This post might come off like a weird spiritual tip for a developer, but bear with me a minute...
A word I came across in yoga that fits very aptly into the 21st-century knowledge work. It originates from Sanskrit language and roughly translates to "complete acceptance", which we all should embrace.
As developers, we are frequently caught in a feeling of incompleteness. Our work is never done. The code we write is far from perfection. There's always room for improvement by refactoring, or even rewriting complete pieces of the software. Moreover, masses of new frameworks and libraries catch our eyes daily. What about that next certificate or promotion?
The problem here emerges not from the practice of skills towards mastery, but the constant feeling that something is missing in our lives. When I rise on my career level, master the Kotlin programming language, and read these 50 books about object-oriented programming, I shall finally be happy!
Well, no, I won't. After that, I shall be just as unsatisfied and even severely depressed in the worst case.
Let it go. Don't plunge headfirst learning all the things that won't benefit you now. Instead, accept that your knowledge is never complete. The real mastery is an asymptote: a graph approaching but never reaching a point.
To fight the anxiety of needing to know everything, consider doing things just-in-time. Learn new techniques when they are necessary for your work. If an upcoming client uses a technology unfamiliar to you, grab a few quick courses beforehand. Rewrite that unstable component when its maintenance produces more risk than revenue. Write tests, not too many, mostly integration tests. Most importantly, follow the paths of YAGNI (You Aren't Gonna Need It) and YDNIY (You Don't Need It Yet). In the end, you have wasted zero time and spared your sanity.
However, modern society often is against just-in-time learning. We are expected to master a broad set of skills to be hireable to a new position or sellable to a client. We need to shift our thinking from masters of all trades to just-in-time specialists. Being a generalist is a good start, but specializing is required for solving real-world problems.
A practical example of just-in-time learning from my career is the integration documentation revamp I made for my previous employer. I wanted to find a fast and stable platform which would make writing technical documentation easy and fun for developers. While investigating this, I stumbled upon Hugo, which led me to learn about its internals, and how its static output integrates with Netlify and GitHub Flow also allowing non-developers to give rapid feedback by viewing preview deployments from pull requests. Similarly, I knew the basics of React and GraphQL but didn't dive into those before starting to write my personal blog with Gatsby.
Many years ago, I spent time reading arbitrary online tutorials without actually having a problem to solve. Today, by solving narrow use cases just in time, I've gained confidence that I'm on the right path. Having a track record of concrete solutions, I'm also completely satisfied (santosha) with my current situation while understanding there's still a lot for me to learn.
Photo by Road Trip with Raj on Unsplash.
Top comments (3)
Thank you for this post! I wholeheartedly relate to that feeling of incompleteness. I would add to that a feeling of not knowing (or even not being) enough. The worst is when I think, "If I had just studied {insert topic} previously, I could..."
On the other hand, I have noticed that there are certain topics that I have studied that have produced greater returns than others. For example, learning about the principles of Object-Oriented Programming has helped me in a lot of situations, whereas learning about some specific .NET technology has helped me get a job done but not been applicable to many other things.
I am trying out a hybrid approach where I learn what I need in the moment (e.g. a specific technology) AND when I can make time, add to my toolbelt by studying topics that apply broadly (e.g. reading a book about design principles). The second part seems hard to justify as a purely JIT exercise, but I believe is long-term more important to my growth as a developer.
Absolutely! Always prefer learning fundamentals (rarely grow old) before specialized frameworks (often grow old). Just-in-time learning applies to both, although fundamentals are best learned at a calm pace without external pressure to grasp a thing.
Agreed! Thank you again for sharing your insights. This was something that I needed to hear.