I want to share the two steps that I’m using to walk the path to becoming a great developer. Becoming a great developer is a constant work in progress, but it’s a pattern that I’ve seen many other great developers follow.
Step one: Write more code
This might sound easy but trust me, it’s not easy. There are an infinite number of reasons we developers don’t write code:
- I don’t have the time
- I don’t know that code base
- I don’t have the right environment setup
- I don’t know what to work on
- I’m tired
They all boil down to fear. You’re afraid of something. Afraid of wasting time, afraid of being embarrassed publicly, afraid of making a mistake, afraid of being afraid.
Let me share two stories with you about my fears:
I’ve been a contributor to Redmine for a couple of years now, but I haven’t been very active in the code base. Why? Redmine is a large complex code base and I didn’t know how everything worked. So I stayed in my corner and only committed minor changes. Yet I still found a way to break those sections. Self fulfilling prophecy?
With my product, SeeProjectRun, I have to charge users’ credit cards. Taking actual money is scary. After hearing all of the horror stories about companies screwing this up, I became deathly afraid of this and put off writing any billing code. Yes, me a developer who has written four credit card interfaces for active_merchant was afraid of writing code to bill his users. WTF is going on here?
Fear is a mistress that will steal your life if you let her. So how do you get over your fear of writing more code?
Write more code
As odd as it sounds, the only way I found to get through my fear of writing code was to crank it out like it was going out of style. The easiest way to do this? Start new side projects and contribute simple patches to Open Source. Every time you write code, you will learn something about the code, your tools, or yourself. Did you really think my 57 plus daily refactoring posts were only about fixing bad code? Nope, they are my sledgehammer against coder’s block.
Oh and the ending to my stories about fear:
I just spent last night rewriting a core component of Redmine and committed it to the project this morning. It if breaks, I’ll fix it. If it’s really crap code, I’ll revert it. No one will care and no one will remember the mistake.
And for the billing code I strapped myself down and finished the credit card billing code for SeeProjectRun in two days. Throwing two hundred test cases at it proved to me that it will work good enough to get over my fear.
Don’t let fear hold you back from writing code.
Step two: Work with great developers
Now that you’re creating code, you need to work with great developers so you can see how to they write great code.
Just take:
- 1 passionate developer (you)
- 1 great developer (them)
- a dash of code
Mix well daily and after a short rise in the over, you’ll have two great developers. Feel free to add a few nuts (other great developers) and bake again.
You don’t need to search for the greatest developers of all time, you just need developers smarter and further along in their skills than yourself. This can be easy if you work in a company that has hired great developers. But what do you do if your company doesn’t hire any great developers or you are a solo freelancer like me?
Start reading great developers’ code.
I’m making it a habit to start reading great developer’s code. They put out so much code, you will find yourself reading so much of it that you start to dream about code. (Notice that the smart developers are always producing new code…. they are following step #1)
Getting started
Now here’s the call to action, because you will never become a great developer without taking action.
1. Write at least one line of code in a new code base every day for a week. Switch code bases after each week.
This can be a new feature, a bugfix, a refactoring, or just monkeying around with an idea. It doesn’t matter, the act of thinking through the code and writing is what you are after. Don’t know one a good code base to start on? Do a refactoring on Redmine and tell me about it in the comments below.
2. Find a way to learn from a great developer every week.
If you are working with a great developer:
- do an informal code review their last commit
- ask to pair program with them, or
- buy them lunch and ask them about their favorite hack
If you are working solo:
- download some popular projects and read through a single class every week
- get some API documentation that shows the method’s source code inline and read the source each time you look up a method, or
- find a mentor and work with them on some real code
So whatever you do, take action today. Unless you’re afraid of becoming a great developer…
But there is plenty of room at the top.
Eric Davis
Love the “write more code” point. So so true. Practic makes perfect
Yes as long as practice is doing actual coding and not reading about it in books. Reading is just another excuse that prevents us from doing work.
Hmm, again, in the same vein as my last post – love your advice, not digging your attitude. “Doing work” is not everything, and reading books (I assume you refer to programming-related books) is a low barrier to entry way to read annotated chunks of good code (depending on the book). You even recommend reading code – is it the annotation that you do not find helpful?
Let re rephrase that: “Reading programming books about code can be just another excuse.” If you are reading for fun then it’s useful if you are enjoying the book.
But you can read every book on Ruby programming and still not really know Ruby. Taking some kind of action, even if it’s doing the exercises in the book, is required in order to move beyond beginner.
I also found annotated chunks of code from books to be 1) missing a lot of context and 2) gloss over many details. It’s a limitation of the medium, you can’t print the entire source code for an application and it’s libraries. But if you are reading the code on your computer, you can drill down into library code and see why it’s used like that.
Great post! I loved this! Having silly excuses is the #1 reason why we don’t pursue our dreams. I love when someone says it like it is.
You have a typo in the first paragraph:
—
but it’s a pattern many I’ve seen many other great developers follow.
—
I think you meant:
but it’s a pattern that I’ve seen many other great developers follow.
Sean
Thanks, I’ve corrected it. Just like code, the best way to get better at writing is to write more.
Great advice. Not digging your conclusion that “not enough time” boils down to fear. Sure, it could be that. Or it could be that you do other things in the evenings and on weekends, and you *literally* don’t have the time – after all, time is very limited. Or it could be that you are spending that extra time with friends or loved ones. Or perhaps you simply find that it increases your happiness to spend that time lounging, consuming entertainment, reading books, or anything else. None of these have anything to do with fear – simply prioritization and balance. Everyone has to determine this balance for themselves, but I hope that it is possible to be a great developer without being *only* a great developer.
I agree about priorities and balance. But if becoming a great developer is a priority, you will need to stop doing the time wasters we all do. If you can kill a 15 minute time waster and replace it with writing code every day, you make a big impact over the long term.
It’s questionable about whether I am a going to become a great developer or not… but it’s my experience that great developers are those that write less software.
Knowing when to keep the fingers off the keyboard is an important trait in a developer… and I’ve worked with many decent developers that never seemed to figure this out.
Knowing when to stop coding is an important skill for sure. But I’ve seen a lot of the opposite myself: developers who want to talk about their code and never get around to creating anything.
Once they write some code, then they have something to look at and decide if they could write it better or clean it up. This is where the second part comes in: getting feedback from other developers to make that code better.
Nice post! Thanks for sharing!
great article, Eric.
Awesome, I share the same fear but maybe with a lot of tests it’s dissapear. I recommend two books about being a better developer: Clean Code and Clean Coder.