I am very pleased to present another guest post by our good friend, The Male Brain, who took it upon himself to translate a lengthy blog post by Israeli writer, Udi Hershkovich, from the original Hebrew into English. I present his translation here with only a few minor edits here and there. The post is essentially a deeply cynical, and very funny, take on how to survive in the tech industry as a programmer. Having been through quite a few coding hells of my own – some of them self-inflicted, admittedly – I can attest to the validity and robustness of these principles from rather painful personal experience. As always, my thanks to Dawn Pine for his hard work in educating and amusing all of us here at Didactic Mind.

Original post

Foreword by Dawn Pine

I came across this piece a few days ago. It is both humourous and enlightens us about the realities of the work place. So I decided to share it with you. Also, all the rules were already written as a blog post by the guy, so when he says “Copy-Paste”, he means it literally.

Pre-Intro

The techie’s Ten Commandments for juniors and veterans, on how to survive the Middle Eastern section of the high-tech industry [TMB – relevant to other sections as well]. Copy-Paste-Save. Cynicism and humour are required plentifully. You have been warned.

Intro

Friends, there is hope. We have a new generation in the high-tech industry. How can I be sure? It is because just this week I lectured students on “How to survive coding” at a distinguished academic institute. Well, what can I say, we have someone to count on.

I decided to chip in and give you, my semi-faithful readers, the essence of “How to survive coding” to help you fit in, survive and even flourish within the rich processes, methodologies and hard-pressed managers, aka the Mediterranean chapter of the global high-tech industry. Now all you need is to Copy, Paste and Save (if you really want you may Print). All the details and rules are right here.

Rule 1 – Find Someone to Blame

This is the most basic, most essential rule of all. Before you even begin to code, make sure you have someone to blame for all direct and indirect damage from the code (which you may need to write or rewrite). There is no shortage of candidates: Architects, Documentation, Testing (QA) or the other team. Whoever you feel like. Why is it so important? Because, when the bugs arrive (and they always do) all those guys will come crashing in to blame you. That’s why you need to be prepared. As the saying goes: If someone bugs you, Bug first (TMB – the original is if someone comes planning to kill you, you should hurry to kill him first)

Rule 2 – Working? Don’t Fix It

As the old folks in high-tech say: “Touch-Move, You break it – You bought it”. Nothing good ever comes out of it. And yes, even if it doesn’t work, don’t touch it. It is possible and highly recommended to let others break their sweat and keyboard. It is empirically and statistically proven that touching the code only makes things worse. So why would you? It is going to get worse anyway, so why risk it?

Rule 3 – Spaghettification – the Code Always Becomes More Complex

Don’t fight it, it is a law of nature. The second law of thermodynamics states that the mess increases to maximum in every system. Another good contributor to that is the “Course of generics”. It’s no wonder that academia is teaching complexity. I say, in for a penny, in for a pound. We should capitalize it. This is classic job security. As your code becomes Super-Complex, the odds of firing you diminish – as no one dares to or could touch your code. In other words: Why KISS when you can complicate?

Rule 4 – KISS

This one is also the cause and the effect of the previous rule. It all begins with juniors (aka “Implementation Wolfs”) futile attempts, due to hyper-motivation and lack of experience, to keep the code simple, readable and understood. Futile, pointless and to no good effort. After a couple of code reviews, everyone can tell it is not a case of “Keep your code Simple, Stupid!” but of “Keep It Simple if you’re STUPID!“. To sum it up: “You start at your most complex and make it more complicated.

Rule 5 – Just Ask, Shy Does Not Code

It seems that juniors suffer the imposter syndrome. We the veterans know how much we don’t know, and how much we BS our way through life. As much as you feel shame to expose the fact that you know nothing, it only gets worse. Ask now, it’s cheaper. Oh, and better ask someone that actually knows the answer. Even better, ask someone who not only knows better, but will do it for you. Just ask, as there are no silly questions, only silly people.

Rule 6 – The Code Principle of Uncertainty

This one is quite mysterious yet highly important. Don’t try to figure out why your dose suddenly runs well. You know how everything is working and then you review the code, and have no idea how the hell it doesn’t crash? DO NOT TRY TO FIGURE IT OUT. Let the miracle happen. Once you dig in and try to figure it out, the code lifts its head, looks around, and tells himself, that “Yes. I ain’t supposed to do that” – and halts. As the old high-tech folks say: “The software runs only when the code is hidden” (TMB – Taken from the Talmud. The original saying is “The blessing only resides in things that are hidden from the eye”). Note, that a sub-rule derived from this principle is “The Observer Effect”, which proves once and for all, that QA is unnecessary, but we won’t go into that.

