A few weeks ago I wrote a post about being a technical architect, and one of my main conclusions was that you need to stay technical. But how?
Phil Wills had a suggestion for me:
@annashipman one of the most important things I did, a long time after becoming an architect, was to stop going to recurring meetings.
— Phil Wills (@philwills) March 1, 2015
At QCon, I asked him more about this. Did he mean all recurring meetings? What about retrospectives? What about stand-ups? We ended up having a mini Open Space of our own, joined after a while by a couple of others, and then Phil proposed a session on ‘how to stay technical as a senior techie’ at last Friday’s Scale Summit. Here are some of the thoughts I got from that session.
Whether by “the job” we mean technical architect, manager, or senior developer, there was broad agreement that being interruptible is an important part of it. You are in that position because you have the skills to help others and it might be that interrupting you saves other people a lot of time. Twenty minutes of your time on a problem you’ve seen before could prevent someone else spending two days stuck down a rabbit hole, for example. So you need to learn how to be interrupted: how to minimise the negative affect interruption has on your own work and enjoyment of it.
A big problem with being interrupted is the loss of context, and we talked a bit about how to mitigate that. One suggestion that comes up frequently is blocking out time, e.g. core pairing hours. This may not work if you can’t always pick the times of meetings you need to attend but can certainly be useful when you can.
Another brilliant suggestion was around doing Ping Pong pairing. The reason this helps is that if you do get interrupted, your pair can carry on without you – this is not ideal, but if the interruption is unavoidable it does mean that the work continues and it’s relatively easy for you to reload the context when you return.
Other suggestions included working on smaller pieces of code, for example bugs in your issue tracker, rather than large features; and making sure that the code you write is such that you can keep it in your head. Finally, working on supporting tools that aren’t on the critical path can be a good way to keep coding without potentially blocking the team’s progress.
Staying technical is not just about writing code, and we talked about some other ways of staying current. Some people found doing Coursera courses useful, though this does require a huge time commitment, usually outside of working hours, so won’t be sustainable for many people. Reading code, rather than writing it, was suggested, along with keeping up with what people are working on in the ticketing system.
One person talked about the company organising a regular Coding Dojo which seems like a great way to keep everyone current on what is being worked on. Another way to do this is mobbing, or mob programming.
The main way I stay current, which I don’t think was mentioned in the session, is via Twitter and some newsletters like Devops Weekly.
We finished up with a really interesting discussion around why we were all so concerned about staying technical, and it turned out that many of us were worried about losing what it was that had made us senior in the first place.
People pointed out that being senior is not necessarily being able to write perfectly in whatever cool new language recent graduates are using, it’s reasoning about problems. You are in a position to use your knowledge of similar problems to cut to the heart of the matter, and you can use your experience to ask the right questions.
Practical suggestions included using Socratic questioning to draw out problems people might not have thought about yet. “What do you think the solution is?” “Why?” “What would you do about X?”. You also should not be afraid to say when you don’t know, and “let’s work it out together”.
But for me, the take-home message here was best summarised by Robert Rees, who I quote with permission: “The fear is that you lose authority as you lose expertise, but actually that’s not true: authority comes from having delivered many projects.”
I found the discussion really useful and have some practical tips to take away. It was also nice to know that there are many others facing the same issues as me. Thanks to Phil for proposing it and to all who took part!
If you’d like to be notified when I publish a new post, and possibly receive occasional announcements, sign up to my mailing list:
