Discovering the path to becoming a great developer is not difficult.
There is an abundance of great material at our fingertips: websites, blogs, code, books, podcasts, and even free online courses. With access to so much good material, if you are willing to put in the time & effort, you will become a standout developer.
After several years of putting in this time & effort, you will be an expert in the “best practices” and trends in software development. You may also find, however, that most of us are reading the same blogs, reading the same books, following the same practices, and generally, agreeing on all of the same trends. This is probably a good thing – we are reaching some level of consensus of good practices and approaches to software development.
However, using this approach, we are not likely to discover our blind spots. We learn a lot, but we’re learning too much of the same things. How can we counter this problem? Possibly re-stated, how do we move from being a “top 10%” developer to becoming a “great” developer, a “star”.
Cal Newport gives this advice for becoming a star:
“In theory, the people who tend to consistently produce important work seem to be those who consistently take the time to decode the latest, greatest results in their subject area.”
For developers, that means we need to take time to read great code.
“One of the reasons that I have routinely been going out and searching for difficult codebases to read has been to avoid that. I know that I don’t know a lot, I just don’t know what I don’t know. So I go into an unfamiliar codebase and try to figure out how things work over there.
I have been doing that for quite some time now. And I am not talking about looking at some sample project a poo schlump put out to show how you can do CQRS with 17 projects to create a ToDo app. I am talking about production code, and usually in areas or languages that I am not familiar with.
Some people can learn by reading academic papers, I find that I learn best from having a vague idea about what is going on, then diving into the implementation details and seeing how it all fits together.”
Notice he says “production code, and usually in areas or languages that I am not familiar with.” This is the same idea Cal Newport stresses – don’t just do the work – do the hard and difficult work that most of our peers do not.
It is clear that Ayende reviews code regularly and then blogs about his findings. Given his successes with NHibernate and all of his new work at Hibernating Rhinos, I think its clear that he is a “star” developer, and someone we can learn from.
* If you’re convinced, Oren Eini also has more tips on reading large code bases here.