Startup Nugget #3: Staying Technically Relevant
It becomes harder to keep your technical skills up to date when you're constantly switching between tasks and everything is urgent.
As the main technical person of the company, it can be a contradictory statement. Since I have to wear many hats, even if those hats are limited to the technical domain, there's little time I can devote to experimenting. Learning a new language or framework consumes time that could be better employed in improving the current state of the startup.
Why would I spend half a day playing around with say, IPFS or GraphQL with the hopes of them perhaps becoming somewhat useful for some remote use case when I could be writing some code that would add a valuable feature to the platform?
Oftentimes it feels that I am capitalizing on all the previous knowledge I've acquired over years of being a software developer, where I had the free time and energy to religiously consume tech articles and experiment around. I fear the moment when a truly complex technical challenge arises that would require a more convoluted approach, and I won't have the ability to tackle it. An even worse situation would be to make an architectural choice that would deteriorate into crippling technical debt in very little time because of my ignorance of better alternatives, dramatically slowing the speed of development and stability of the system. The common example is microservices vs. monolith but besides that tongue-in-cheek example, I'm thinking more of using cron jobs because I never used a queuing system that could offload resource-consuming tasks from the backend.
This is not necessarily bad, on one hand, this whole situation has forced me to make boring choices for the tools we use, because of their stability, ease of use, or because I just didn't know any better ones and we are constantly time-constrained. A positive unintended consequence of it is that I no longer get excited over the new tech fad but rather learned to filter the cruft through the lens of actual utility.
By no means does this stand as a sign of complete stagnation, I've had to make quick decisions about tools I'd never used because we needed them, and I had to learn how to use them (and learn fast). Wordpress, AWS (plenty of services), Google Analytics, Sentry, React Native, are just examples of them. I cannot however get rid of the feeling of only getting to know them little enough so they fix the concrete problem that needs fixing and on to the next issue.
Two solutions become apparent to me:
- Hiring people to perform highly specialized roles that would free me some time to do research and play around. This is the natural evolution for any growing company anyways, meaning the workload has multiplied to need additional brains.
- Specifically allocating time to learn & experiment, and be rigid about it with the team. This is hard to pull off, there will always be fires that need putting out, urgent features that come up, and a whole string of unexpected problems, but just being clear about not being bothered during 2 hours a week gives you some room to at least keep yourself on the loop.
As a closing thought, I think the healthiest way to look at it is to start considering any reading, playing and experimenting as part of the process and part of the necessary work to achieve the best results.