from Hacker News

Advice to young programmers

by chegra84 on 7/23/11, 1:43 PM with 63 comments

  • by crikli on 7/23/11, 4:16 PM

    I would also add this: don't join a priesthood.

    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.

    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.

  • by nakkiel on 7/23/11, 3:25 PM

    My only advice, to all programmers, is to print the following and stick it in a place where you can see it everyday:

    “There are only two hard problems in Computer Science: cache invalidation and naming things.” – Phil Karlton

    The variant mentioning off-by-one errors may be pleasant, and useful for beginners, but is hardly a problem.

    When we'll have solved the naming thing we'll be safe.

    The rest is just buzz-words and useless noise.

  • by lifeisstillgood on 7/23/11, 9:31 PM

    5. Say yes ... No!

    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

    If you have done it once already and know how much effort it will be - say yes and quote

    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&D.

    The customer then has more choices / options which is usually appreciated

    Dont lie to customers. And saying yes without saying "I've never done i before" is lying.

  • by zwieback on 7/23/11, 4:35 PM

    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.

    It's a lot easier to avoid becoming a zealot when you know what's going on underneath.

  • by RegEx on 7/23/11, 3:45 PM

    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.

  • by mtogo on 7/23/11, 6:14 PM

    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.

  • by sayrer on 7/23/11, 10:28 PM

    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.

    Here's Peter Norvig's review of a Python title: http://www.amazon.com/review/R2C7L5KHUVHOR2/ref=cm_cr_rdp_pe...

  • by sshah on 7/23/11, 9:56 PM

    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.

  • by peterb on 7/23/11, 3:24 PM

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

  • by defdac on 7/23/11, 4:38 PM

    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.

  • by thesmartace on 7/24/11, 12:42 PM

    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.

    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.

  • by xsmasher on 7/23/11, 9:36 PM

    Think, then plan, then code.

    Simplicity where possible, complexity only where required.

    Be a code scientist. Take your theory about the bug, test your theory, then make the fix. Then test the fix.

    Don't be satisfied until you really know what's going on.

  • by apetresc on 7/24/11, 5:25 AM

    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.

  • by known on 7/23/11, 4:17 PM

  • by tete on 7/23/11, 5:20 PM

    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.