The Clean Coder is a good read for starting programmers. It goes beyond code to what it takes to be a software professional.
http://www.amazon.com/The-Clean-Coder-Professional-Programme...
What most young programmers need to learn
51–60 of 108 posts
Re: What most young programmers need to learn
#52Earlier quoted context omitted.
The short answer is "yes, it's worth the time". One big improvement I've made in my code over the years is that I take the time to improve my code. Continuously improving code quality does lead to high code quality, and high code quality reduces maintenance hours (both amount needed and time spent).
Well, it really depends on business objectives here. If you're writing the code which will live at least a month — definitely. But if you're writing a quick hack of a project or test that you're know won't be around next week, it's often a real waste of time and effort. And I'm not writing about that theoretically now: for me personally, it's a real problem. Whenever I sit to write a simple dirty hackey thing, I alwa…
The problem is that one-time hacks have a nasty habit of living on and becoming long-lived systems. And it can be hard to explain to users / business owners that just because it appears to work doesn't mean it's "already done".
Writing quick hack code is a good thing if you are in an organization that is disciplined enough to throw it away after you've learned from it.
Re: What most young programmers need to learn
#53Young programmers should first learn to _READ_ and understand code.
You mean getting used to other programmers' idiosyncrasies and deciphering them? You will dissuade them from ever taking up this profession with that attitude. I was attracted to this because of the opportunity to create things, not because other people wrote stuff and now I have to read it.
I disagree thats what the GP meant. Too often people just hack away without truly understanding what they are doing. Then you end up with trying a million things until finding something that works and not knowing why it works. If you take a few minutes to read the documentation and understanding why you are doing something rather than "I tried it and it worked" you will become a better programmer.
Re: What most young programmers need to learn
#54> 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…
Another reason for keeping the commented-out-code, could be if reverting to a previous version of the code is more work, than checking in a new version. Or when the old commented-out-code is used as an explanation as to why the current code looks as it does.
Re: What most young programmers need to learn
#55I disagree with his last point. There was once a time when I was obsessive about not copying pasting code. Over time I eventually learned that sometimes it better to just copy+paste a code snippet a few places than being dogmatic by making sure that nothing is ever duplicated. My rul of thumb is that if there is branching then don't copy, if there is no branching, then you can copy+paste it.
This snippet should only live in one place:
if (something) {
for (blah blah) {
something_else();
}
do_something();
}
do_something();
do_another_thing();
another_call();
Re: What most young programmers need to learn
#56The Clean Coder is a good read for starting programmers. It goes beyond code to what it takes to be a software professional. http://www.amazon.com/The-Clean-Coder-Professional-Programme...
Excellent. I'd also recommend
"Code Simplicity: The Fundamentals of Software"
http://www.amazon.com/gp/aw/d/B007NZU848?ie=UTF8&redirectFro...
Re: What most young programmers need to learn
#57From someone who started as a developer only 2 years ago, I found the stuff about how to properly design classes to be the hardest part. There is not enough touted articles on it on the internet.
For example, how would a developer know to break [insert functionality] into a separate method? It is not always obvious to junior developers to break a method into smaller chunks, especially when they understand every line of code written. They usually recognize the problem once it is pointed out, but it doesn't often register beforehand.
Re: What most young programmers need to learn
#58> 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 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. Yeah, that could probably describe me. Reverting a particular piece of code back from VCS seems like more work (the kind of "I need to think about it" work), which is enough for me to leave bits of code commented when working on some particular task. I never leave them th…
This is what I do as well. I use VCS but it's more work. If I'm just refactoring a piece of code I comment it out while I work on the new stuff and test it. It also has the added benefit that I can reference the old code easily if needs be. Occasionally I will commit with the commented code still in place (until I'm 100% confident with my new code) but I usually follow that up quite quickly with a commit removing it.
Re: What most young programmers need to learn
#59Something I've learned over the years:
"A little discipline now will save a lot of discipline later."
This goes for anyone in any walk of life and in any profession.
Re: What most young programmers need to learn
#60From someone who started as a developer only 2 years ago, I found the stuff about how to properly design classes to be the hardest part. There is not enough touted articles on it on the internet. For example, how would a developer know to break [insert functionality] into a separate method? It is not always obvious to junior developers to break a method into smaller chunks, especially when they understand every line…
A common approach is to describe the functionality aloud. If your description includes the word 'and', then there may be a problem ("this method increments the foo counter, and makes the tea").