December 12, 2019
Arien ‐ Head of Software Engineering NL
I like nuance. It leaves room for discussion. I recently read an article criticising Go's (the programming language) take on simplicity. It states that Go’s maker, Rob Pike, does not trust the average developer with the full expressive power of a complex language. And that’s the reason Go is such a simple language. The author takes issue with this, because they see this as insulting to developers.
What does this have to do with personal development? A bit of thinking and a few Reddit comments later, I realised that simplicity is something you really start to value when you’ve seen a good deal of self-inflicted complexity. Programmers learn from mistakes. They’re pretty smart. So, as you become more experienced, you start to develop a “sixth sense” for over-engineering and incidental complexity. One day you wake up and think: “what can I do to solve this problem?”. Well, you’re a programmer, so you make a new tool, library, framework, or programming language. If only you could prevent others from making your mistakes, you will have made the world a better place. Hence Go.
So, is the average programmer average? By definition: yes. Will they make mistakes, learn from them, and, in so doing, become less average? Undoubtedly. Well, then we shouldn't take from them these learning opportunities. Nor could we. As we know, and Fred Brooks once asserted, there is no silver bullet that will solve the complexity problem. So, learn you shall! But should we then give all developers free reign to use complex techniques and technologies as they see fit? That doesn’t sound right either. The truth (almost) always lies in the middle. Nuance can be so uninspiring, I know.
In good times
In the marines, they teach you how to use a rifle before giving you one. There has to be room to learn, but we need some safety guarantees in place. There are cases of conference driven development. Or simply wanting to play with the latest trendy thing. In those cases, and it might be a tough pill to swallow, it should be OK to just say: “No, we’re not going to do that”. But sometimes it’s not so clear. If a developer in your team wants to try something new, despite your sneaking suspicion that You Ain’t Gonna Need It, maybe you should let them do a little bit of it. Who decides when, where, and how much risk we are willing to take in order for an individual to learn? Ask the person paying for the developer’s time, and you’ll likely get a “Not on my time”. It has to be integral to the way you work. So then how?
Ideally, the tech lead will help define the parameters within which developers are allowed to experiment and fail. And they would make sure the developer gets the support they need to increase the chances of success. If you want to play with server-sent events? Manage the risk by defining server and client modules that hide the implementation. Perhaps a developer wants to build the new product on Kubernetes, but they've never used anything like it before. Container formats being standardized and the fact that there are multiple platforms to choose from, makes this a choice you could potentially change. As long as the team is willing to admit and accept that for the ease of deployment they pay the price of technological complexity, then perhaps this is the place they should start their Kubernetes journey. Some technologies have survived the hype. If you keep them out of the hands of developers too long, you will start to lag behind as an organization, and your developers will resent you for it.
In bad times
However, what if you’re in a situation where simplicity is not yet a core value. Or only in principle, but not in practice. For example, a team full of young hopeful individuals, that have yet to develop the “complexity sense”. Or perhaps, a team that is simply keeping a product alive. Where people feel that it’s “just a job”. In both scenarios, complexity is going to grow unconstrained. Those situations require simplicity be more strictly enforced.
Take as an example a platform team enforcing that service teams can only use a fixed set of dependencies. Harsh? If you take it personally: yes. Effective? If executed well: sure. Such rules and their tone (think “us v.s. them”) with which they are enforced are hard to get right. Unless someone on the team is fighting the software design entropy, those rules and processes will be set in place by the powers that be. You don’t want to have that happen. So, you should try to prove to the outside world that your team is capable of managing complexity on its own. Then the room to learn and try new things will appear.
What about getting a training? A good training is educational and inspiring. They can be great. But you must know how and be able to apply it. Otherwise it’s just frustrating. Bridging the gap between a workshop and real production code is difficult. Training that happens outside of projects should not be the only place you learn. The way I see it, professional development is a natural progression that comes from applying your craft.
Spotting learning opportunities
Imagine someone telling you what code you can and can’t write. Imagine them telling you to throw away a really clean abstract parent class that you wrote, because “we don’t need it, it bloats the code, and it’s cheap to add it later”. You might start to hate that person, even if you think he/she's right. And I realise that someone reading this might think I’m a jerk for even suggesting such “regulation”. But personal development is personal because it’s about you. Not because you can do whatever you want. You have a job, and you take pride in doing it well.
If you had to choose between learning something new at the expense of the project (and your team), or not learning anything at all, then you’d be stuck in a nasty place. Fortunately, that’s not how it works. Think about personal development in terms of finding the area where personal learning goals, the added value of that learning to the project, and the value for the customer align. When you see the bigger picture, and personal development’s place inside it, then you can start spotting opportunities to learn. It puts you in the driver’s seat. And that’s a good place to be.