Keeping up with technology - Part 1
It may seem exhausting or boring so let's make it easy and fun
Most of the engineers I’ve worked with don’t even try to stay current with new technologies. They usually feel it takes time and amounts to more work. But more often than not, their approach to this topic is mistaken.
Keeping up with your field should be fun and lighthearted. So, this week, I wanted to dive into this more practical tool that should be available to any software engineer.
This will be a two-part article:
Part 1 focuses on the what and how
Part 2 will focus on the when and where
If you don’t want to do it, don’t
This is a simple PSA. I know I’m curious, I love to learn and discover stuff, so I enjoy spending time doing technology watch, even in my spare time.
But sometimes, you need a strong separation between your professional and personal lives. And for some people, it means not touching anything programming related outside of their work hours. I get it, it’s your right, and this shouldn’t be forced upon you (especially by yourself).
But if you want to do this, let’s make it as fun as possible.
Build up your toolbox
To put it mildly, it’s about expanding your toolset to solve more problems faster and with higher quality. In my opinion, this is akin to a good craftsman honing his skills by finding fresh ways to solve existing or new issues.
For me, it’s the pride of being able to help a client set up a messaging feature in an application in less than a day because I had heard of a SaaS to do it. Or it can be that I’m improving my code because I read about new architectural concepts. But often, it’s just being able to have a cool conversation about a hot new concept with another engineer.
And all of these examples happened because of one thing; I came across these new tools.
Don’t clutter your garage
There is a vast difference between knowing “about a tool” and “knowing a tool”.
Most engineers who don’t do spend time monitoring the new trends or have abandoned it did it because they mistook the two. You cannot know everything in an environment as fast as software technology (and let’s not dive into the exhausting Javascript ecosystem). As you take the time to learn the latest new framework, ten more will have come out. So chasing such an ideal will only burn you out.
The common denominator between knowledgeable engineers is that they don’t become experts in everything. But they keep track of it so that the day they need to; they know where to find the information required.
So the investment is not in knowing how to, but knowing which tool is attached to which problem.
What should be on your radar
Here are a couple of things I keep track of:
Language/framework/library and their evolution
SaaS products I could use
Who knows what (blog, newsletter, Twitter account)
Design patterns
Software Architecture patterns
Posts about solving problems I encountered or may encounter (blog post, GitHub issue answer, stack overflow answer)
Keep in mind that this list is not exhaustive, and my definition of what to track is usually “stuff that could be helpful”.
Filter out and aggregate
I then have a simple framework to address new stuff I come across:
What problem does this solve?
In which context does this problem happen?
How often can I find myself in such a context?
What value does it bring compared to other solutions I know of?
While I don’t write this down except for the problem itself, I always go through this framework mentally to discard most of the things I come across.
I then try to aggregate the base information in the same space (I use Notion) to find it later on. I tag the problem solved and add where to discover more about it, whether it’s a link or the name of someone knowledgeable on the topic.
Escalate
Sometimes, knowing about something is not enough, and in such cases, you want to invest a bit more time into one of the tools you came across.
For this, I like Thoughtwork’s Tech Radar approach. Here it’s the main steps to adoption:
Assess: Try it out on a proof of concept project, something you can do quickly and throw out later on, but which can help gather some deeper knowledge on the technology.
Trial: Time to test it out in the real world. Use in a small part of your project and make sure you can swap it out with minimal cost later on.
Adopt: It works! Now time to make it a standard across the codebase.
Hold: This might not be the best solution to our problem anymore. While it may have been standard in the past for good reasons, we should be phasing it out.
Each step comes with an increased cost, so don’t take escalation lightly.
Not everything should be useful
Please don’t take the previous paragraphs as a checklist, or it’ll feel like work. Take it as an approach and philosophy to practicing regular technology monitoring.
I don’t follow these principles all the time. But because I adhere to them, I do so knowingly. Sometimes, I also want to try out cool new stuff; even if I know it’s not likely to bring me any value later on. But I do so out of enjoyment, knowing I’m not always adding a valuable instrument to my toolbox.
So please do the same and not take this proactive learning too seriously.
This one was going to be a one-shot, but I got enough for my first two-part post, so two parts it is. And if you don’t want to miss the second part and when and where to gather this type of information, don’t forget to subscribe 😄
And if you’ve enjoyed this post and got something out of it, sharing this post would help me a lot in return (“like, share, and subscribe” as they say).