Intro

I think this question is something that could be asked about pretty much anything in life. Why do you wake up at 7 am? Why do you have two coffee cups with anime girls printed on them? Why are you afraid of people? Why do you even brush your teeth? You may or may not ask these questions, and it depends on on how depressed you are your curiousity levels.

Here, I want to discuss why trying to understand and correlate unpractical things may be benefical for developer, how it improves their work, and touch on moments where it may not be as suitable to get deep and spend time reading the documentation.

It is very reasonable to think about the tools and methodologies and even code style you employ deeply, from a standpoint of a person passing by, objectively, so to say. Why are using const variables in the first place? Why is there ten redux stores in your project? Do you like your RxJS? Dwelling on such questions, youā€™ll discover a thing or two about yourself.

Hot bubble tea

There are behaviors that everyone do on a regular basis, thatā€™s why theyā€™re ā€œhabitsā€. Thereā€™s some patterns of behavior in programming too, of course. It is classic already to call JavaScript a ā€œwatā€ language, to call PHP outdated, and that Next.js is a copy of PHP and the time is flat circle and we are back to 2001. They are traditionally common memes that have became shared language.

JavaScript's implicit coercion of adding up arrays and objects magically in a famous talk called 'Wat'

Maybe, this is something that people use to bond over, and have a laugh together. People are social creatures. We are often made to copy other peopleā€™s thoughts and behaviors by our nature, we are meant to do this. Because someone else thought it would be a great idea to rate programmers based on their Leetcode scores, or to meticulously look at their ā€œproductiveā€ time with a spyware called timetrackers now everyone is doing it! But sometimes, just as in life, it is important to find your own ground.

When you entrench yourself in yapping influencers and series of blazingly fast and absolutely, hundred percent innovative technologies, you forget how to stand and decide on your own. Everyone seem to have the decision to all your problems. It is important to remember that people could not account for you specifically, perhaps only if they are spying on your google searches to promote you the pair of Nikeys youā€™ve been craving to purchase for 2 months.

There is enough negativity on social media and controversies and debates, like, should you use Typescript? I donā€™t think so, its now removed from this repository you use! or ā€œyou must write everything by TDD and make your functions 15 lines longā€, otherwise all hell will break lose.

People, just as I did right now with the passive-aggressive quoting of Uncle Bob, are probably made to be angry about statements that they do not support. But I think most problems can be resolved without raging at your opponent, and in this article I wanted to make a case for me, and maybe for others, about why you may want to learn deeply about the things youā€™re using daily, to withstand all the hot takes, grow more independent, and build a secure knowledge with hard ground, that will stop you from becoming a talking head.

Why ever?

Understanding the roots is like understanding small atoms and molecules when learning biology. You can know about a pill which would cure some disease, but you are not a doctor for knowing that, although you can practically apply your limited knowledge in some situations, like doing a mouth-to-mouth on a flight. You would be very useful for that! And its easier so, but you would not become an expert just learning labels and frameworks and mixing them out of intuition.

And you could as well mix and match your libraries and frameworks, juggling them around, making completely functional products, but at one point you either continue doing that for the rest of your life, and your career growth just stalls at what someone else throws at you, what another AI spits out for you to copy, or you craft a path to build something from scratch yourself, because you want to understand the fundamentals and be at the forefront of the development.

Getting a UI kit is easy nowadays, because thereā€™s dozens of them made by vast groups of other people. As you have Radix, you have your logic baked in, as you have Shadcn, they are not even someone elseā€™s code, they are completely within the reach of your imagination, in your project as your files! Do what you want! Build another meta-framework with Vite, have all your infrastructure solved by Vercel!

But, as npm packages, this causes your dependence on someone, and when that someone fails to produce what you want to have, you will have a hard time keeping up. It would be like buying an apartment with only as much rooms, and when you have a family upgrade of more than three kids, you will start thinking where to place them, and you would not have an answer. You will either compromise on your familyā€™s living conditions, or move out for something else built for you. You can, of course, buy a house, buy a mansion, buy whatever if you do not know how to build your own home from scratch.

But what happens when you donā€™t have anyone else build a suitable home for you? What would you do, if you need to build a new Discord, but way better, and youā€™re just using frameworks, having never ever dipped in their internals, and you lack that one feature that your company wants to have? Well, maybe you can employ some tools, maybe you can hire another senior developer, but you will always need something external to have your back.

And thatā€™s why you need to try out C, check how Assembler works, and know what does it mean when a heap is out of memory, or call stack was exceeded, or how a database stores your data in pages. You stop at INNER JOIN, and it works, but in 1% of cases, all your project collapses, and thereā€™s not as much stack overflow questions on it, say, none! Then, it will be up to you to fix it all, and you must need to have intuition, on where too look for and what points to include in your thinking. It is too broad to go into a problem without any underlying knowledge. To be a master of something, you must need how that something works, otherwise the dog you tamed may bite at you!

Having that, when a new technology comes out, you wonā€™t be in such an awe: it wonā€™t present much new upsides for you. If you know how Hono works right now, and you have used it in a production, and you know why it uses Trie or RegexpRouter under the hood, and what underlying concepts an http framework is built upon, then new Bono framework that proposes to be a quicker and better version would present before you as an upgrade and increment, rather than a new foundational that it is certainly not, as it is new and fresh and not battle-tested enough.

Know unknowns

I think almost all people, whether they believe it or not, exert magical thinking, in a way that their lifeā€™s example may have taught them to act a certain way, or believe certain things. If you notice an inconsistency in their thinking, because it appears as nonsensical to you, they may not even understand you, maybe get angry, maybe just miss your words altogether, because it works for them.

As rational as those thoughts may seem to them, many thoughts are formed through unconscious processing. Iā€™m not an expert in this, but right from your childhood, when youā€™re almost completely unconscious and unknowing about whatā€™s going on, there are forces in you that do everything automatically. That mechanism does its job of keeping you alive, but it has its flaws, of course, and thatā€™s why people are even made to ā€œthinkā€, to overcome just passing the life by as it unfolds, and employ ā€œmetaā€-thinking.

When you put your supposed knowledge that youā€™ve gathered by feeding information into your brain, you find out that itā€™s not as coherent as you ā€œfeltā€. You would probably be unable to justify very simple things, that you just ā€œintuitivelyā€ thought you knew. And here, the power of essays and curiousity and your boundaries of knowledge, like teaching stuff to others, come into play. When you try to push yourself to find weakpoints, you become stronger, so when a crisis come, you will already be prepared. Like a giant ancient tree with roots prolonged to the Earthā€™s core, you will withstand any storm and meet the warming sun, rejoicing at your victory.

But enough of my yapping. What I want to say is that it may seem completely foreign to try to do things outside of practical necessity. For me, its a contrary - I try to know about anything I can get my hands on, but in a way, I need to learn about the other side of the coin - to focus on one thing and be practical about my ways. For other people, its another story - they donā€™t see any meaning in learning something remote from what you do.

In my previous blog post, I explored the ideas between learning many things or mastering just one. I came to the conclusion, that balance was the key, and that one thing was impossible without the other. You canā€™t master one thing without knowing other connected to it, and you canā€™t know everything without relying on something. Thatā€™s why using just React may not great for you long-term, and thatā€™s why hopping from framework to framework is just detrimental.

So, I propose that we all ask questions about things we use in daily lives. How does this JSX element work in my .js file? Is that even possible in JavaScript? Oh, Typescript knows how to use those notations? How does it do so? AST? Parsers, jsx transforms? You donā€™t need to subscribe to a thousand RSS feeds, and do not need to research a new framework every week for that, itā€™s right here, before your eyes. It is a hammer, that you use every day, and may not even know how it works.

Everything is not wat you think it is!

Research history. It was a revelation to me when I learned about CoffeeScript and its downfall. Thereā€™s a saying, that thereā€™s no programming language made in vain, and that they all carry some idea to them, and that idea would probably be used by others, even if those who brought it to others perish. I think thatā€™s what happened to this language. Hereā€™s a great video, second in the results of searching ā€œCoffeeScriptā€, and itā€™s named ā€œThe Death of CoffeeScriptā€.

1
# A typical example of inheritance
2
3
class Animal
4
constructor: (@name) ->
5
6
speak: ->
7
"#{@name} says #{this.sound()}"
8
9
class Cow extends Animal
10
sound: -> "moo"
11
12
class Horse extends Animal
13
sound: -> "neigh"
14
15
class Sheep extends Animal
16
sound: -> "baaaaa"
17
18
s = new Horse "CJ"
19
console.log s.speak()
20
c = new Cow "Bessie"
21
console.log c.speak()
22
console.log new Sheep("Little Lamb").speak()

