I have been thinking about excellence for the past couple of months, since I’ve starting working full time again. Excellence in writing code, designing systems, and formulating problems.
Last week I had the opportunity to attend a talk titled Relatively Painless Technical Excellence from J.B. Reinsberger. It was one of the best talks I’ve heard on agile and software engineering. I have to start by saying I didn’t have much expectations about it, and I was positively surprised by the content. J.B didn’t talk about frameworks or tools. Instead, he discussed problems and micro-tips. Things we can do in our routine, here and there, to optimize our work for our teams and ourselves.
This came at a perfect time for me, and so briefly, here are some of key take-aways I got from the talk. Please note that what I write are my own interpretations.
You’re doing too much
If you feel you have a busy schedule, running from meeting to meeting, talking to people everywhere to the point you feel you’re not being productive, you’re probably doing too much.
It’s obvious, in hindsight. But in the moment, you can easily get distracted in trying to juggle things. There is probably a good chunk of things on our mind or agenda that are eating up our time and are 100% unnecessary, i.e. the world would move just fine if we didn’t do them. It can be a single event, like that regular meeting where nothing gets really decided or done. Or it can be 10 different things eating up tiny slices of our day, but when added up can give an extra full hour.
And what can you do with that extra hour? Use it to learn. Become better at what you do. Optimizing time is about finding things we don’t need to be doing and doing away with them. The more we slash, the more we gain.
Knowledge is the bottleneck
There are many instances where a team can end up in a situation of being completely dependent on a single or few select persons. Whether it’s that one person that knows how to deploy your code. The one person that setup all the backup scripts. Or the two people that built the entire system on their own. Knowledge is great. Specialization makes you faster and better at a specific thing. But there comes a time when this gets problematic.
You get a new recruit and they need to be onboarded on existing projects. Or that person goes out on vacation. Suddenly, everything is at a standstill. All work that depends on those tasks that only that one person can do is stalled. Knowledge becomes the bottleneck. There are ways to work around it, though.
Unless you specialized in synthetic mutations for genetically engineered cells of dinosaurs for the first generation after the 3rd great evolution, then there is a good chance what you know can be taught to other people on your team. They may not become as efficient or knowledgeable on the topic, but people around you should understand enough so that they don’t have to depend on you. This can remove potentially serious blockers from your team. It optimizes for the group and for your personal time, because now you don’t have to worry about not being around or being the only one getting paged at 1AM. And chances are, your product process can become more robust because of that. So if knowledge is your bottleneck, than you should look for ways to counter it. Pair programming is great way to address it. It may feel slow and painful at first. That means it’s doing it’s job, which is to highlight discrepancies and gaps of knowledge in the team. Try it out.
Document and re-design
Whether you agree that code is a final design document or not, it is not uncommon to refer to source code to understand what an application or system does. Sometimes, though, we end up with more questions that we had in the beginning. Why is this step necessary? What’s the logic behind supporting this one use case (e.g. impact)? When this happens, we start searching. Searching for Wikis, design decision documents, and then people. The people that first built the system or anyone that currently maintains it. We can’t avoid the search, but we can reduce the time it takes for people to find things. If you’re implement something that you yourself wouldn’t understand why it’s there 6 months from now, then you need to add more documentation. In the code. In the repo. Anywhere where someone might go and look for it. This last bit is important, because it’s what saves everyone’s time. And in the end, it makes our own lives easier.
For a similar reason, we refactor code. Refactoring is reducing costs of future maintenance and growth. The current design no longer supports an expansion. We just added a new garage, and that made us realize we’re gonna need extra floors. But the base structure can’t support it. So we refactor. Change the support pillars. It’s painful now, but paves the way for the needed expansions to come. Or maybe the whole design is too complex to understand. So we need to simplify it. Make it more accessible for new contributors. If too much is happening in a single module, then maybe the current analogy for the system isn’t the best one. So we should come up with a better one.
Closing
None of these things should be done just because. You should try them if you find yourself facing these problems, feel that you need to improve and think these techniques might help. If not, figure out what works best for your team. In the end, it’s all about optimizing for the team. Focusing helps you make the best use of your time to grow your skills. Pair programming brings to light your main pain points in knowledge sharing; and it helps you learn to articulate your thoughts, because you have to explain to another person why you think you should implement it that way. And finally, documenting and refactoring is about saving people time in finding things and re-cementing the foundation of your system, both of which are critical to software engineering. After all, with each new line of code we write, we give birth to new legacy code. And someone is gonna have to maintain and evolve it. That someone might be us. Or one of our colleagues. So why not make ours and theirs lives easier?
I wanna thank J.B. Reinsberger for discussing these talking points. I hope you find them useful to your team.