So You Want To Be A Software Developer?

What would you say to someone wanting to be a software developer today? I’ve been thinking recently about how my experiences as a developer have shaped my opinions over the years and thought I’d get them down here for any newer entrants into the development field, especially as my daughter is about to enter her final two years at high school and has chosen to take computer studies as one of her subjects. Maybe it’ll help someone else thinking of a career in software development.

Essentially, I’ve distilled my own experiences down to the difference between pragmatism and dogmatism. When I was younger I just about jumped on every new technology, pattern or practise that was being pushed as the next big thing, thinking “I have to know this” and more often than not finding an excuse to apply it straight away. These days I’m more than happy to look at something new, perhaps spend a few days investigating it, getting a grounding but then I tend to mentally file it away until the day I hit a particular problem that could be solved by it. If that day comes then that’s the time to dig in and explore further.

The truth is there aren’t enough hours in the day to be an expert in everything, or even most things. The trick that I’ve learned is to pick my battles wisely. To me that means less emphasis on technology choices, more on architecture/design principles simply because no sooner have you mastered one aspect of a technology stack, you often find that there’s a new kid in town being touted as a superior replacement. That’s not to say that you shouldn’t invest time in learning new tech because, no doubt about it, it’s fun and exciting. It’s just not wise to put too much effort in upfront because you may never have a chance to use it before it’s deemed old school.

On the other hand, again looking back retrospectively, I’m glad I’ve been interested in architecture and design for as long as I have as I feel the investment there has a much greater pay off. For one, unlike technology, that kind of knowledge stays relevant for a much longer period. Even when it becomes apparent that there are newer, more modern approaches to those same familiar problems, the knowledge you gained in the past doesn’t suddenly become obsolete. If anything it widens your perspective and gives you something to compare and contrast with. It’s also true that the old approach may still be a good approach depending on the context of your situation. Not everything has to be bleeding edge.

Eventually I realized how far ahead of the game the likes of Fred Brookes really was when he said there is no silver bullet. How true. But how come I never really, I mean, really, thought about it deeply when I first heard of it? Why didn’t I take more interest? I now put it down to lack of experience. When I was younger, the technology side of things consumed most of my energy. I was really hungry for new tools and technology, and if I got good at it, I wanted to use it everywhere whether or not it was the right choice. If there was a chance, I’d find a way to use it on a project. Sometimes this worked out well, other times not so well and looking back now I would say that at this point in time I was very much dogmatic about my choices. I used them because I liked them and nobody would persudade me otherwise even if it wasn’t the right tool for that particular job.

These days, the tables have turned and I’m very much more pragmatic about my choices. I want to use the right tool for the job at hand. I’m much more inclined to keep things as simple as possible until the situation demands a more complex solution. And this doesn’t apply just to technology choices either. At one time I had a very narrow opinion on unit testing, whether that be test first or after, or BDD for instance. I just used it everywhere and at the same time got completely obsessed about achieveing 100% code coverage. Eventually I came to realise that that wasn’t always the correct thing to do because despite what some would have you believe, TDD (to quote Mr Brookes again) is not a silver bullet. It’s a damn fine technique to have in your toolbox but if not done correctly it can have a large deterimental effect on the project resulting in a maintenance headache for everyone involved. These days to me, TDD is something I use on the code that has the largest risk/value to a company. I often think about it in the same way that Eric Evans describes the Core Domain vs Supporting Sub Domains in his book Domain Driven Design. As Eric says, “not all of a system is going to be well designed” but the core domain is at the heart of the business and here is where I would choose to invest in developer tests of one sort or another because of the importance that code has to the system. Supporting sub domains however, well that’s where I’d evaluate them on thier own merits and try to determine if the cost/payback is justified. I’ve tried to test every part of a system before and well, the results haven’t been pretty but the cost has been substantial.

One last thing though, recognising pragmatism vs dogmatism can be a hard skill to gain. It’s only after acquiring a good deal of experience that you begin to take a more considered approach. Either that or you’re a very level headed, mature young developer, with a good mentor looking over your shoulder! It’s often the case though many devlopers don’t get that far through either lack of interest or passion. You can often tell this when working on systems that you’d swear were the inspiration behind the Big Ball of Mud architiecture paper written by Brian Foote and Joseph Yoder (Recommended reading for all developers). When you look at these systems, deliberate considered choices are often nowhere to be seen. They’re just one big monolithic mess that was written long ago by developers long gone and it’s now been handed to you to keep ticking over and incrementally improving. The only good thing to come out of these kinds of systems is the chance to be inspired to produce better code yourself and then maybe apply it to improve that said project but without guidance it can often be so demotivating to a young developer that it may cause them to leave thinking that if that is what development is all about, well, it’s not for them (and that has happened with people I know).

We’ll always be faced with new things to learn and apply, it comes with the territory but sometimes we just need to standback and take the time to consider the consequences of our choices instead of rushing in head first. If you’re a lone developer and don’t have a mentor as such then seek out those online considered to be experts in the areas you’re interested in such as Eric Evans, Greg Young, Udi Dahan, etc. You’ll always learn something from them.

There are many things now that still inspire me, yet at the same time cause me to hold back from adopting them wholesale. CQRS and Event Sourcing is an area that interests me greatly but I haven’t yet found the opportunity where they would be the ideal fit but there are plenty of ideas in there that can be used immediately. It’s the same with the whole agile movement. There are many different flavours and rigidly adopting one might not be the right thing to do. Taking the bits that work best for you and your department might be a better approach. No matter what you choose, whether that be tools, technology, architectures, or processes keep in mind that all of them have trade offs. There is no one perfect answer. As long as you keep evaluating what’s working well and what’s causing you friction you’ll arrive at a better place.

In a nutshell, it’s highly likely that despite best intentions you will make mistakes (and that will never change). The key is to keep learning from those past experiences and apply them to the future.

So You Want To Be A Software Developer?