It looks like a baby of Python and TypeScript a bit, and you can see how many of the language features were moved into JavaScriptā€™s ECMA standard. Thatā€™s another notion: arrow functions were not always here, and back in the dark times people were actually using IIFEā€™s in their code to isolate global variables from each other, because bundlers like Webpack or Vite were not there to save them.

When this language appeared, many companies like Discord and Spotify used it, just as they use TypeScript and Electron and other technologies now. It may seem impossible that todayā€™s technologies will be somehow superseded by other, new and shiny ones, but I guess it could be a blindfolding experience if you donā€™t know anything about the past. Many civilizations fell as if they were houses of cards, even though when reading about them, you thought they were so great theyā€™d last an eternity.

And you will be amazed how everything is built imperfect, as all developers make mistakes. There is not one technology that doesnā€™t have its downsides. There are some bad ones, left in the past, or vanished after their creation without any attention to them, there are some really good ones that are persistent within a very large community of people, like a trio of modern frontend frameworks (React, Angular, Vue) which dominate the job market. But each one of them could be picked at: React is too simple and unthoughtful of developer experience, Angular is too complicated and verbose, Vue is using a compiler, and so on.

That understanding will empower you in a way to have your own missteps slide sometimes. It especially helps to think like that if you have a perfectionistic conscience telling you to fix every variable name and rewrite all your apps in Rust, because you heard it is the best language in the world. You do not want to think about the adversities of using middlewares in your killer app for 10 hours straight, even though this pattern has its downsides! Do not rebel just out for the sake of it, hot takes are not what is important, but rather having a strong foundation on what you believe.

And all these frameworks stood the test of time, especially in the applications where they were meant to be used. The Lindy Effect proposes that the longer something exists, the more it will be used in future. So, even if thereā€™s a hundred frameworks produced each second, you donā€™t have to learn them all, or be afraid that you will never get a job if this trends continues, because the past is on your side - React is probably staying for some 5 years ahead, if not more.

There is one bad path that software industry is taking right now, or perhaps it is justified by the growth that this field took with all its benefits, great salaries and making the world a better place, but some job postings are incredibly awful. I have a friend who is a Senior Angular developer at a pretty big company with many outsource and in-house employees, and when he looks at job postings, it is impossible for him to even get a screening. Recruiters are asking developers to have 5 years of experience in React, which is just completely stupid!

You donā€™t need to have five years of experience cooking specific recipe, if you can cook great and you know your theory and craft and tools. You can learn new ways to do things by applying your past experience, even if itā€™s unrelated. Sure, you may not ā€œknowā€ React at a Senior level just having jumped from being a Solid developer, but you will sure as hell pick it up quick, and your experience at this specific technology is not what matters. There are other skills like industriousness, ability to speak clearly and communicate your ideas and nitpicks in a human way, and, especially, to learn. It seems like the job market is saying:

I donā€™t trust you! You must prove yourself by doing obscene things for me to even consider picking you up! And Iā€™m the king, because thereā€™s hundreds like you, willing to serve me at any price I pay them!

And it is a horrible thing to face. I donā€™t have a solution to this, and I wonder if anyone would have one, other than just okay such a state of things and pass such a posting. Tracking developerā€™s productivity by hours worked, by coffees sipped and by lines of code is just such a non-straightforward and surely not an engineering way to look at things. And Iā€™m sure that it would be better if my house is built by a carpenters hired by my friend who knows his carpentry, otherwise my hiring skills would probably put my future home at risk.

Explore by doing

Life is the ultimate measure of truth. Try to apply your new ideas in practice, make a new project following the architecture you learned about or even concocted yourself, and see how it works for you. Maybe Clean architecture is not the greatest tools for small projects and MVP and products which are handed away and would never change their database forever. Maybe putting every component you have in one components/ folder, without any meaning and colocation is not a great idea as they will mix together without any order, although you were trying to impose one when you created the folder and were not writing everything into one file.

Cool sounding sentences and skewed benchmarks on the landing page is not an indicator of success. Of course, it is hard to determine if something is skewed, and that on itself is a hot take, but when you compare server frameworks with ā€˜hello worldā€™, something is up. Here, if you have researched about the tool you use, you will know what things it does, and why its meant to be used at all. You will understand itā€™s not a silver bullet, and know its weak points, which will help you in optimizations, which are not premature, and debugging, when console.logā€™s donā€™t work anymore.

