Personal Technical Debt
Recently listened to a Hebrew podcast about “why programming languages take off and crash?” and decided to summarize it and add some more information.
Technical Debt
You must be familiar with the term technical debt. In short, it means knowingly or unknowingly leaving the codebase in a less than ideal state, acknowledging that we’ll have to make it better, hence, pay the interest, in the future.
It doesn’t mean it’s wrong in all cases, for example a deadline imposed due to legal requirements or fixing an urgent security problem or an issue for a big client.
An example could be deciding to write new functionality in a class that already has more than one responsibility, knowing that splitting it to its responsibilities would be the “correct” but more time consuming way. We’re now in a debt, and fixing it in the future would be more expensive, because:
- We will have to relearn the domain and the use case subtleties
- Keep re-prioritizing in our backlog
- Overhead of a user story — refinement, estimation, implementing, code reviews, manual QA
- The risk of another deployment
The bigger problem is when not paying the debt at all, leaving the codebase in a state that makes future changes slower and harder. It’s multiplied when this is the normal modus operandi — ignoring the debt, continuously deteriorating the codebase quality (usually being surprised that new features take too long).
There are other types and examples of technical debt: an evolving system that doesn’t support the current traffic and requirements, thus yearning for significant changes, or plain mistakes in architecture, design or implementation. Other can be lack of tests, documentation and poor readability.
For our discussion, the actual type or definition doesn’t matter, but rather the general idea.
Personal Technical Debt
By “personal technical debt”, I don’t mean that each developer owns parts of the technical debt. I rather refer to the personal career.
This is mostly about stagnation. Software is one of the most rapidly evolving disciplines. New languages, paradigms, frameworks, libraries and tools appear on almost a daily basis. Techniques, development processes and methodologies also change.
The problem is when we stick to the old for too long, leaving us less valuable to our current and future employer, to the risk losing the job and not being able to find a new one. In this case, we’re forced to either move to a location that does offer a job with the old technology, or we must learn very quickly, putting us in a bad position, competing with people who already learned and have experience. You might have a lot of luck, finding a job in your town and even get paid exceptionally high, because the company cannot find others who can or willing do it, but this would be temporary until they switch. Think how many Cobol or Fortran developers you know in your city.
It’s worth noting that languages, frameworks and libraries get old and are neglected gradually and slowly, not die or disappear one day. There are signs, however:
- less stackoverflow questions and answers
- stackoverflow annual survey results
- less attendance in meetups
- less job offers
- friends are surprised you’re still working with that language/framework
- higher salary for those who are “willing to remain”
- periodical posts about how the framework is not dead yet with proof to support
- hot startups or companies within the industry use a different technology now
- big companies announce that they deserted that language or framework
What can you do
Gain knowledge and experience with old principles and with new technologies. By old principles, I mean things like design patterns, relational database basics, SOLID principles, refactoring, importance of abstractions and more. Only chasing after the new javascript frameworks might not be enough.
Examples of such moves I have witnessed:
- .NET developer and CTO working as a junior Ruby developer to get into web development
- Developer becoming world famous for unit testing and CI/CD
- Ruby developer learning python to get into machine learning
- Backend developer learning React JS or Angular JS
- Object oriented developer learning functional programming
- MySQL and Postgresql → Mongo and graph databases
- QA learning Ops to become a proficient DevOps person
- AWS and other cloud technologies, Docker, Kubernetes
How to do it
- Learn while commuting, in evenings and weekends here and there. Can be theoretical books, technical articles, blogs and talks, code catas, getting to “hello world” level in various languages, online tutorials and courses
- Side project
- Contributing to open source projects
- Education time/Friday lab — many tech companies allow periodical free time to work on things not necessarily related to work, to allow for personal development, creativity and fun
- Take part in hackathons
- Attend meetups
- Attend conferences
- Initiate a workshop within your company
- Volunteer for a new project with new technologies within your company
- Move to another company that offers a chance to work with both your current and new technology, or maybe only the new one
- Move to another field: DevOps, product management
- Career path change — move to management
There are several reasons why technologies fade out, such as: low performance, security problems, difficulties to release new versions, and more. It doesn’t matter why, but this happens every now and then, and will for sure happen at least once or twice to you. So better be prepared.
Beside constantly reading, my personal moves included:
- Manual QA → automated QA within the same company
- Automated QA → .NET developer in a new company
- Learning agile methodologies, unit testing and CI/CD in a new company
- .NET → Ruby via a side project, including Redis and more technologies, then in a new company
- Relocating and working with Kafka, services and high traffic in a new company
- Ruby developer → Team lead within the same company
You can see that some moves are easier than others, e.g. change library, database or framework within the same language is easier than a new language. However, any such move can prove to be valuable.
This also leads to another interesting point — many people find themselves in one of the two groups — either tail of lions or head of foxes, meaning, they either prefer to learn and be surrounded by experts, or to be leading the older stuff. In my opinion, we should be changing every some time — for some time we are novices, we learn from experts, then we become the experts, then we can start learning something new again. To me, this is a sustainable, healthy and interesting career.
