How To Be a Developer
The things you do to become a better developer
I’ve been doing development now for a long time; I enjoy it, and it’s something that I’m good at; that statement could easily be switched around, I’m good at it, so I enjoy it. Regardless of how it is now, it was still something that I had to learn how to be good at it. For me it was always about acquiring a set of skills and a methodology for approaching a problem. These are the things where simple things like having been taught how to learn can help. I learnt Modula-2 at university; of less use than COBOL in the real world; but it taught me how to learn a new language, and I’ve applied that knowledge everywhere I’ve worked. The skillset that you acquire through your career will be quite varied but the methodology is always invariably the same.
Know what you’re trying to solve
If you don’t understand the problem that you’re trying to solve, then no matter how elegant, how concisely expressive or how brilliant your code is. It’s just not much use to anyone. Breaking down the larger business problem into smaller digestible chunks is fine, but then handing that off to a junior developer without giving the context of the problem is a mistake. You end up with hundreds of lines of code that don’t do what you want, and if it does, well that was probably luck rather than judgement. Management invariably view development as simply an exercise in a production line; but it really isn’t; a lot of this is our own fault as we often use manufacturing analogies when describing development to management. The dev-ops culture that has started isn’t just about the disconnect between development and deployment (big as though that sometimes is); a skilled developer need to understand the business value that they’re adding and the problems they’re trying to address.
Understand he tools that you have
If you say you’re a java developer, and all you know is how to do mvn package, then you’re not really a developer; if you’re a C programmer and you can’t write a makefile, then this is a problem. You’ve not shown a willingness to learn about the tools that are critical to your job. If you invest the time into learning about the tools, then you’ll be able to use them more effectively; you only have to learn it once. You need to know about your target deployment platform; how to navigate it, how to set it up, what limitations it has. It’s not part of your day job (if there is such a thing) but knowing these things will make you a better developer with a better understanding of how your code impacts the rest of the business.
Be open to new ways of doing things
You’re just a developer, you don’t know everything. Things change quickly and you need to be aware of what the new things on the block are and how they’re going to deliver your next project. What you’ve always done, isn’t what you’re always going to do. A large scale project I’ve had to work on involved developers who only knew J2EE style applications; the deployment platform wasn’t J2EE and yet they insisted on treating it as though it was. What got delivered was an unholy mess, it wasn’t scalable, wasn’t testable, even the happy path barely worked. Things like this don’t give developers a good reputation.