Letter to a Young Developer

I’ve been getting some emails from young developers wanting to “level up” as programmers. I’m definitely not the first to write about this topic, so I’m not sure how much I have to add. Still, for what it’s worth here are a few points off the top of my head:

  • Work with other developers. We are at a wonderful time in the history of technology when for the first time, it doesn’t really matter where you are or who you are working for. So long as you have a decent internet connection, you can pair up with another developer anywhere in the world and work on some code together. More and more experienced developers I know are offering their time for this kind of knowledge sharing. My friend Evan Light holds open office hours, and is developing a site to help Rubyists  pair up. I’ve been doing this for a while as well. Want to work on some FLOSS code? Email me and we’ll set something up.
  • Read the classics. Code CompleteThe Pragmatic ProgrammerThe Practice of ProgrammingDesign Patterns. Etc.
  • Read WikiWiki (sometimes known as WardsWiki). I can’t stress this enough. Sometimes I think I learned everything I really needed to know about programming  from surfing WikiWiki on slow days.
  • Read other people’s code. Hooray for GitHub! If you want to start with a more curated collection and you know some Ruby, try Best of Ruby Quiz.
  • Get involved in your local user’s groups. If they don’t exist, start one. And submit talks. I don’t care how much of a n00b you think you are. There is nothing better than committing to a talk to force you to to learn all about a topic.
  • Write a blog. Don’t worry about being original. Some of the most useful blogs out there are a largely a chronicle of a programmer’s experiments and mistakes, and how they overcame problems. Reflection is one of the most important parts of learning, and writing helps you reflect. And sooner than you think you’ll be getting feedback from other programmers.
  • I’m sure you’ve heard this one before: submit patches to an Open Source project.
  • Flip a coin. Heads pick Vim, tails pick Emacs. Start learning to use the editor that came up. Either one will grow with you for the rest of your programming career. Strong, flexible tools make good coders even better.
  • Learn more than one language. But first learn one language well. You need a go-to language where you can get an idea and bang out a first version in a day, without spending a lot of time learning about bits of the language you’d missed or forgotten. But once you have that one, you need new languages to challenge all the assumptions that first language taught you. Pick languages that are widely divergent in styles. From what I’ve seen Seven Languages in Seven Weeks does a good job of covering a wide array of programming paradigms.
  • Get on the mailing lists for the languages and platforms you use. People sometimes forget that there’s a whole world of great discussion beyond blogs, Hacker News, and Twitter. Mailing lists are often very civil and helpful places compared to those other venues.
  • StackOverflow is your friend.
  • Don’t spend too much time researching the “best” tool for something. I used to badly hobble my productivity by spending days or weeks trying to find the very best obscure framework for the project I was about to start. Don’t fall into this trap. When you’re a relatively inexperienced developer, pick languages and frameworks that have lots of users to start with. It’s more important that you know where to go when you run into a roadblock, then that you pick the perfect tool.
  • Look for apprenticeship opportunities.
  • And of course: practice, practice, practice. Write code at work. Write code at home. Practice code katas. Programming is no different from any other skill: in the end, it all comes down to practice.


  1. Such good stuff, Avdi. I especially like the tip about NOT researching the best tool for the job. I’ve wasted so much time doing that. Pick a popular tool and jump in! Like anything you do agilely, it’s more important to learn quickly than to (try to) get it 100% right from the beginning.

    Couple of things:

    1) Would you recommend “The Practice of Programming” to someone who’s left his C++ days long behind him?

    2) Stop calling it VIM. It’s Vim. Thank you very much.

    1. Agreed very much, if you’re not sure of the best tool for the job just pick one. Chances are you’re not going to implement the right tool properly the first time anyways so you will end up rewriting your implementation anyways. You’re mainly just wasting some time you could have been truly learning.

  2. Not sure about the StackOverflow endorsement.  It seems to have pooled a large amount developers, making most of the answers average.  I.e., half of them are wrong.

    StackOverflow seems to be the worst form of carg0-culting out there.

      1. There’s a decent (although, somewhat old) post on the topic here…


        Believe it or not, I haven’t kept track of posts that are misleading :).  I did make an attempt to try and add some information to the post, but the system wouldn’t let me (for reasons I’ve since forgotten).

        Don’t get me wrong, I do think SO has it’s uses.  However, I’m not sure I would recommend it to young developers.  The rest of your advice was spot-on, and I just feel that SO wouldn’t be that useful for people trying to learn how to code.

        1. What’s interesting is that the author of that post spends most of it answering criticisms of SO! Near the end he does bring up some (probably) valid points of his own.

          My feeling is that some people take SO too seriously. It’s a tool, not World of Warcraft.

          (Says the guy who was inordinately pleased with himself recently for going over 100 reputation. That’s right, folks – 100 big ones.)

    1. There is a fair amount of incorrect information there, but it’s easy enough to winnow out. SO has saved my bacon a number of times.

      I started programming in 1984. I can’t imagine how we did it without Google. Lots of trial and error, I guess.

    2. StackOverflow does a lot to improve the quality of the answers. Haven’t seen any other site like that!

  3. I completely agree with all of this. One thing I’d say is “learn lots of languages, but make sure you concentrate on one”. I’ve done C++, PHP, Python, Scheme, JavaScript and Ruby (roughly in that order), and I’ve settled on JS and Ruby as my go-to languages. I’m glad I didn’t settle too early though.

  4. Very good post. I especially agree on giving talks. Fear of making a fool of yourself in front of people can be very motivating!

  5. Very good post. I especially agree on giving talks. Fear of making a fool of yourself in front of people can be very motivating!

  6. Nice post! Inside the local user group topic I would add “Give talks”, you know, sometimes I commit myself to talk about something at my local user group (though not recently, mea culpa) because it makes me really dig into the subject of the talk and actually learn something.

     Just a tiny note, the link to the rubypair repo is broken 

  7. Great post! I have also as many others spent way to much time researching the best framework/tool and most of the time it isn’t worth it. If you wan’t to be agile (as most of us probably want :-)) its all about being productive and you can reserve time to learn a new tool or do some research when you don’t want/have to be productive. I would also encourage young developers to focus not only on one language but also at one task at a time – kanban can be very good to know about in this regard.

    Happy coding and good luck!

Leave a Reply

Your email address will not be published. Required fields are marked *