Monday, November 7, 2011

Becoming A Better Developer

One of the most frequent questions that I get asked is “How can I become a better developer?” I think that it’s a very good question to ask that deserves a good response. But how can you respond to something like that? Becoming a better developer depends so heavily on past experience (where to grow), interests and rationale (why do you want to grow), that it’s really hard to answer without a fair bit of discussion. This post reflects my experiences from both my own growth and the growth that I’ve seen in others.

Motivation

By far, the most important step to becoming a better developer is to be motivated to do so. This may sound like common sense, but in reality there are a lot of very smart developers in the world who are quite happy to stay at their current level. A famous phrase comes to mind here:
If you’re not growing, you’re dying…
This couldn’t be more applicable than to a discussion on developers. In our world, technology and capabilities change so fast that unless you’re actively trying to push yourself, you’ll rapidly become irrelevant. The best developers don’t just rely upon what they know; they actively are trying to push the boundaries of what they know. The best developers that I’ve ever met aren’t all the smartest people that I’ve met, but they all have had a strong drive to be better (even when others consider them “the best”).

Becoming a good -or even great- developer takes more than a desire to make it happen. It takes a commitment to do whatever you possibly can to make it happen. If that means spending 30 hours per week outside of work growing your skills, then do it. If that means traveling to conferences once per month, then do it. If that means alienating yourself from friends and family, well that’s up to you…

Confidence

Good developers are usually quite confident in their abilities. Why? Because they know that they have put in the effort to truly understand what they are talking about. But I’ve met a lot of developers who come across as poor or average simply because they don’t have confidence in themselves. Be confident in what you know.

Now, I think it’s worth noting that there’s a difference between confidence and arrogance. Being confident is a very desirable trait in a developer. It enables a developer to make the right decisions and discuss them in a productive way with others. But arrogance is deadly to a developer. It will completely kill any team dynamic, and often results in poor choices do to the “I know better” effect. Being confident lets you discuss and listen to others while still contributing to the discussion. Being arrogant shuts down the ability to listen and understand others.

Choose Concepts Over Implementations

Once you understand how basic programming works, you can start to separate yourself from the implementation details. Despite what many people may say, there’s not much conceptual difference between the different programming languages out in the world. Sure, there are different paradigms (functional, procedural, OOP, etc), but if you know the paradigm the language operates with, the rest is just an implementation detail. Focus on learning and understanding the concepts behind what you are working on.

If you understand the concepts, that enables two things. First, you can use those concepts in other languages with ease. But far more importantly it lets you think abstractly about different ways to solve a problem. It also lets you learn from other communities. So rather than waiting for somebody else to solve a problem in your language, or looking for help in your language, you can look anywhere for help.

The language that you use should only ever be an implementation detail (once you pass being a beginner). By some counts, you should be learning a new programming language at all times. If you’re the type of person that struggles with separating concepts from implementation, then this is very good advice. But I don’t think that you really need to keep learning new languages to become a better developer. Sure, it can help add perspective and depth to your abilities, but if you’re focusing on concepts then switching to a new language should only take a week or two.

Yes, I did say that moving to a new language should only take a week or two. And no, I don’t mean writing your first program. You should be able to switch to a new language and be almost as good as you were with the previous one in one to two weeks. If you learn concepts over implementations, this should not be difficult as learning the new language will simply be syntax and core library differences.

Read At Least One Book per Week

If you like fiction, then continue reading your favorite novels in your spare time. But to become a better developer, I would suggest that every single developer should be reading 1 technical book per week. There are two main things that you’ll benefit from with this approach. First, by reading actual books, you’ll focus on exploring a concept in depth (as opposed to blogs and online reading which tends to not fully dive into a concept). In that sense you can take those lessons and better apply them to the real world.

The second advantage to the one-book-per-week approach is that it will make you push your boundaries. One book per week is 52 books per year. Think of how many good books (based on reviews) are in your comfort zone, and it’s easy to see that you’ll quickly run out of books to read. Then you’ll have two choices, either read books that have bad reviews, or read books on topics that you’re not familiar with. That’s the best way to grow.

Share Your Knowledge

One quote that I’m especially fond of because of the shocking truth behind it is:
The best way to learn is to teach.
Do I think that every developer should go sign up to lecture at a college? Not at all. But do consider sharing your knowledge to others. Start a blog and post your thoughts to it. Offer to give talks to local user groups. Offer to speak at conferences. Write a book. All of these are easy ways to start sharing what you’ve learned. This will force two things to happen. First, since you won’t want to come off poorly, you will likely put in more effort understanding the concept better. Second, you’ll refine that knowledge more than you can imagine by talking about it and receiving feedback from the audience.

