Or “No Correct Solutions: How Engineering Actually Happens”
I’m currently training for a marathon, so I’m out at stupid-o-clock in the morning to get in a training run before work. However, this gives me time to listen to some stunning podcasts.
This morning, I listened to the CoRecursive podcast with Greg Wilson about his views on software design and software architecture. He talks lucidly about how undergraduate or (non-CS) software engineers aren’t taught to debug, they aren’t taught to give constructive reviews often, and they aren’t taught a language to describe what they are building. In fact, us software engineers lack a language to describe what we are building aside from design patterns and to be honest, those are often misinterpreted or misimplemented.
However, the biggest idea I took away from this episode wasn’t about how we describe software engineering to each other. It was the idea of dark-matter developers.
Dark Matter Developers
Greg mentions dark-matter developers first coming up in a Scott Hanselman post from 2012. But that post references a John Cook post from 2010, which then mentions this idea coming from a Kate Gregory interview where, as John says:
She likes to call C++ programmers the dark matter of the software development world. They’re not visible — they don’t attend conferences and they don’t buy a lot of books — and yet there are a lot of them.
I’ve run into this concept myself when I’ve coached or consulted with teams of developers. Most people don’t actually care about abstract concepts around process, the latest thinking on X or Y, or have an opinion on framework or technology. They are just there to do a job.
Likewise, I often find that I’m too much of a cynical, hard-bitten developer who has been through the mill of various agile transformations to give two hoots about what people say. Consequently, I feel like a hypocrite preaching a methodology in front of an audience.
Because ultimately, I know that there are no right solutions.
Occasionally Important Decisions
So, just like Kate, or Scott’s or Greg’s Dark-Matter Developer, I have been that person who hasn’t read a blog, read a book, or attended a conference for long time. Conversely, I’ve also been the person who has attended the talk, or given the talk, or read the book or got excited about the book or the framework.
Ultimately, I can be both of these people at different times. I can work with others who have come to our amazing team or community for their own reasons. But fundamentally, we’re there to solve problems, right? We’re not necessarily always there to argue about the details of one technology decision or another. As a wise person once said: “Know when to pick your battles”
So, at the end of the day, having opinions and communicating them effectively can influence the direction of our software. Sometimes, as individuals, we care about an opinion enough to want to make it happen, and sometimes, we’re happy enough to follow someone else’s decision.
So, do decisions actually matter in the context of a team who are deciding about the future state of a piece of software?
The Proof of the Pudding
Think about the time you were involved in a decision around a new framework or a new piece of software. What motivated you to pick one technology over another? Were you interested in learning it? Did you think this would make it more fun? Did you want to do it in something where you felt more comfortable or respected? Or did you really have no preference? Was it mandated by the company, an architect or perhaps your boss?
And then, what do you find when you’ve stayed around long enough to see the impact of these decisions on the software systems?
Do these decisions often have long-lasting implications for the quality of the software over the course of a project, a product iteration, a release, or a year or two?
With all options being mainly equal, we can then start to understand that most decisions we make about language, toolkit, architecture and so forth are pretty meaningless.
For example, I once built an app in Angular 1.x which was then completely deprecated by a Angular 2.x and the codebase needed to be rewritten. With the benefit of hindsight perhaps I wouldn’t have chosen Angular 1.x but it in the meantime allowed me to write a modern web app
Time is a Great Healer
On a long enough timeline, all solutions are valid, even those crappy ones you think won’t last five minutes in production. How can they be invalid if they work and continue to work?
So which is it? And what does this make me? Am I (and you) a ‘dark matter developer’ who fundamentally doesn’t care about the future of our product but is only there to make up the numbers?
No, of course not. We care. We have a limited amount of energy to spend on discussions. So, use your experience to know that the decisions we make fundamentally aren’t always that important.
So:
- Pick your battles.
- Be realistic enough about the impact of new technologies.
- Don’t worry about technology decisions or code reviews going “against” you.
- Know that the real work gets done outside meetings.
- Don’t (always) seek to persuade.
- Embrace both the difficulty and the beauty of coding.