Great development is about more than code

Most developers start out focusing solely on learning how to write code; usually a specific language and specific techniques. I started out with BASIC; spending many hours tinkering with games and graphics. I loved creating things just to see if I could create them not because there was any need to do so. 

Later I used the same approach to learn the syntax and capabilities of Java. It was easier this time, many of the skills I’d learned from BASIC were applicable despite the language differences. As my knowledge increased I created more sophisticated, and complicated solutions. I felt like I was becoming a better developer and I was, but I still wasn’t what you would call a good developer.

It took many years for me to really appreciate the importance of fully understanding a problem before even thinking about the solution. Spending time, often way more than you feel comfortable spending, thinking about the problem before writing a single line of code is hard. It feels counter-intuitive to see a problem and not immediately start trying to solve it. Experience taught me that good code design does not come from writing code.

Believing that complicated code is better code is a mistake, and one commonly made. Good code is the right code for the problem. It’s the right code for the team (language, tools, level of documentation), and it’s the right code for the problem (testability, maintainability, extendability). Often that means that the best code for the job is the most boring, simplest code. The kind of code that anyone in the team can pick up and work with.

Great developers are those that can see a business problem, collaborate with others, and design the simplest solution to get things done. They’re able to balance their time to support others, investigate ideas, as well as writing code. Being proficient in the language is a big part of their success, but it isn’t the only part. Anyone wanting to increase their development skills needs to look past simply writing code and start learning how to design great (simple) solutions.

2018 in Books

Books_of_2018_-_Google_DocsSometimes we read the book we need to solve the problem at hand. Other times we read a book and only afterwards see the situations that it has taught us to see.

2018 was a little lighter on reading than I would have liked but I did discover, and rediscover some gems.

First up was a reread of The Phoenix Project: A Novel about IT, Devops, and Helping Your Business Win. Five years on from its first publication and it’s starting to feel a little dated but still an excellent book with relevant lessons. Focusing on flow, and making work visible were key takeaways for me this time around.

Next up I read, and loved, Powerful by Patty McCord. Patty writes about recruiting, motivating, and creating great teams based on her experience developing the culture at Netflix.

What takes the place of rules, processes, approvals, bureaucracy, and permissions?” The answer: Clear, continuous communication about the context of the work to be done. Telling people, “Here’s exactly where we are, and here’s what we’re trying to accomplish.”

And

“You want to be a lifelong learner; you want to always be acquiring new skills and having new experiences, and that doesn’t have to be at the same company. The fact is that sometimes you’re hired by a company to do something, and then you do it and it’s done. If I hire people to rebuild my garage, when they’re done I don’t need them to rebuild the back of my house.”

The most practical book I read in 2018 was Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, Jez Humble and Gene Kim. This is a book crammed full of tips for helping teams achieve success, I particularly appreciated the focus on burnout that threaded its way throughout the book. Important reading.

Radical Candor by Kim Scott was my book of the year. “Radical candor is the sweet spot between managers who are obnoxiously aggressive on one side and ruinously empathetic on the other. It’s about providing guidance, which involves a mix of praise as well as criticism—delivered to produce better results and help employees achieve”. There are many, many great stories and transferable tips shared in this book. A joy to read, and a book that has changed the way I manage and want to be managed.

I ended up highlighting most of the book but this quote neatly sums up how it made me feel

“If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea.”

My final book of the year was Switch by Chip Heath and  Dan Heath. Years ago I struggled through Thinking Fast, Thinking Slow, enjoying the message but finding it hard to recall accurately. Switch does a great job of sharing the same message in a far more accessible format. I absolutely loved the Elephant and the Rider metaphor to describe our minds, and I found the stories in the book to be interesting and highly motivating. I can’t wait to put these ideas into practice in 2019.

How was your 2018? Did you discover any books worth shouting about?

The Reverse Pilot

Growing effective teams requires a lot of experimenting. As people join the team and grow they’ll change the team dynamic. New ideas will be suggested and new difficulties will appear. Adapting to proposals and challenges naturally leads to changes and it feels productive, and positive to introduce new ways of working.