Rule 7 – The Unbearable Lightness of Coding

As a result of the last rule, no one (not even you) has any idea why and when your code works. So debugging is also unachievable, from a time perspective. Use it to stall as much as possible, while moaning, grunting and making general debugging frustration sounds every few minutes, while bingeing on the latest Netflix series. The best practice is 20-80 – 20% feature development and 80% trying to figure out why the hell is it doing what it wants and not what I want. BTW, the 20% coding isn’t that hard. Most of it can be summed up by the two magic words, “Copy-Paste“. No actually writes new code, as someone has already written it before. No wonder that programming is the oldest profession – old as in “repeatedly copied” (TMB – sounds better in Hebrew, as “old” and “copy” have a similar ring to them). Also – this post is also one big Copy-Paste.

Rule 8 – All Credits are Not Created Equal (or The Rule of Minimal Action)

There is no correlation between the time and effort invested to the credits. The selection criteria are, “Work as little as possible and earn as much as possible“. Assignments should be wisely selected. So, no “new challenging and exciting” technologies. The chance of failure is immense: No one to ask, no one to copy from and the worst of all – NO ONE TO BLAME (No wonder it is called “cutting edge”, your flesh is getting cut.) The best is owning the code of a recent employee. Fix it – and you are THE MAN. If it doesn’t work, it is that guy’s fault. Win-Win. If by any chance you get to actually do some work, demand all the credit you can get. Basically: It doesn’t matter what you did, what matters is what they think you’ve done.

Rule 9 – Constructive Ambiguity

No commitment. Not to quality, not to quantity and especially not to any schedule. When asked about delivery date, use the following keywords: WIP (Work In Process), On Track, Business as usual and so. If you are being pressed for a deadline, you go to the extrapolation phase: Documentation needs to be updated, testing document should be written, oh and integration time must be taken into account. Loads and loads of buffers, so it’s somewhere between one week and three months. If needed use Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Rule 10 – The “Head to the Foxes” effect

[TMB – In the Hebrew tradition there is a saying: ” Rabbi Matyah ben Cheresh used to say: … Be a tail among lions rather than a head to foxes. ” [Mishna Avot 4:20]. This is usually interpreted that it is better to be a small fish in a big pond, than the other way around.]

Effective work is clearly defined: Your manager is more pleased with you than with your teammates. That is why you should be head of the foxes, rather than a tail to the lions (no wonder everyone in the Israeli high-tech sector is a “Head of” something). So keep nearby a junior that codes at least 2.5 bugs per hour. Your best bet to move forward is by your peers failures. In order to survive and succeed you don’t have to run the fastest, you only need to outrun the others.

And the smart engineer says: The most important rule is Don’t Panic.

In Summary (or – Below the Line)

What can I say, I tried to minimize the rules of code survival to 10 basic rules, and a lot of topics were left out: The systematic procrastination principle, Parkinson’s law, the “way too much” emails and work meetings known as ” In Search of Lost Time“, of Work-Life balance and the importance of timing in finding and solving bugs, not to mention sucking up to the manager and so on. I do need to save something for next year. In the mean while I’ll share some of my trans-studential experience I had before the lecture.

It started with getting there 1.5 hours before I should have, due to pressure. After 2 years of Covid I can barely remember how to have face to face with one person, so having it with a few dozen? Anyhow, I was walking around campus. Campus? Don’t make me laugh. Those buildings can match any unicorn [TMB – startup reaching 1B$ value], duo-corn or even a tri-corn. Fancy sittings and transparent collaboration rooms and even underground parking! FOR STUDENTS! In my years, sometime in the last millennium, who ever dreamed of coming to class with a vehicle? Even if one did, one had to find some bush to park it on. Only staff had reserved parking. Today? It seems that students make more money than their poor professors, who made that fatal mistake and stayed in academia instead of making bucks in high-tech. (TMB – most professors I know actually work in high-tech, mostly as consultants).

While waiting in line in that stunningly designed cafeteria, a likable female student arrived, asking the barista (we see how the titles importance trickled out from high-tech) if they had oat milk! And to conclude that picture, some of the pizzas brought to the lecture were gluten-free. Who the hell knew what gluten was in my time? If one was sensitive, one either had stomach ache or stayed hungry.

It seems that the students are ready for high-tech, totally. They are doing a great job in colleges and universities to train the next generation. Come over, the bugs are waiting.