Posts Modern software engineering or just a gardener's job!?

Modern software engineering or just a gardener's job!?

You might be wondering, why the title seems like a click-bait, but matter of fact, you’re caught in it just as you were when looking for your next gig, big promises and lot to learn… excitement… big project… modernity… things I didn’t mention but you saw/experienced, then the impostor syndrome hits you and you wonder, what next?

You’ll read that, lately there’s deficit of “Software engineers”, globally!


software engineering is in high demand

That’s just a fancy title that companies use to gain “TALENT” while making you insecure (with all their niche demanded skills), but I think that the perfect title should be: Senior software engineers are in high demand, there’s a flood of juniors and trainees.

Why’s that?

Most companies cannot afford to train a new developer matter of fact, they don’t even know how to…

also there’s the problem where many senior Software Engineers that want to take over a leadership role are incredibly rare, probably because they don’t like to just read code reviews all day just to get asked in meetings why other tasks aren’t done?

Not everyone is cut out to be a teacher/mentor to someone, some people just aren’t good at teaching, but if a person can describe a complex solution with less than two sentences without loosing the other side’s attention, you know you’ve hit jackpot, then there are people who want to teach, those are golden.

Your problem isn’t my problem, until you become my problem

Toxicity is everywhere, even in this field (sometimes fairly more than others), ego is one hell of a downer.

If you are not part of the solution you are part of the problem.

How many times you’ve dreaded to help someone on your team, you were asked to, everyone has, even if you’re a nice person sometimes your day isn’t your best day or another X reason, but that’s not your problem and then suddenly it becomes your problem.

We as humans tend to lean towards the easiest possible solution, sometimes it’s really easy to ask someone and you can grow quite comfortable in this area, rather than solving the problem yourself. Wasting half a day or even a day, just because your estimate is running out of time.

Other times it’s the XY problem.

The affordability of your time can be the mistake, the affordability of other’s time can turn out to be your mistake too if you don’t know how to communicate and be direct to solve the problem, hence you’re creating another problem this way, this can go on and on.

The other time you get a problem of quality vs quantity, as a company we’ll hire 5 seniors and 10 juniors, you expect juniors to do “support” aka clean shit, and later on train them using the knowledge provided by the seniors, but sometimes you as a company throw so many shit in the seniors hands that it even blocks their vision and drowns them, then you ask them why does it smell like shit in here?

This of course isn’t your problem, untill you become their problem.

But you didn’t create the problem yourself huh?

It’s usually the employees that are scapegoats, just ask yourself what if you died tomorrow?

The company you work for would put an ad right away to replace you as fast as possible.

Coding != Engineering

I remember one day when a client asked me, what’s the best way to encrypt data?

Then I striked with my answer that, hybrid encryption is the best way to go forward, they didn’t even ask me what I meant by that, it’s just as if they knew what the hell I was talking about, I was confused and asked them: “Won’t you at least ask me to explain what I just stated?”

The client: “We were waiting for you to ask this particular question, as there’s a difference betwen a coder and an engineer

Honestly I was confused but it made sense in my head.

I went on and explained that the way to go forward is to encrypt the data using symmetric key and then encrypt the symmetric key using asymetric encryption, I’ve trained myself to explain stuff is always stating the why first?

The symmetric key that encrypts the data is sitting on client’s storage, it’s cyphered and doesn’t make sense even if it’s readable.

I was applauded and I got revelation about what and where I’m currently situated, if you (the client) is reading this, thank you for what you said:

“Design and think it first, then explain it as simple as you can, we seem to never have time to do it right, but always have time to do it over and over, might as well do it right in the beginning”.

Then I thought of what I said to my friend one day:

“Proper architecture is expensive, but have you tried no architecture or bad architecture?”

The difference between a coder and an engineer is in the process of doing things, thinking about things and encompassing them later on, it’s what separates the pioneers from the rest.

Refactored drama

All new stuff is refactored big and old shit

Sometimes you might ask yourself, are we even really engineers?

One day as a joke to my colleague I told her that I am a code gardener, didn’t realize the impact and the truth of it until I sat and took a big dump in the WC.

It all starts when you think, oh okay I have these 4-5 lines of code, move it into a function, sheesh: let’s create a layer that’ll help us reuse the code, omfg: whine about which new shiny library is better than the previos one, unleash the rage: programming language X vs Y, cross platform solutions: shoot yourself in the foot and keep asking yourself about why you never wore a shoe but you were holding a gun in the first place.

It’s all just drama and most of the times we tend to be the queens in it.

Then burnout happens.

