In the first part of this series I indicated I would be asking some of my developer colleagues to give me a few points on what it takes to be a solid developer (Not SOLID as in the OO principles by Robert C Martin). Originally, I thought I would summarise the responses into a short essay, but the quality of the responses was too good, so instead I have just grouped them into broad categories. Also, I think its important to pick up some of the trends from the responses so if you see an item that has been repeated you’ll probably get the idea that it’s a significant issues for a number of developers. Some minor editing and formatting has taken place.
Humility & Growth – that might sound like I’m being a bit hypocritical 🙂 but at the end of the day you need to learn from people who know more about any number of subjects than you. It might be new tech like mvc, generics or just business process. It might be in-house tech that the junior guy you work with knows back to front. But most of all be prepared to go back to square one and adopt new techniques like you did when you were starting out.
Objectivity – the ability to stand back and look at a solution from somebody else’s viewpoint – maybe that the business stakeholder or another team. A good developer will and should eventually be a good analyst / designer so think outside your problem and assess downstream impacts and risk. A problem thought through and solved is much cheaper than a problem built, tested and solved.
Stay Sharp : Invest time in and out of work hours in monitoring the industry trends and cutting-edge releases (both source e.g. MS/java/jquery etc) and peers (e.g. New Sites, apps and other public release). You might not get to use it in the short term but when the time comes to offer up new tech you’ll be ready
Ability and willingness to learn.
Be a good listener.
Develop and Maintain Knowledge.
Work out who are good programmers, watch what good programmers do, Learn their patterns and practice their technique
Don’t be precious : Sometimes you have to sacrifice your principles to get something out the door. Project influences will quite often not align with your idea of correct process. The good developers know which corners are being cut so they can be back filled when the time is right.
Ability to understand the needs of the business, not just what they ask for but what they NEED.
Deliver a solution that makes their lives easier. Not what is technically easiest making it hard to use while still meeting the business requirements.
Be pragmatic – not wedded to any single way of doing things. Willing to explore alternatives.
“It’s not the tools or framework but it’s the knowledge and principle which will take you far in your career” . So dotnet may stay or may go ..maybe Adobe will be a programming platform ..may be microsoft will fail and become extinct. But if you have the right knowledge and principles then you can pick ruby on rails and will start programming in a 2 weeks. Like my great, great mentor used to say …any technology is just 2 weeks away if you put your heart and mind into it, and it just starts with a simple “Hello world”.
Be Agile : No not the programming nor the methodology but the Agile way of thinking.
Ability to write simple clean code that can be easily maintained.
Have a good eye for defensive programming – i.e. expect things to go wrong, test your input parameters etc, but be realistic about it.
Ability to make changes to an existing system without rewriting it.
Understand implications of code changes (and know when to hold back due to those implications).
Understand patterns and be able to apply them. Good programmers use them without even thinking about them.
Have a basic appreciation for ‘usability’ – spends more than the 3 seconds it takes to drag buttons on a form thinking about how screens / pages hang together and how the end user is going to interact with their software.
A simple solution is a good solution. Keep it simple. Test it.
When given a task understand the big picture. Research and then come back with a few key questions.
Be driven by finding solutions – strive to be innovative – don’t ask the business to change their requirements because you are too lazy / not good enough to make it work.
Take pride in your work – like a top chef who wouldn’t send out a meal they aren’t happy with, a solid developer won’t flick something to the test team without being happy that they have thoroughly tested it themselves first.
Ability to problem solve and research.
Recognition that you are not the smartest guy in the room (willingness to re-use other people’s solutions).
Know your smell (and When in Rome do as Romans do). When you are working in a team/or organisation there are times when the managers/PM’s may not appreciate your work, style, work ethic etc. You should try to detect this. When you detect this, be prepared to change (either your job or the way you work).
Be a team player.
Take the role of the follower / leader (based on your role in the team).
Understand your role in the team. If you are the grunt developer on a project don’t try to take over the lead role. If something eventuates for you in a different role for another project that’s great.
Ask the right questions.
Challenge yourself. Get out there and work in different industries, companies and projects.
Having significant experience in multiple environments (organisations) is very significant.
I am planning a third and final part to this series where I ask my mates for tips on how the junior developer/graduate/newbie should enhance skills to become the solid developer.