Why I'm Still Learning To Code and You Should Too
I’ve been coding for close to 40 years now1.
Over the years I’ve been through various technical and managerial roles, including being the founder and President of a start-up and CTO of various companies. Though many of these roles do not need me to be coding but I’m still seeking opportunities to learn coding, technical architecture, and ops skills.
It’s not easy to keep up with this learning, especially when it’s not directly required in your every day responsibilities. So why do I spend time, let along so much of my time on it?
Being a programmer (or software engineer, if you want to sound fancier) was not always an easy career choice when I started. While computer science was touted as the new industrial wave, the career wasn’t very attractive overall2. Any of my cohorts went into sales immediately or shortly after graduation. Many can’t wait to get out of technical and into management which is less technically challenging and often commands better pay and respect3.
Probably the most obvious reason is that I am a nerd and I suspect that you as a readers of this blog are a nerd too. Acquiring new knowledge and learning new skills has always given us immense satisfaction4.
I learned about how a computer work through C, OOP through C++ and later Java, functional programming and closures from Lisp and Scheme, logic programming through Prolog, dependency injection and aspect programming from Spring. From Ruby on Rails, I learned about convention over configuration, importance of testing framework, domain specific languages, DB migration, and DRY. And I find fascination in current developments in distributed architectures, containerisation, dev-ops, microservices, service orchestration, service meshes, server-less computing, CI/CD, and so on.
Not that we should use all the latest-and-greatest shiny objects, but we have an ever expanding palette of tools and new understanding that can help us improve the quality of what we do.
We can also build powerful, useful tools with code.
You can write code to analyse data, to simulate scenarios to understand their implications. You can write algorithms to automate securities trading, and code to back-test and analyse these strategies to find the winning one. You can customise how your services, applications, and tools work, and to make them do new things, to get the most out of them. You can make systems work together to compose more powerful capabilities and automations.
It’s like you have multiple workers following exactly your instructions. For your work and personal use.
I said earlier that learning to code is not directly related to my technical management role. That’s not entirely true.
There’s no question that technical management, especially at the C or senior levels, require many non-technical skills and doing copious non-technical tasks such as communications, interactions, controlling budget, managing relationships, thinking about strategies, organisations, and processes. Regardless, you cannot technical manage without a good understanding of the technical aspects.
As a CTO or technical director, how do you make decisions to optimise the tangible and intangible outcome of your team’s work? Which technologies do you use and what organisations, processes, infrastructure and tools do you use? Certainly you can hire good people to advise you on these aspects, but how do you know that these people are the right people and their recommendations are valid?5
I’m not saying that the CTO or director need to do the detailed work or even be as knowledgeable as the staff, only that a certain level of knowledge and experience is required, and this is probably more than what people in those positions or aspiring to be there might think. Especially when technology and practices ar moving at such a rapid rate.
Personally, I find that unless I have some hands-on experiences, I cannot participate meaningfully in decisions about whether adopting cloud technologies, or using this stack, or moving to micro-services, would have a positive or negative effect on quality and cost? How do I know what are the trade-offs and how they apply to our situations? How do I know when a candidate or staff is giving thoughtful responses to my questions or just repeating tropes from some articles?
You must always be able to distinguish b**t, and given that lots of the new knowledge are not necessarily intuitive, this is not as straightforward as we might think. To make matters worse, we are less likely to know we are ignorant when we are ignorant6.
So, in short:
- I find coding challenging and fun. You might feel the same.
- Coding gives me the ability to create and customise tools and automations that potentially make me more efficient and more effective.
- As a technical manager, it is essential that I understand technologies, and related issues such as processes, costs, organisations.
If your job is a developer or a tech lead, continuously learning would if a no-brainer. And if you aspire to be a technical manager, director, or CTO, learning new technical skills would still be a great investment for you to do a better job.
What are your reasons? I’ll love to find out in the comments below.
-
The situation is somewhat different right now, where technical jobs are some of the highest paying and most respected professions. Not to say that some of the technical < management prejudice mindset still exist. ↩
-
I interviewed many candidates who expect to move into management within two to five years of working and do not intend to work in technical roles beyond that. Many do not learn anything technical outside of school or work. ↩
-
Besides computer skills, I’ve also become a consummate student of nutrition, fitness, philosophy, human cognition, foreign languages, history, etc. Not only I find learning interesting and fun, there’s satisfaction in knowing and having skills. ↩
-
As a corollary, never trust a software architect who does not write code. ↩