Software development is hard. Its one of those things that can be highly appreciated when the complex appears simple or easy. Sure, talent means a lot. But do you think Micheal Jordan or the Williams’ sisters could have dominated without working hard? I can swing a tennis racket and shoot a basketball, but do I possess the wherewith all to be successful at these sports?
So at this point we can agree that being a good software developer is more than skills. Okay, great. Who decides on what is “good” or not? I submit to you its your clients or those that interact with you, in other words, people. And if you develop software for a living, it boils down to value, which is basically a judgement about the amount of money that something is worth.
“A plethora of certifications and all the latest buzzwords can only get that potential client to your door (or an interview). If they do not believe they can work with you, they won’t”.
So as much as we can love “being in our own head” (you introverts know exactly what I mean), we cannot be closed off to what is going on.
What do I mean by “what’s going on”? OK, back up a bit. Before funding was approved to bring you on, your client(s) drafted an idea. We presume the idea has enough merit to justify spending funds that will ultimately bring about a desired result: profit. No business spends money just for fun. It (the endeavor) becomes necessary to position your client for the desired result. So the activities leading up to your work revolve largely around people. Meetings, email, phone calls, and the like all purposed to convey what is required. This requires us to be responsive enough to make certain we understand. This is where our behavioral skills really come into play, not just with the client, but within our teams.
In the end we should be of the mindset that if the client is not successful, we cannot be successful. Of course, its not a one-way street. If the client shoves us crap (incomplete requirements, overly aggressive deadlines, minimal feedback, etc.), its likely that crap is what will happen. But! We should be professional enough to warn them of whats coming sooner than later with suggestions for getting things on track. Success is a two-way street.
In no particular order, my shortlist of what makes a good developer:
1. Coding skills: But beyond knowing syntax, understanding that sets of code will need to be maintained (and not necessarily by you), which means opting for straight forward coding as opposed to obscure, tough to read/debug code. This includes basic fundamentals like separation of concerns, don’t repeat yourself (DRY), and all that good stuff.
2. Ownership: Take full responsibility for your assignments and work packages.
3. Community: When working with a team, taking time to understand the end goal and how your pieces fit in. Further, being aware of how the team is doing towards this goal. What I mean is, you may not be the Project Manager, but realizing that the team cannot be successful unless everyone succeeds. Lend a hand.
4. Get rid of the hammer: “If all you have is a hammer, everything begins to look like a nail.” Don’t be a one trick pony. Be curious enough to want to see what’s out there and how it can be used it to solve problems. This should not be too much of an arm twister, don’t we all want to stay marketable?
5. When in doubt, ask for help – ’nuff said.
6. Keep project parameters in mind: Yes, the PM needs to track of
just about everything. But that does not mean you should not have project schedules handy and speak up with something is amiss. Just don’t go away and code.
It feels like I’m pointing a heavy finger at myself and developers. Rather, I feel that as we exude these behaviors we can be in a better position to ensure our clients success. If they are successful, we are successful, which keeps us in business.
Cliff Gardner, CSGardner Consulting