Advice to young programmers

I would also add this: don't join a priesthood.<p>In other words, keep your mind open. Don't become a domain expert, as advised, and then convince one's self that that domain is The One True Path. Conversely, don't glance at a particular domain, assume that casual knowledge to be canonical, and then write off that domain as A Path of Fools.<p>Young programmers are especially susceptible as the myopia of youth prevents one from grasping the miniscule nature of their own knowledge. Once one gets a bit older, he/she tends to realize that what they know is but of grain of sand in the ocean.

My only advice, to all programmers, is to print the following and stick it in a place where you can see it everyday:<p>“There are only two hard problems in Computer Science: cache invalidation and naming things.” – Phil Karlton<p>The variant mentioning off-by-one errors may be pleasant, and useful for beginners, but is hardly a problem.<p>When we'll have solved the naming thing we'll be safe.<p>The rest is just buzz-words and useless noise.

5. Say yes ... No!<p>SAying yes is an implicit delivery promise. You will either break yourself (budget over runs, massive stress) trying to deliver, and/or you fail and your reputation suffers<p>If you have done it once already and know how much effort it will be - say yes and quote<p>If you have never done it before, say "I have never done it before" but for a small hourly fee I will implement a prototype. If you like it we can talk full project, but if not, or if I cannot make it work, then I just keep small fee as R&#38;D.<p>The customer then has more choices / options which is usually appreciated<p>Dont lie to customers. And saying yes without saying "I've never done i before" is lying.

I would also recommend learning at least the basics of lower levels of computing technology, e.g. some CPU architecture and some assembly or low level C.<p>It's a lot easier to avoid becoming a zealot when you know what's going on underneath.

Some good advice in this article. The most valuable thing I've picked up as a young programmer is the importance of finding your own learning style. Some people read books, some watch podcasts, some can just read the documentation and go. I've found that browsing example source code in the language/framework I'm using (with some light documentation reading) does well for me. It may take you too long to learn the skills, languages, or frameworks required by your post-graduation employer if you never took the time to find the best way to teach yourself.

This advice is mostly not harmful, but the most important thing a newbie programmer can do is actually just code. Just sit down and write some code. That's it.

I don't know about those Deitel books. I had to use a Java one in college and did not enjoy it. Maybe they've gotten better.<p>Here's Peter Norvig's review of a Python title: <a href="http://www.amazon.com/review/R2C7L5KHUVHOR2/ref=cm_cr_rdp_perm" rel="nofollow">http://www.amazon.com/review/R2C7L5KHUVHOR2/ref=cm_cr_rdp_pe...</a>

The 'path' seems to be of a solid programmer/consultant. If you are going to work in a team then I would add 'improving teamwork skills'. This mainly involves respecting others in the team and focusing on team's success. These things go a long way and you will get a chance to work with developers in different areas of the company and contribute towards interesting projects.

He missed some important ones: study good code and practice writing it.

I like this article, probably because I do as outlined in it - but I also wonder how this (or the first advice particulary) is applied to pair programming? Seing someone else solve an interesting problem over his/her shoulder while discussing it endlessly will never quite stick as when you think about a problem for days and then come up with a solution for yourself.

I think the main piece of advice is number 2. Make lots of small throw-away programs. Whether these little junk programs are good or bad doesn't matter - you will be learning something either way.<p>And post everything to Github (or Google Code, Sourceforge, etc). Having that kind of thing public gives you more of a reason to want to improve.

Think, then plan, then code.<p>Simplicity where possible, complexity only where required.<p>Be a code scientist. Take your theory about the bug, test your theory, then make the fix. Then test the fix.<p>Don't be satisfied until you <i>really</i> know what's going on.

I think his Point #5 should say "knock something OUT", not "knock something UP". If someone asks you to knock something up, you should probably ask your wife for permission first.

I'd suggest <a href="http://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it" rel="nofollow">http://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_...</a>

I don't think seven "Become a domain expert" is a good idea and especially not something you should recommend. If yo really find the right thing you'll know, but it is very good to know a lot about everything.