“The candidates must have at least three years of Java development and experience with four of the following five technologies…”. This is how a typical request for consultants goes, both for public and private sector customers. It clearly favors candidates with long, stable assignments behind them. It seems to be commonly accepted in our industry that the most important quality a developer can bring to a new project is experience. That may not be such a good idea.
The underlying premise here is that training makes you a more effective developer. That may be true, but only to a very small degree.
The problem is that deep tool knowledge is not where the biggest gains are. Software development is just not that trivial.
I have seen teams that have success based on criteria that are different from this kind of experience. A developer with 4 different projects in a 2 year time span take along more good thoughts than one with 5 years of experience with the technology being used. A fresh graduate with nothing to defend often asks those stupid questions that makes the rest stop and think. One who is attending meetups and reading relevant blogs takes along experiences others have gained without having been there himself.
Efficiency is not first and foremost dependant on the speed with which you can code because you have long experience with a specific tool. Efficiency comes with the one who asks if we really need to use the framework we have taken for granted. It comes with the one that had heard of the tool that ends up saving the team for weeks of work. It comes with the one who takes the time to think clearly and simplifies our process and makes everyone more productive. The efficient developer thinks like an innovator.
Development is innovation, and the best developers are innovators. The good news is that you do not have to be among the very creative to think new thoughts. You do not have to be fresh from school to ask the stupid questions, and you do not need experience from many different projects to be able to draw on other people’s knowledge.
You too can be innovative by paying more attention to how innovation happens.
Jeff Dyer, Hal Gregersen and Clayton M. Christensen have coined the term Innovator’s DNA. They have, based on extensive research, uncovered what practices and techniques the most renowned innovators use to come up with new ideas. The conclusion is that innovation only to a small degree owes to genetics, while it to a much bigger degree is an effect of how you behave.
So, to become a better developer you can use some of the five techniques they have described:
1) Associating. Connect seemingly unrelated ideas, questions or problems.
2) Questioning. Don’t be afraid to look stupid. “What would we do different if we only had half the time we do now?”
3) Observing. Meet up with the guys at customer service. What are people complaining about?
4) Networking. Talk to people with different backgrounds. Can you use their insight?
5) Experimenting. Create a prototype, set up an experiment, do an A/B-test.
When we hire at Iterate, we don’t just look at people’s experience. We try to find their intrinsic motivation, their desire to create something, their eagerness to play and experiment and their drive to continue learning. We value and grow the factors that make you an innovative and excellent developer.
Great writeup and topic!
This reminds me a lot about something that inspired a lot me a few years back. “Know as much as possible about what you don’t know”. Not knowing you don’t know is were the perils are.
How often haven’t you read a book and applied that knowledge? What if you didn’t read that book?
Developers that tries many languages, tools and patterns are the ones that become extraordinary.
Why would you not want extraordinary developers? 🙂