What most young programmers need to learn
joostdevblog.blogspot.com
What most young programmers need to learn
1–10 of 108 posts
Re: What most young programmers need to learn
#2Expected to see a long list of algorithm design books, but was pleasantly surprised.
"In this case however it all still makes sense to be in one class, but the class simply grows too big." - would be nice to see some examples, I bet anything can be split in a nice way.
Re: What most young programmers need to learn
#3> Code in comments [...] When asked applicants are usually well aware that commented-out-code is confusing, but somehow they almost always have it in their code.
To my experience this is a common symptom of not using a version control system. You change a line of code, but you want to be able to undo if it doesn't work, possiblay half an hour later when you changed other places of your code (so your editor's undo is of no use).
I also see this from people who are using VCS, but that's mostly because they are overcautious and/or have not really gotten "warm" with the VCS.
A final, very small percentage are familar with VCS and confident with their code, but leave that commented stuff in there accidentally. The usual cause it that they have not (yet) acquired the habit of reviewing the diff before committing.
Re: What most young programmers need to learn
#4The insight that "knowledge" is not the the problem, but "self discipline" is an interesting one.
I made similar observations and came up with a list of "coding commandments": https://larsxschneider.github.io/2013/08/25/ten-commandments...
Re: What most young programmers need to learn
#5Well-organised code with sensible, correct naming of things will save you years of development time during your career.
Re: What most young programmers need to learn
#6So true. When I was a junior, code quality was the first thing I was taught, in the first week.
While the code worked reasonably well, there was no indentation, spacing, comments and variable names longer than one letter (perhaps because my first language was GW-BASIC).
Re: What most young programmers need to learn
#7> Code in comments [...] When asked applicants are usually well aware that commented-out-code is confusing, but somehow they almost always have it in their code. To my experience this is a common symptom of not using a version control system. You change a line of code, but you want to be able to undo if it doesn't work, possiblay half an hour later when you changed other places of your code (so your editor's undo is…
Yeah... I need to stop doing this. Hangover from pre-VCS academic code-soup habits.
Re: What most young programmers need to learn
#8Young programmers should first learn to _READ_ and understand code.
Re: What most young programmers need to learn
#9> Code in comments [...] When asked applicants are usually well aware that commented-out-code is confusing, but somehow they almost always have it in their code. To my experience this is a common symptom of not using a version control system. You change a line of code, but you want to be able to undo if it doesn't work, possiblay half an hour later when you changed other places of your code (so your editor's undo is…
I am guilty of commenting out code when I am working on a problem, but before committing I remove it unless it is the simple version of some function that I made way too complex in order to improve performance. I find it easier to understand later what the complex code is supposed to be doing if I have the simple implementation in the comments.
Re: What most young programmers need to learn
#10Scheme.
As still the best "small" language to teach fundamental principles (everything is a first-class value, symbols are references to values - naming, procedure composition and nesting as the basic building block, ADTs, immutability of the data, evaluation strategies - eager and lazy, and what is meant by "mostly functional language", etc.) and shapes of data structures (list, three, table).
It will pay back with any "stack" or a "framework".
Haskell.
To learn that static typing done right (type inference) is a very clever feature, but it catches only simple errors (it cannot catch flawed logic or wrong abstractions), so it is not a silver bullet, and, perhaps, to realize why "extremes", like "pure-functionality" or "lazy language" are rather unnecessary complications than big gains. And that monads are mere accidental, awkward ADT to ensure an order of evaluation in a "lazy language", where it is undefined by definition.
After that one would find everything in industry is rather easy and boring and develop a healthy aversion to Java and other "packers" stuff.