When we look back on situations we tend to focus on what was missing. Missing requirements, understanding, or more practical things like missing alerts or monitoring. We add in extra technology, or meetings, or process to try to fix the problems we see.

It can be easy to forget that sometimes we need to be removing things to be more effective.

Measuring Change

When we introduce processes or tools we usually bring them in after considering the options. We agree on a trial period and consider who needs to be involved in the trial. Usually we’ll have something to measure, or assess to give a measurable assessment of the change.

If we don’t see the hoped benefits, or especially if we experience new discomfort from the introduction, we’re happy to abandon our experiment. Abandonment doesn’t necessarily mean we give up entirely, instead if the pain is bad enough, we might seek out a new change or tool to achieve our goals.

Critically assessing our current tools and process in the same way could bring similar benefits to team effectiveness.

Learning By Doing

I once worked on a team that was having difficulty releasing our code. Building and testing each release was painful, the actual release itself took much longer than expected, and we often had unexpected problems once we got the code into production. Each time we hit a problem we discussed what had gone wrong and usually added another safeguard to the process.

Over time we Introduced sign offs from the design team, the product team, and the test team. We become more cautious about who could release and when. Releases became less frequent to reduce the impact on customers. Eventually we ended up with a slow and inflexible process that made releasing anything at all painful and stressful.

It would have been easy to keep tinkering with the existing process and most likely adding more safe-guards and checks to try to improve the quality of releases. Experience tells us that when things are going badly we’re missing something and we keep on adding steps and tools to our process until things work.

Luckily a new team member came in with fresh eyes and forced us to step back and re-evaluate. Instead of trying to improve our current process we went right back to the beginning and evaluated what we wanted to achieve. We defined the values that mattered to us, and we worked out what success would really look like. Afterwards we designed a new, totally different, process that met our values. Surprisingly it removed almost all of the safe-guards that we previously thought were needed to make releasing safer. The result – a process that actually did what we wanted it to do, and ended up being more effective than our original one too.

Take An Intentional Step Back

Taking the time to step back and consider exactly what you hope to achieve with your process is a great way to start cutting it back. A daily practice like standup can become a habit without necessarily achieving the goal of improving team communication. Realising this is the first step towards experimenting with alternative communication styles. Take the time to define your values and then assess your current approach against these values. Are you meeting them? If not, why not?

Focus On The Small As Well As The Large

Not all change needs to be large to have a significant impact. Sometimes a number of small changes can have a far bigger result and will almost certainly face less resistance than a single big-bang change. Skimming off small but unnecessary tasks will save you time and lead to a streamlined, effective culture.

I once produced a weekly, company-wide, email newsletter to summarise all the changes that were going on in the Technology department. I described the experiments we were running, translated the technical release notes into English, and explained why these changes were important for our users. The newsletter took a lot of time and effort to produce. Often the technical description of releases was meaningless, and missing the critical ‘why’ explanation. for each one I had to track down the original author to find the answers I was trying to give to others. Once I had the details I had to write the email, create and attach screenshots, and email it out.

People were reading the email but there was no real feedback. Even more significantly I couldn’t see any change in behaviour as a result of the email. I still had to hunt for the information I wanted, and the recipients still asked questions about things that I had covered. The email didn’t appear to have the impact I had hoped so I decided to run a reverse pilot and simply stopped sending it.

A week later and nothing. No one asked about it. The questions about technologies changes were the same. I took that as a positive result to my own experiment. If the email wasn’t missed then it clearly wasn’t adding enough value to justify the time I was putting in.

Several years later someone asked me why I didn’t send the emails anymore. They remembered the email and had found it useful. Not useful enough to follow-up when I stopped writing it, but useful enough to remember it having existed. Together we found an easier way to produce a shorter email that provided ‘enough’ value without taking so much time to create.

In Summary

Finding the ideal tool or process takes time and will likely require us to add or remove a number of steps to get to the ideal place. The “reverse pilot” provides an easy way to test out whether you can remove things from your process. Approach it in the same way you would an introduction of a new tool or process and be prepared to reinstate the change if results show that you should.