Did you just really “engineer” a solution or applied some gardening?

  • Refactor this function
  • Change this button’s color/padding/margin/text
  • Fix this bug that someone from 2012 left here
  • Sprinkle some water on the unit tests you didn’t have time to write but they’re in the desert now dying out, cuz no one gave a thought that they need to be maintained too, not just the code

The more philosophical breaking down of the problem you do, the more you’re facing existential crisis.

Realiy is often disappointing.

Work from home, but be “agile”

The biggest bullshit of these last few years.

Don’t get me wrong, I love working from home, not wasting 2 hours on commute and sometimes listening to talks about the “weather” all day or what we’ll be eating is the most peacefully rewarding thing one can get.

One thing that has been bugging me since I started working from home is that sometimes your thoughts shouldn’t be a meeting, meetings have grown a lot once we started working from home, at least on my side.

The number of “grown” ass companies that can’t understand the differences between agile and waterfall is depressing.

Sometimes your company doesn’t even need these things, remember when everyone tried to copy Spotify’s way of structure but then even Spotify themselves abandoned it because it was a disaster?

Now it’s the same thing with agile, but they just don’t understand, until something replaces it as the next big thing, so that your bosses can advertise that: “we’re using this methodology, we achieved excellency”.

Corporate leadership can’t “feel in charge” unless they’re interacting with people face to face.

The ego-gratifying whiners can’t shake hands now, can they? Too bad that they won’t be center of attention, now you can easily give them the vouchers they gave you for free psychological counseling, because they need it more than you do.


Nepotism is widespread in general. Tech is no different.

“it’s not what you know, it’s who you know”

Although not everywhere.

Clever code doesn’t necessarily mean good code

Debugging code is twice as difficult as writing code.

Clarity and maintainability (which are related, but some might confuse them that they are the same thing) are crucial when coding, and these two things should be the first that you think about followed by: test coverage, documentation, training, security, future-proofing, scalability, etc.

What I find more concering is “best practices” or “new best practices”, these are highly contextual and not necessarily applicable to you or broadly, don’t accept these bindly, it makes you look like a total idiot.

Scalability is a costly feature, both in time and in nerves, and a very complex one to achieve.

  • Don’t build it if you don’t need it.
  • It’s hard to do right (just as the right architecture)
  • Screw it up now you have three problems:
    • no scalability at all
    • buggy complicated system
    • let’s do it all over again because we gained more knowledge now

Designing scalability is really good, BUT if you know how much you’ll need to scale and what that scaling entails later on.

Naming is more important than you realize, vars should mostly be a noun (with exceptions), but making something really descriptive without being long is a discipline, even one can name it an art on it’s own.

Doing MR/PR reviews is really hard because, It’s harder to read code than to write it.

The tendency of destructuring a problem boils down to a complexity of one’s codebase, even if one person wrote it, i’m pretty sure that they can’t remember what they did and what they were thinking at that time, comments are useful for that purpose and should be IMHU added only when you need to be reminded what you were thinking when you created that and then you’ll know the purpose.

What is the most sophisticated piece of software/code ever written?

Googling is one of the most important skills for every developer!

Software engineering cults

You’ve heard of TDD and tried to do it, you have a benefit from it, then it turns into a cult, but why?

I’ve read somewhere that: “Tests, like any code, should be deleted when their value is lower than their cost.”

And I agree, tests have their lifecycle too, you have to maintain them, many huge codebases don’t have tests but have more QAs, tests have saved my ass many times and I do recommend them, but for the sake of your sanity, if you ever write tests before you write the code, you’re wasting precious time creating inflexibility that is abundant after some time when criteria or demand changes and you’ll end up doing two times the work.

It’s not just TDD, like agile, many things can be called cults.

This article will be hated by TDD activists.

You and only you

It’s you who matters in this story, whenever your guts tell you that something isn’t right, you better listen to them, it’s your body reacting to something, whether known or unknown.

Sometimes you need to make big descisions, they may take days, speak for yourself and tell someone you need to think it through, sleep through the problem, take a shower, go hiking, fix an open-source bug someone has wasted years on and hasn’t found a solution, die many times in Dark Souls 3 but don’t make a swift decision just to please someone else’s need.

Big challenges will come your way, adaptability is one hell of a double edged sword which can make you good in the short term, since it will allow use of existing labour shared in form of knowledge but on the other hand too much adaptability can stray you in an unclear direction where you’ll revise yourself.

It’s important to know the way by having it walked even if you have scars to shown rather than knowing about it!

Same as this article.

This post is licensed under CC BY 4.0 by the author.