Revising My Craft
May 17, 2015
I am revising what I do for a living, in both senses of the verb “revise”.
For the last 5 years I have held the job title of “Chief Technology Officer” - “CTO” for short - at two startups. My roles were hands-on and involved CTOs who aren’t hands-on get very sniffy and insist that hands-on CTOs are ‘not proper CTOs’ many tasks including, but not limited to:
- Stakeholder interviews
- Information architecture
- Systems design
- Writing software
- Hiring staff
- Managing staff
- Systems administration
- User Interface design
- Product Ownership
- On-call problem resolution
- Project management
- Board/Invester liaison
In larger companies CTOs don’t have time to write code and look after systems administration needing to be spreadsheet and presentation deck jockeys.
In very early startups you absolutely have to get stuck into designing and developing the technology - you may be one of only 2-3 coders in the whole firm.
I gained 25kgs in weight in this time In the sort of size companies I worked at, I didn’t have time to code, but I still had to.
Recently I decided to change things up. I had originally planned to go back to consulting, and to perhaps leave London and to get more balance in life. I handed in my three months notice and started talking to a possible client or two. Something didn’t feel right, so I started to look at other jobs that played to my strengths as a developer.
Scott Adams says you should optimise for energy. I think subconsiously that is what made me go down this route. I expect to have far more energy six months from now I surprised myself by both getting and accepting a job offer from a medium-sized e-commerce company as a Senior Ruby Engineer. It’s several rungs down in terms of job title, and a relatively large drop in income, but that doesn’t bother me. The thing that appealed to me about it, I think, was that in this new role I get to focus again.
As I considered the offer, I also considered their feedback from the interview via the recruiter. “He’s had split focus for a while, so his technical skills have suffered a little”, is a phrase I initially resisted, but deep down I knew they were right. Their follow-up - “He could be very good within a few months with some focus” - made me wonder.
I completely agree with Jacob Kaplan-Moss’ evaluation of the myths around programming talent, and on evaluation I would say that today, right now, I’m probably in the upper 50% but not in the top 10%. I feel like with some work I could get there though.
I research algorithms and if there is no existing library that implements them well, I’ll write up my own. Then I’ll think about how what I’m doing integrates with the bigger picture. I know the fact that I’m standing back and thinking about consequences and the ability to change cheaply puts me over the “average” line stacked up to most other developers. But am I taking my time to do things well, am I really honing my code in the right ways? No, I can do better.
Why would I want to put the work in to get up the standard distribution of talent? Writing code makes me happy. Not solving esoteric problems that are only of academic interest, but shipping real code after speaking to real people. Knowing that the company I am working for has benefitted, that the customer has benefitted, that’s what makes me feel good. The days I ship code do not feel like work and I go home “happy tired”. The days I have to move away from architecting and implementing software always feel like work and I go home “drained tired”.
My best days as CTO were those where I basically became a senior developer: scoping, prioritising and designing features and then working to deliver them. It’s where I added the most value.
As this dawned on me, I thought that perhaps I should never have become a CTO - I should have looked for a Senior Developer/Engineer role originally. What’s done is done. I now have experience that help me empathise with senior managers, and that can’t be a bad thing. For now though, I want to become the best developer I can become.
As such, I’ve started to dive through books. My initial reading list looks like this:
Domain Driven Design: Tackling Complexity in the Heart of Software - Eric Evans
Growing Object-Oriented Software, Guided by Tests - Steve Freeman, Nat Pryce
Practical Object-Oriented Design in Ruby: An Agile Primer - Sandi Metz
Eloquent Ruby - Russ Olsen
Ruby Under a Microscope: An Illustrated Guide to Ruby Internals - Pat Shaughnessy
My goal is to balance some bigger picture ideas with some technical works of Ruby, the technology I use. I have read all of these books before, but feel I did not give them time to digest because I didn’t have the time to reflect.
I don’t expect any of the topics covered to be completely new to me, but I am interested to see if I can bring the ideas together with a focus that helps make me a better developer.
I’ll be writing up notes/reviews here, perhaps quite detailed. Nothing makes you internalise knowledge better than teaching/relating it to others.
@p7r is my preferred route If you think there are others I should add to the list, the links at the foot of the page should help.