Today I was at the meetup for the newbies. (Again. After the previous time, I wrote Advice for the Newbie.) And this meetup inspired me to write this article.
Use TextEdit
I talked to one person who got the following advice: to learn CSS and HTML use TextEdit (or another plain text editor). Supposedly you will learn syntax this way faster. Adviser thinks that using modern code editor (like code or sublime) will make learning slower.
What awful advice. It is so hard to write code without highlighting, without editor which can highlight matching brackets, which automatically indent cursor when you go to the next line. It would be such a waste of time for a newbie. Even more modern editor often has syntax checker built it in, so instead of writing something, saving the file, reload the browser you would see errors right in the editor.
Why would you spend time on something that machines can do and can do much faster? Machines can check syntax, fix formatting automatically.
You need to understand syntax to write programs, but there is no reason to refuse help from the machine.
Learn Python (to learn JS)
One person asked what is the best way to learn JavaScript. And the advice was to learn Python. Wait, what? So the reasoning is following, JS is very confusing (I agree), and Python less confusing, so if you learn basics in Python you can switch to JS.
The intention is nice, but the advice is awful. A newbie will spend time learning Python, and then will switch to JS and will find it even more confusing than before learning Python, because eloquent Python is a bit different from eloquent JS. In JS you have an event loop, and async/await and awful coercion rules, which you should avoid as plague.
The better advice would be: learn JS but learn the best parts of it e.g. avoid coercions with triple equality, use let/const to avoid problems with scoping (var), use arrow functions to avoid problems with this, etc.
Maybe there is ESLint config with good practices, like eslint-config-react-app, but not React specific.
Don't get me wrong Python as a language is ok, if you want to learn Python please do, but recommend to learn Python to understand JS...
Learn webpack
The person asked how to get started with modern web development. And the advice was: sit down and write web pack config from scratch, so you would understand who bundler works and then you can write website.
Webpack is nice, but it is a very complex tool. It has so much accidental complexity exposed to end-user. Error messages are confusing. Version migrations are hard. Documentation sometimes missing. It would be so hard to learn for the newbie. I think the person will give up before they accomplish something.
Why would you do this as the first step? You can use Parcel, which doesn't require configuration - there is nothing to learn (almost nothing). Or you can use create-react-app, which hides webpack.
Webpack as the software is ok, but it is very hard for the newbie and not needed, because you can start with other tools and learn webpack later.
What is the worst advice for the newbie?
Share your examples of bad advice (at dev.to or twitter).
Photo by Ashley Jurius on Unsplash
Top comments (44)
Everyone's first language should be C
This particular gatekeeper felt that it was super important that every developer start their journey with a strong foundation understanding of memory management, and that the only way to do that was to start with malloc.
god i heard that so much when I was starting out
I still hear that today, though i'm learning Webdev lol.
I can't even try to imagine the chaos of pointers, memory managment, the complex C syntax and just any sort of understanding of this level of "low-levelness". I think i'll stick to HTML/CSS/JS and Python
I really like the way I learned in school. We had a C class but it was one semester first year. It was more broad than deep. It was helpful in a number of ways but we didn't spend too much time on either the language itself of the whole degree program or any particular part of C in the class itself.
That said I would never advise anything more than that for most people and it certainly isn't necessary for most people.
As I said in the other reply, the main bad part of the advice is that it is the way to learn about fundamental programming skills. Can you start out with C? Sure it works and plenty of people have gone down that path. But there are other paths that people can go down that are perfectly valid.
I agree with this! In my college, the first programming language you have to learn is C. A lot of people fail the course.
They say its a way to filter out those who are really “ aren’t built” for computer science. At such an early stage, I think the college should cultivate interest in the subject rather than test a student’s aptitude right away.
This was my complaint while I was studying CS in college. It seems so elitist to introduce C as a way to weave out people from pursuing CS. I suggested that the lower level class for freshmen should be in python to build interest from those who have never heard of programming or didn't know where to start.
My initial suggestion came from the fact that students from rural America are usually left behind in the race for technology in academia..but then again, academia is mainly about elitism.
I don't believe that this advice is bad.
I heard it, practiced it and I'm quiet happy about it.
Most of the time as webdev, I don't care much about memory.
But when I'm starting to work on bigger applications or with bigger API, experience taught me to be careful about it. Especially if my end user cannot up his hardware easily, when my 3D GIS app start to use more than 3GO of RAM.
The issue is not that "learning about how memory works" is bad advice. The issue is the manner in which you are supposed to learn.
Does learning about pointers, malloc, and free teach you about memory management?
Sure.
Is what you learned immediately transferable to a GC type language?
No, the rules are different and you have to learn some new things.
If you had no desire to learn C at the moment, could you just learn how memory works within what you are using?
Yes.
Will that be easier and quicker than having (and this is the key bad thing about the advice, that you have to learn C first or you won't know what you are doing and will be a bad programmer) to learn C first?
Yes.
ok yes I understand your point.
A good advice would be to have a good understanding about the basics, including memory.
But does that mean that you must learn C ? No, indeed.
I guess when you start programming (in general) without knowing which language to use first, C could be considered a good one. But well I started with Java and many started with Python... so the point is more about the concepts and basics than the language itself
I think one of the biggest mistakes that are made is learning a framework too early. So many kids do not understand the basics of CSS, HTML, or JS.
When I interview a entry level person and they only know React and bootstrap, it gives me a lot of concern. When you ask them to do something very simple and they can’t, it shows they don’t know the basics and never tried to learn them.
Some of the advice above is not that bad. CS Code is amazing, but there is a benefit for leavening to code correctly. For example candidates that use Prettier write ugly code. But someone that has more experience writes nice code. What does this matter? Because the tech stack, language, and standards can change. Knowing good core programming practices translate across multiple languages.
Bottom Line - everything changes soooooo fast. Prepare for change. It was only a few years ago Google was trying to replace JS with Dart for example. Before VS code, everyone was using Sublime, Atom or Webstorm. So even the tools change overnight.
Read clean code.
Keep it DRY.
Don't write comments.
I always think of there being two kinds of DRY: abstracting DRY and deduplicating DRY.
The first is the more classical DRY that people often think of in OOP extracting shared behavior into reusable objects etc. This is something that can be learned along the way but needn't be focused on as a beginner.
The second is DRYing things up on a more local level like moving multiple instances of the same basic logic within a method that can be called in place of those lines. This I think it is worth learning from the start.
Yeah that makes sense. The problem with the DRY principle is that most of the time you should repeat your self.
Although I'm a C programmer and do mostly backend network programming involving raw sockets, packet capture, etc., I disagree when newcomers get advised to start from C language because they need to know how memory, cpu and whatever works at the basic lebel. That's great, but that's like saying I need to be a mechanic to learn how do drive. Since most of developments today is web dev which is done mainly in higher level languages like Javascript, there really is no need to burden yourself with all the complexities of C, C++ or any other statically compiled language with manual memory management. Unless you want to go in that direction like me for example or are attracted to embedded devices, stick to higher level languages. This is my opinion and in no way a professional guidance of any sort.
It's still amazing to me that people recommend you learn other languages to learn JS. I've seen people recommend Python, C/C++, Ruby... If you want to learn JS, learn JS damn it.
Most of the bad advice I see do things like setting up false expectations about how things are going to feel, send developers on wild goose chases (as in the python case), or putting up false barriers.
I just wrote an article on this, actually... dev.to/canderson93/7-pieces-of-bad...
I think the most damaging piece of advice that beginners get is "Come do this other course." -- When you're working with the basics, courses are basically interchangeable. Beginner concepts are very concrete. It's hard to teach a for-loop wrong.
What this advice does is lure beginners into a false sense of "the grass is greener", and the reason they're still struggling to build software is that they haven't done the right course yet. So they keep starting over again, looking for this magic course but never addressing their actual issue (which is that they haven't been learning to build software). Welcome to Tutorial Hell.
Again, more shameless plugging here, but I expanded on this idea in dev.to/canderson93/can-you-actuall...
I think for me it's "just read the docs" when it comes to understanding how a certain library/framework works. People learn in different ways, so maybe they'd be better off watching a course or reading a blog aimed at beginners.
Abstractions can be incredibly expensive and should only be created if you are absolutely sure it's the right thing to do
Regarding the first point I understand why some would give such advice.
To have a better understanding of some of the mechanics and concepts, I'd advise a newbie to use text editor instead of an IDE.
For example : to a guy learning C, using a program that does all the compilation process will not help him assimilate how it works. Using only a text editor he will have to write a makefile and do it himself. Better struggle with this in the learning stage instead of having issues when you have deadlines to deliver your code.
Also, I think that it might help a newbie to search functions or variables "the hard way" in a project he has never worked on instead of having a shortcut highlighing all the occurrences in the whole project. It forces him to search the logic used by the other developers.
But of course it makes no sense not having line numbers, syntax highlighting, syntax checking... These are the features that helps keeping the learning curve going up.
Nah, you really have to let people see some successes early before you try to enforce the "You gotta do it the old fashioned way so you really learn the basics. I think we still have a box of punch cards around here somewhere..." How about letting someone learn the basics of programming in that language before you start expecting makefiles and the like. Jesus tapdancing Christ! You aren't going to make a better programmer, you are going to make a possibly great programmer up and quit.
We need to move beyond the mentality that doing it the hard way builds character, and the "It was painful for me so it should be painful for them too!" type of thinking. Trust me, even with the modern IDE, a new programmer will have plenty of challenges ahead of them that will provide the opportunity for hard learning experiences. I would hope that if you ever interview someone, your questions aren't about the finer points of using gcc to build a C project (unless the job specifically works in C for some reason)...
I'm not saying I did it the hard way so you have to do the same. I chose to use a text editor after a few weeks instead of an IDE, it was not an advice I received. And I never perceived it as painful. I liked understanding what really happenend and not clicking on a button and wait for it.
And of course you've got to have early success, and using a text editor isn't preventing that.
If we keep talking about C programming, you won't need a Makefile for a while since you will use a single file for a few lessons. And at first you will just have a simple
gcc yourfile.c.But quickly afterwards, you will have multiple files importing one another and will have to build intermediate states. Then more and you will need to use a Makefile.
That is learning too, and why managing to do it isn't a success too?
Of course you will have to go using an IDE afterwards when working on large projects, it will make your life so much easier. But I don't see how using a text editor (once again with some useful features) is a bad advice.
And no I'm not a maniac during interviews! I'm not doing C since I graduated, it was just an example that suited.
All of what you said in your reply is along the lines of what I had hoped for, but I have run into too many in our field who legitimately believe that one must go through a rite of passage, and earn knowledge through painful acquisition.
The question about the interview came to be because I am still a little raw from an internal interview I did quite recently where the interviewer was more interested in showcasing his expert knowledge and denigrating my own skill set than he was about determining whether I would be the candidate that was the best fit for the position. Since this chucklehead was the guy I would have to be working closely with if I got the job, I went and spoke with my manager after the interview and personally passed on the position. I don't know if I ultimately passed or failed his interview, but he certainly failed mine.
All in all, I really didn't mean to focus on C, because the main area where this is hitting our industry is in web development. The bootcamps are of quite checkered quality, and it is hard to know if someone is a well-rounded developer capable of working in multiple frameworks as well as in plain vanilla JS when needed, or if your newest hire is only as skilled as the framework they were taught in, and resembles a fish out of water when the project requirements are switched suddenly. Someday, our field might become more formalized in our evaluation of an engineer's skill set, just like the mechanical, electrical, or civic engineers are. Students will sit for a PE certification upon graduation from whatever program they study. Someday.
Once again, I do not see it as neither a rite of passage, nor a painful way to learn.
I'm just saying that I don't see it as a bad advice because I would recommend people to do so!
That is what I chose to do back then and it worked for me. And for a curious person, it can be quite fun actually to understand what the IDE is doing when you click the build and run button.
But it is only a friendly advice. I won't judge a person who choose not to follow it 😉!
I don't agree with the first point. As someone who started off in web development using notepad / notepad ++ (especially as Dreamweaver used to add too much extra crap to your code) I feel that my base understanding of front-end approaches far outweighs that of someone who has VsCode or VisualStudio suggesting classes and approaches to someone. It is much better to gain a base understanding and find for yourself what certain CSS etc do before having it done / refactored for you by a clever IDE. At the end of the day, if the IDE is doing most of the work for you rather than assisting in refactoring then you aren't really coding you are essentially painting by numbers.
Dreamweaver is WYSWIG editor, it's not a code editor. Don't put everything in one bucket.
notepad++comes with highlighting and bracket matching (don't remember about code indentation, but probably it does it too). You kind of agreeing with the first point...Not really when I explicitly mention good old notepad standard. This is also before Notepad ++ came bundled with all of that stuff. Also, just because Dreamweaver is a WYSIWYG editor doesn't mean that you can't code in just the code panel. In fact, back in the day the code window was all you would see through fear of the crappy WYSIWYG editor adding in loads of garbage markup. Either way it's beside the point. Developers, especially when learning front end which is one of the easier fields to come to terms with, should have a base understanding of best practise, conventions and indeed syntax without having a IDE hint at everything for them.
This Dreamweaver remark is almost a strawman.
I didn't talk about code generation I talked about highlighting and syntax checking right in the editor.
I don't need to convince you - you are not a newbie.
Newbies, whenever you will hear this advice - ask if adviser uses notepad or proper text editor in day to day job and reach your conclusions.
On the plain text editor point I think some people believe that using tools like intellisense make for lazy developers who don't understand what they're 'really doing'. I fundamentally disagree, I thinks it's much more useful to know the behavior you're after than to remember the exact command/statement which will get you that. I've been a web developer for ~7 years and I still have to look up much of the finer point of CSS that I use.
This might have made a bit more sense in 'the olden days' (or for DevOps types these days) when you had to be able to hot-edit things on the server with only nano or vi to edit things on a server.