Thereā€™s one interesting aspect of programming, which is an ability to see instant results of your work. It was not much possible twenty or thirty years ago, as people then waited for hours to see what the result of their work were. It is very practical. That got me into programming as well, I think, because dopamine feedback loop got very strong after about a week or so of doing it. It was very easy to get into my code editor and just do whatever, to learn, or to have fun.

Thereā€™s a mixture of fun and seriousness in programming. I think thatā€™s why it can get boring to learn about data structures and algorithms if youā€™re a web developer: where would you ever use them in your job? The practical upside of knowing how a binary search is close to zero. And perhaps if you code C++, then you have more seriousness, and if you are making cute-looking landing pages that you yourself adore, working with a great designer behind them, or you are teacher that makes great examples and crafts stories for your pupils to follow, you are on more of a fun side.

Regardless of that, it may be worthwhile to look outside of your place, and having understood what a goroutine is, how tokyo threads are made in Rust and then conclude it all by trying to tie it up to JavaScriptā€™s EventLoop and callbacks and Promise and libuv. Then, you will find writing your code is a much more conscious and aware process than before. Hard things that youā€™ve previously did not understand very well will come in a new clarity to you. You will receive a different perspective on old ways of thinking, which propagates progress.

Ignorance is bliss

Thereā€™s another side of the coin to this debate: business goals. Remember, that if youā€™re working, or even if youā€™re making your personal project, you may have a goal or two, where you might want to get in a certain period of time. Thatā€™s great to have a time estimate, because it sets a clear boundary for your brain to count upon, and that reduces procrastination a lot. With that, your limitations show up. You canā€™t get it working in time if you sit and read the documentation, it is a bottomless pit of your time to figure things that you wonā€™t even need in 99% of cases.

Thatā€™s the time where you may want to turn to dumb part of yourself on. Stop your grandiose idea of making a perfect project, and get back on the ground. Look around and figure a way to make this work: nobody will probably even see your code, and even if they do, theyā€™ll probably fix it for you. The perils of always finding a reason to refactor once more are not immediately apparent, but once you do it enough times, you will see how it affects your productivity.

At one point, a lazy person is better than a dozen smart people, who would create an intranet of microservices at day one, then get so entangled in them, quit, and leave everything to you. You will have to deal with it or build everything from scratch. Sometimes you want to use a SaaS to control your infrastructure, because it is really hard to build one yourself. Iā€™ve tried to do my Nginx CI/CD setup from scratch, and it took me about two or three days to get it somehow working, and I donā€™t dare to speak about reliability, and thatā€™s with some preexisting experience.

It is virtually impossible to know everything deeply. You must spend several years to get good at one thing, but being good at many is a feat. You may even need to be a genius to keep your skills great at several things, because it is hard to keep something you learned at your fingertips, without it rusting away over time. It may be not so hard to speak in three languages at once, but to keep that up you need to continue speaking in them through the rest of your life, otherwise you will probably lose them.

Also, sometimes just knowing does you no good at all: it may even disrupt you in a sense of pushing you towards differing viewpoints, and it will literally slice you in pieces. You may not want to learn how every bit moves in an electrical wire when all you want is to just build a feedback form on your companyā€™s website.

Parents in their 20s: having babies; Me in my 20s: One billion loops in several programming languages comparison

If youā€™re not aiming to become an expert, itā€™s not a big deal. Those who are not interested in knowing how assembler works, perhaps shouldnā€™t learn about them, and shouldnā€™t purported by evangelists to do so. It is important to understand our differences in that regard - someone just wants to know how to administer insulin and do all other important things to help their family, or walk someone elseā€™s dog and be a babysitter for money, without knowing all the theory of animal training!

Build your yap

Having said all that, I want to say, that the current technical world is a magical place. It is built on the fact that we must collaborate, and thatā€™s why soft skills are growing in demand, and I think its better in some ways to have a teammate who knows how to communicate well over someone who knows another JavaScript feature. We uses computers, which we donā€™t know how to build from scratch, and to know that we would probably need to spend decades building them, and if we donā€™t want to do this, we must trust other peopleā€™s work to produce our own.

It is a very pricey, but at the same time very profitable skill to have people behind your back. You need to spend yourself with them, be polite and understanding, preserve your social group together, which requires efforts, both physical and emotional, and time. Thereā€™s a bunch of russian sayings:

ŠžŠ“Š½Š° Š³Š¾Š»Š¾Š²Š° хŠ¾Ń€Š¾ŃˆŠ¾, Š° Š“Š²Šµ Š»ŃƒŃ‡ŃˆŠµ

ŠžŠ“ŠøŠ½ Š² ŠæŠ¾Š»Šµ Š½Šµ Š²Š¾ŠøŠ½

Š” тŠµŠ¼ Š½Šµ уŠ¶Šøться, ŠŗтŠ¾ Š»ŃŽŠ±Šøт Š±Ń€Š°Š½Šøться

They are roughly translated to:

One head is good, and two is better

In a battlefield, one man is not a fighter

You canā€™t live with someone who loves arguing

Look around yourself: many of the things you use every day are an enigma in themselves. You wonā€™t be able to have electricity, which probably is a new energy on which lives of many people run on, wonā€™t probably have your apartment with all the nice furniture that someone else made. And you donā€™t have to ponder about those things, spending literally -1 seconds to use them.

In programming, thereā€™s abstraction levels that work similarly. Under the hood, a program, like some black-box machine learning algorithm, may create and collapse a microuniverse, and you donā€™t have to care, because you gave it a string and received a string back. It is easy to learn about strings, and it is certainly not even close to easy learning how to build such a thing.

Modern technical world has a nicety of opensource, and itā€™s like you can go to a store, and they will give you any instrument you wish for literally for free, and you can find a client, and sell them the skill of using those instruments. Thatā€™s so crazy to think about, but it exists: you donā€™t spend a second learning about the inner workings of Virtual DOM, but you get all its benefits, because thousands of people spent countless hours modifying and optimizing how it works.

On another note, you have hundreds of people that you meet across your lifespan, that are willing to talk to you. It means that you can learn how to avoid many pitfalls, just by listening to them, which is a way lesser price to pay, than to compose a complete architrecture from scratch, only for it to fail on first production day. Some other people that youā€™re actually working with may spend their hours to help you prevent the same mistakes, but personally, in real time. It is really wonderful to have such a positive force behind you.

With that, be willing to stay constructive and pragmatic enough to accept criticism! Nothing is worse than locking yourself in an echo chamber, unwilling to go out of your comfort zone of ideas. At times, the best influence and moving force you can have is your ā€œenemiesā€, that would tell you about your weakness in a much enlarged sense, than any of those who ally you. They would jump out of their shoes and spend hours just to nitpick all your claims, and they have some sense in it, even if theyā€™re hateful. But there is not much truth in a hateful discussion, where one side undermines another!

In the end

Iā€™ve recently viewed another developerā€™s resume, and it was great, shiny and well-formulated, but one part especially touched my heart and made me chuckle, partly because I am the same, but over time less so. When he was listing technologies he had worked with in a job he had, at the end it was like so:

ā€¦JavaScript, Vue, PHP (Iā€™m not proud about it)

It really shows certain developer immaturity and imposed elitism of using something and not using something else, when in fact those technologies are not ā€œgoodā€ and ā€œbadā€, they are just different, and are being used to reach different means.

I want to notice how important it is to stay sane, without turning into a prophet and call everyone else sick if you donā€™t know what they know. We may not understand much about another countryā€™s laws, but they somehow live, and it is a great pitfall of thinking stereotypical to assume we are somehow better than them, just based on our differences. And to formulate more thoughtful criteria on separating truth and positive from untruth and negative, it is important to know what both are, and how they work internally, why and when.

That also may put you in a more relaxed space, because everything around us were built by the same people as we are, maybe a little bit more meticulous and exceptional, maybe a little bit involving luck. Having achieved such an immense feat as constructing a net over the entire world, so that everyone may click few buttons to know everything about anything, it makes you wonder, just as looking at Egyptian pyramids, if that was a human hand at work. And, as perfect as this whole design seems, there are still downsides to it, and that puts you in a place with everyone else who achieved great things, which means you could do the same, with enough effort and help.

Thatā€™s why its important to be humble and communicate well with other people, regarding of their status. Do not berate those who are lower than you (mere juniors trying to sneak up and rise at the company your working) and do not cower before those are greater (Linus Torvalds, smartypants), as we are all people. Remember to learn your basics, and stand proud of your opinion, without gripping to it so much when it becomes obsolete if others critique you constructively. Be wise to let go and keep strong, and you will arrive where you set out to go šŸ˜¼

Thanks for reading!