Every once in a while there is a popular tweet, either with some strong statement in it or some controversial opinion that makes the internet blow up, ensuing endless retweets and many separate discussions about the content, or the person, who tweeted it. The most recent one has been this post by DHH (for context, he is the one who created Ruby on Rails - let that sink in by thinking just how many jobs this one guy ended up, indirectly, creating in the industry over the years. His impact in the field, like it or not, can’t be dismissed, period) that summarizes the key idea of an article he published, which you can (and definitely should!) read here:

The tweet above, combined with the first paragraph of the article summarizes the entirety of the topic that I’d like to discuss:

“In the valiant effort to combat imposter syndrome and gatekeeping, the programming world has taken a bad turn down a blind alley by celebrating incompetence. You don’t have to reduce an entire profession to a clueless gang of copy-pasta pirates to make new recruits feel welcome. It undermines the aspiration to improve. It reduces the work to magical thinking. It is not good.”

I assume that this was what triggered everyone on Twitter, and, well, for good reasons: people can’t read anymore, that’s a fact. There’s no fear of failure nor a sense of imcompetence when “understanding” is just a google search way, and, yes, that’s bad. It’s bad because it goes against the essence of what being a programmer (instead of a copy-pasta cat) is all about, and, the fact that a huge portion of twitter completely misunderstood the article and was quick enough to judge DHH about gatekeeping and other ridiculous claims just further proves the case. It’s perfectly okay to search up stuff online, nobody can know everything and everyone needs to start somehwere. And, while it’s true that the internet has made the entry barrier into the field as low as it ever been, it’s a dangerous trap to fall into to assume that this is just how things are supposed to work. They’re not. There is extremely hard work and intent behind each framework or programming language in use today, and, reducing all that complexity when we hit a wall by just copy-pasting things from the internet entirely dismisses the purpose of programming.

People claim that it’s ridiculous, that nobody even remotely thinks that a career can be made on surfing google whenever the complexity gets too high, and, well, that’s true, but, what do many (if not all, at some point of their careers) of these people do? An exception occurs on top of a Hibernate query, some data is being modified outside the context of a transaction. Wow, okay, weird. What even is a transaction? I know it has something to do with the database, I’ll just do a quick google search and see what comes up! Ah, obviously, Springboot offers us this @Transactional annotation, I see. Ah, this guy with the answer with 2k upvotes says it should be added on the method where the query is being invoked, cool, let me see if it works. Ah, great, it works, cool. Next.

This is an example of how shallow knowledge can be hurtful in the long run. This is not the proper methodology to arrive at a solution, even in the cases when it’s the right thing to do. And, the worst part is, in many, many cases, this will just work and yes, it can be correct. But, what about the finer details? The pointy edges of this whole thing? I mean, do people actively think about their domain modelling before searching Google? Seriously, be honest. Well, if you are like me, I’m sure you had ocassions where the only thing that mattered was to solve the issue glaring at you in red letters. And, again, to reiterate, this is not the correct approach. Because it’s just shallow. Even if by CHANCE, it fixes the problem, I still don’t leave out of it feeling smarter or wiser. In DHH’s words, I am still a simple bedazzled member of the audience, instead of feeling more like a wizard.

This is very problematic because it compounds over time and pattern matching is too tempting. One day, in a few months time, a colleague will see the same exception as you are seeing, and, you, being a good sport, and, additionally, smart, because you just remembered you saw this same error a few months ago, you simply go and suggest him, “hey man, if you add this @Transactional stuff on top it will work, I had this before.”. Except that…. the method where this was executing was itself running inside a transaction already, and it becomes all super messy and new exceptions pop up, and, now, you’re both clueless. So, you Google again a bit more, and, find that Hibernate does not support nested transactions, etc, bang it a bit more, it kind of works, move on. This is exactly, I believe, the point that DHH was trying to make with the article and it’s an extremely valid point:

Do not accept or settle for shallow knowledge when problems appear. Understand the underlying mechanics, document them and you will be a better engineer.

This can’t be overstated: strive for deep understanding of the things you are using, modelling and working with daily. Invest real time in diving deeper into your domain model, understand the relationships between the entities and the context of which the services being called on depend. Understand their interactions with the persistency layer and dive deep into internals of frameworks. Write Architecture Decision Records that detail all the things you are learning, that detail problems, and their proposed approaches and solutions tailored to your domain, to your architecture and to your codebase. In essence, strive to transform your own institutional knowledge and your domain into a corpus of problems, approaches and solutions that can be researched directly on top of your codebase for future people and for your future self.

Document the problems and solutions that apply to your domain and you will expand your skills in what really matters: system design, domain modelling and grasping the value of tailored solutions instead of relying on the “one-size-fits-all” approach of Googling every time there is an issue you stumble upon. The idea is that it should evolve over time and grow like an assymptotic function of the time spent working on the codebase and time spent on copy-pasta: if you document your findings, if you know and leverage it to adapt it to your domain and if you write it down, you will soon realize that there are repeating patterns in the classes of problems for which you need solutions, especially because structural problems, besides being rare, are almost always the same, or at least, they should be if the code base is consistently maintained and follows a pattern together with the domain it is modelling.

This is the attitude that makes us walk on the path towards true wizardry instead of spending a long time of our careers feeling dazzled by all the “magic” we face everyday in the form of new frameworks, new language features, etc.

If, us, all of us, as engineers would truly understand this, I believe we would all be much better collectively, as a field. Unfortunately, it seems we are not quite there yet. Thank you DHH for such a great and important article in these strange times where shallow knowledge is celebrated.