Here’s something to think about: Are people who speak at conferences speaking because they are the best, or are they the best because they are speaking…

Become a Mentor

Find somebody whose abilities are below yours, and help them out. It works best if that person works on your team, but can be applied to people online as well. The important thing is to look at the mistakes they are making and help them to understand why they are making the mistake. The obvious benefit here is that you are “paying back” the community and investing in the future of the industry. But a subtle benefit is that you’ll gain experience through others’ failure. By mentoring someone else, it will enable you to gain experience and skills much faster and better.

Conclusion

Becoming a better developer isn’t rocket science. It’s not even that hard. All you need to do is be motivated enough to put the effort in to do it. It’s completely up to you. I’m reminded of another saying:
Success comes not to those who look for it, but to those that make it happen.

10 comments:

  1. Thats the great information :)
    Thanx

    ReplyDelete
  2. Thanks for the awesome post. I especially like the idea of reading one book per week.

    ReplyDelete
    Replies
    1. I think a better way to say this is: In a week/two, you should be able to read any code in that language.

      But writing, it's a whole other game. Depends of libraries, frameworks, code conventions, language paradigms (OOP vs. functional vs. lisp) etc. Writing decent code in a given language takes lots of time and experience. That's why senior developers make more $$.

      Delete
  3. A really good post with some excellent points.

    I do have to slightly disagree on the "moving to a new language should only take a week or two" point though. Learning the basic syntax and being able to write software that runs should only take this time, but there's much more to consider to be able to say you know a language (such as scalability, performance, security, infrastructure etc).

    While I agree that both thinking in concepts over implementations and learning new languages are very good things to be doing, there's also a lot to be said for becoming an expert with one or two particular languages or stacks.

    ReplyDelete
  4. @Jaik

    What I had intended was that you should be able to go from being productive in one language to being productive in another in a week or two. Of course you won't be nearly as good or even expert level at the new language. But you should be at least able to work at a junior professional level at it.

    And definitely, it's worth becoming expert level with at least one or two languages. But I would assert that you do that by focusing on concepts rather than implementations. Sure, you're going to need to learn some nuance and specific behavior of each language (for example, the ins and outs of memory management in the language), but the majority of it can be learned generically and then "tweaked" with language specific constraints.

    Thanks for the comments!

    ReplyDelete
  5. Re: Share Your Knowledge

    I think writing open source stuff is a good way to share knowledge too. Of course, an open source software package that no one uses kinda defeats the point, so you need to promote it, too. ie. "spam" it (is it really spam if it's topically relevant?). And then you need to support it. Like in the case of PHP-CryptLib... I dunno... maybe get a forum for people to ask questions?

    I also don't agree with the premise that those who speak at conferences are the best. Maybe they are, maybe they aren't - I'd judge on a case by case basis.

    Re: Read At Least One Book per Week

    I think you'd be better off writing open source stuff, spamming the heck out of it and then providing support for it. Time spent reading is time that could have otherwise been spent doing that.

    You're gonna make mistakes when you first start out. You're gonna have XSS vulnerabilities, SQL injection vulnerabilities, etc. But you lick your wounds, learn from your mistakes, and try again, and you're not going to be making mistakes by reading a book.

    I dunno... reading a book a week may be the best approach for some people. I, personally, think I'm a bit more of a hands on kinda guy.

    ReplyDelete
  6. I couldn't agree any more. Great Post! Thanks Tony!

    I also posted something similar about how to be a better developer a while ago on my site:

    20/20 Top 20 Programming Lessons I've Learned in 20 Years.
    http://www.dcs-media.com/Archive/20-20-top-20-programming-lessons-ive-learned-in-20-years-FH

    ReplyDelete
  7. Most of the above are fine.

    Though I don't agree very much of the following quote as "shocking truth":

    "Best way to learn is to teach"

    Because I believe the best way to learn is to do: to create something of use to others. I am not deflating the huge importance of teaching. It's just that creating programs is far better way of learning. You learn about how to satisfy work needs of others, how to make their lives easier and others.

    ReplyDelete
  8. Yes, one should read as many books as possible, but one book per week is too much. Reading that many books will not make you better developer but better philosopher. One should read a book and then enrich that knowledge with experience.

    ReplyDelete
  9. Hi Anthony,

    I wonder how many developers read that 1 book/week. I do read a lot of articles but I don't have time to read 1 book/week!

    ReplyDelete