In these recent days, I’m beginning to realise, how important it actually is to have a good mentor. To have someone who actually dedicates themselves, their time, energy, brain cells, etc to someones development, wellbeing and improvements. I’ve always known that in a way. But some things, over time and experience, you understand differently. More profoundly. This is one of those.

From time to time, I help out a really close friend of mine for something in his professional life. Either it being a mini debug session because an ORM is giving him issues, or some thought exchanging, guiding. I hate to brag, but I am in luck to have a lot more experience than him, so I tend to help out in any way I can. Even though, that is not nearly enough. We are not having full work days together and the luxury of working together so I can actually work with him on developing certain areas.

In those help out sessions, from time to time, I have a peak into his code. To be brutally honest. Quite often my reaction is, “oh my god“. His code is not bad. It’s actually done really well. On his level. But, his level should be quite higher in the amount of time has passed him being employed. So, my reaction is actually not aimed at him at all. I get disturbed by the non-amounts of time dedicated by his senior peers to him on his development. Even though he is solving complex problems in a good manner, he still has code blocks with:

public async Task<Something> GetThis() 
{
    await ...
    await ...
    await ...
    // Pardon my C# writting, I have never worked with it in my life. 
    // Though read a lot of its code
}

In my opinion, after two to three years of working experience, you should understand that having everything async, but await everything as well doesn’t really make sense. This tells me something else. No senior has ever challenged his perspectives and understandings of architecture/code design. They haven’t dedicated time to him to explain why this might not make sense. I was the first one. That pisses me off.

You don’t know what you don’t know

You don’t say Pavle?

Yeah yeah, I know. Stating the obvious here. But, think about it a bit more. You can’t even begin to comprehend something if you don’t know about its existence, right?

Yes, you can learn everything in the world on your own. But it would take you way too much time. Thats what the education system is for (not getting into it is it good or bad). Just imaging having to learn math from scratch. On your own. No books or anything. Well people had to do it for quite a huge number of years. Now with books and teachers, all that learning is squashed into few years of your life.

Same goes for mentoring. If you let a junior, wonder around, poke stuff and make it work somehow. Without guidance and knowledge sharing. They are going to be wasting huge amounts of time. And in the same time, expectations from them will rise, because if you work for two to three years, your potential future employers (or current ones) will expect certain levels from you. That you might not have. Not because you are on the wrong side, rather because you didn’t have any help and you are on your own. Lets be honest, advanced and good self learners are rare as diamonds. We all go through professors, books and mentors to have a good jump up.

Why you should mentor someone?

I was extremely lucky to have great mentors in several places I found myself working. From the very beginning (Shoutout to Victor and Igor). Yet, now I can be even more thankful to them, when I realise just how much it is important.

I encourage you. Take care of the less experienced. Teach them. Guide them. Challenge their perspectives and help them improve themselves where ever you can. Sometimes, that might get personal. Where you might need to help with a personal problem. Most of the times its code, design, software philosophy, etc. One of the most beautiful and fulfilling feelings is helping someone be better. And letting them take all the credit. Because it is theirs.

The biggest benefit of all. You will grow a lot and learn a lot. They can, should and will challenge your perspective. Their out of the box thinking pushes you to learn more and understand something more deeply.

Don’t fall in the trap that you have to control the knowledge. That you have to make every decision. That you have to be asked for every opinion. You destroy your peers improvements that way. Focus your efforts into them going through all of it with guidance. Sometimes pushback. It will be worth it in the long run. As they say, the best team lead (or manager) is the one that has to do absolutely nothing in his work.

What a Sunday rant. Have a nice one.

This brings unnecessary complexity to our code. Even though on the first hint it tricks us that it’s more descriptive and readable, it requires more effort by an another engineer to understand the code. Probably ourselves as well, just in a few months when we come back.

It’s also quite related to the code complexity learning curve meme of a Junior Engineer to Senior Engineer. Whereas more seasoned engineers like to keep it simple. There’s another picture that reminds me of it:

What is the cognitive strain of our brain? Basically putting a cognitive strain on the brain means that we are tiring it. The amount of cognitive complexity of our code is directly proportional to how tired someone is going to be and how much effort and time someone has to invest to go through and understand the code.

One extreme is being completely oblivious to the code we are writing, like naming all of our variables a, b, c, d, i, k, l . I’m trying to tackle the other side, overengineering and overcomplicating it.

Let me give you an example.

I write my examples in Go because I’m focusing on it now and working with it, but this is applicable to any environment. With the note that all environments have their own conventions on how-to.

func GetPrices(currency string) (http.Response, error) {
   //... Setup code - includes creating client and httpRequest

   resp, err := client.Do(httpRequest)
   if isResponseSuccessful(resp.StatusCode) {
    // Do something
   } else {
    // Do something else
   }

   return *resp, nil
}

func isResponseSuccessful(statusCode int) bool {
   return statusCode == 200
}

Here we see a function that will make an HTTP request to get a price of a currency. I’m not focusing on some details to not overload you (you see what I did there ;) ) with Go as a language and basic setting up of an HTTP client.

What I encountered numerous times is functions and methods getting extracted endlessly but totally unnecessary. Here to achieve a more nice descriptive naming we extracted a response check to a separate function that does a really basic job. But to me who is going through the code the first time, I have to ctrl/cmd + click it to see what the function is doing. Because, what is a successful response? HTTP 200? HTTP 201? HTTP 2xx? Who says that the function name is telling the truth? In reality, it will be slightly more complicated than statusCode == 200 . Either way, we will have to jump down, jump back up, and try to remember where we were the moment before. All of that could be avoided by “making it a bit more ugly” (even though I don’t agree with that):

resp, err := client.Do(httpRequest)
if resp.statusCode == 200 {
  // Do something
} else {
  // Do something else
}

Here, we immediately know what is happening and what is the goal. Let’s face it, all engineers know that status code 200 is a successful response.

The issue arises because cognitive complexity is incremental. This small function is no big deal. But over time, function by function, method by method. We gain hundreds of methods that are not used anywhere else just to stamp them with a nice name.

Another example commonly found is:

func Something(listOfItems []string) {
 item := findItem(listOfItems, "item")

 // do something with item
}

func findItem(listOfItems []string, item string) string {
 for _, listItem := range listOfItems {
  if listItem == item {
   return listItem
  }
 }
 return ""
}

This looks like some for manual job that you usually don’t encounter, but in Go, it’s quite normal. We don’t have fancy .find() methods. :)

Here we find ourselves yet again in a situation, where we would have to go level down to the function, understand what it’s doing and come back up. All for a nice name for the most basic for loop you can see. When this gets incremented over time and amplified it’s really hard and tiring to jump through the matrix up and down to understand simple code.

Let’s try to write simple code, maintainable code and code that we understand easily without firing up our brains to some levels.

By the way, Go is a phenomenal language that is addressing this issue. One of the main purposes of Go is Keep it simple. I think anyone who appreciates that will appreciate Go as a language and could try it! I encourage you!

Keep in mind, this is not related to designing your codebase, your architecture and others. That’s a whole other topic.

I’m obliged to give enormous credit to two people and a book.

My first mentor from my first company was one really talented and fun engineer. Unfortunately, I think I understood many of the lessons later on, but I understood them better thanks to him. Thank you, Victor!

The second is my former boss from Zühlke. He quite directly addressed this bug with me. He was discussing it with me and went into more detail with also recommending the book. Thank you, Igor!

The book is A Philosophy of Software Design — by John Ousterhout. A huge eye-opener and a good challenge to some coding standards. It’s quite small and short but full of beautiful details.

In addition to forcing a bad tech stack to a particular problem. For example, forcing NodeJs to do some .pdf magic parsing whereas a Java popular library does it out of the box with minimum effort, it’s quite a strain. People are skipping job offers with the most amazing teams and companies and projects that are not their stack.

It’s in the principles — not the stack

Personally, I started with the JVM world and have a profound love for it. In the beginning, it was Java, but later on, I stumbled upon Kotlin and got amazed. So for a while, my tech stack was Java&Kotlin on the backend. I guess I was boring enough to persuade my colleagues to introduce it to our project. Thank you Alex & Victor! Of course, as a Java developer, it is my honour duty to always talk s!@#! about JavaScript, npm and the whole package. I think that every time a Java developer that works with JavaScript runs into a silly JS problem has to do the sigh and say Fu!@ing JavaScript. But as life likes to do to it, I ended up with my company on a project that is working exclusively with NodeJs and Typescript. Of course, I had previously mentioned moments.

Over time, I actually liked it. But most of all it made me realise something really important. I was doing the absolute same thing as I was doing with Java or Kotlin, just in a different language. Especially since TypeScript is so similar to Java, I needed one full working day to adapt and for people to not know that I’m actually a Java developer. It helped me realise, the principles are the same everywhere! What I didn’t know out of the box, I could easily find in the docs or google it. Because I know what to look for. (By the way, big shoutout to NestJs documentation. It’s amazing!) I needed an endpoint, ok, let’s see how to make that controller. Oh, I need to connect to my SQL database, ok, let’s see how they make repositories here. Event-driven time! Cool! Let’s see how they do that in this environment!

You are always solving similar or the same issues, the principles always apply! You are designing a REST API. You are setting up a Book entity that you want to save to your relational database. You are calculating the time to execute something. You are reaching out to some third-party API to send a notification. All those are tech stack agnostic. Clean code and readable code also follow. Yes, languages have their own conventions that could differ, but if you have a healthy approach to clean and readable code, you will do it everywhere.

So don’t limit yourself. Don’t skip that opportunity because you never typed that language. Take it as a challenge to learn more, you will advance most significantly!

So when someone asks a question that is related to the topic. I like to say that I’m a Software Engineer, not a Java Engineer. Thanks to that mindset I got one of the most wonderful opportunities to work at Decenter with an amazing team developing DefiSaver. Here, we work with Go, and that’s quite a shift compared to the previous languages. But it’s super fun, I can rely on my colleagues to help out where needed, but for the most part, I can develop without any issues.

One of my favourite approaches is the T-shape approach. You are familiar with multiple sides and stacks, but you are proficient in one area. For me, that was the JVM world. But I have grown to like Go so much that it might grow to be the proficiency I’m after. Know your architecture, know your software design, know your databases, etc. Don’t limit yourself to the language and be brave to experiment. It will be a wild and fun ride!

I hope everyone is lucky enough, to have that one annoying friend, the friend that tells you everything as is. Honestly. Usually, it’s quite welcoming, but sometimes. Sometimes it can be one big pain in the a@!.

Well, automation is that friend and more.

Why I personally like automation

The software engineering OCD of course! 🙃 That is not a 100% joke actually.

During my day-to-day development, I try to automate processes as much as I can. Or at the very least, I try to make a collection of steps easier to repeat. Currently, I’m very lucky to work in a Go environment and we use Cobra to create our internal CLI tools. Oh, the happiness! Each time I stumble upon a repetitive task I try to make a tool so I can make mine and the life of my colleagues easier.

Personally, I like automating steps, especially in the CI/CD workflow, to minimize my potential mistakes. In addition, when you set up your automation to be good, it can be painfully ruthless. If you go to higher measures with linting, when you just forget that one indentation and you get an 🔴. That’s so annoying! I love it! Because it stopped me from piling them so the next time I do formatting it’s not a huge change.

There are a lot of boring tasks that automation can solve. Running tests, builds, etc in parallel. One of the most boring, but crucial tasks is setting up your local environment. That is especially useful for new colleagues. Even though personally I don’t use them because of Goland, the VSCode Dev container setup is amazing. You specify everything there and all a new developer has to do is turn on VSCode and start the dev container, and voila you are good to go.

Setting up your CI/CD well can also help you carry the load of all the verifications. Let’s say even that you would locally run tests, vetting, linting, etc. Why not just do git push and continue on, you will get your results soon enough.

You can even partially automate your PR review process. Introducing SonarQube to your CI, SonarQube can flag items for you, reducing the load on your colleagues for the first iteration at least.

Summing up. Automating our day-to-day tasks reduce the load you encounter, it will struggle with various setups so we don’t have to, it will be strict so we don’t become lazy, it won’t make silly mistakes with version bumping or the like, and the green marks simply feed the OCD.

Automation challenges

After attempting to sell the story of how nice it is, there is the other side of the medal as well. In the beginning, until you get the hang of it, it can be a bit challenging to set up.

When you switch to a new tech stack, a new git hosting platform or anything new. The pain is the biggest. Every little step is quite annoying. “Oh I forgot to run go fmt!”. The triggers for the CI won’t run when supposed to. They will consume too much time. You will fail and fail. But bear with it. Endure it a bit more and it will be rewarding. A bit of discipline is required.

The picture above is a perfect example. You will have to re-run your automation many, many times until you get with the flow of writing and expanding it. You might feel a bit stressed at that time, and you will be. But it’s an investment, just like everything else.

Going the extra mile

You can go even further. You can introduce an IaC (Infrastructure as Code) tool to your workflow. That brings version control, less forgetting, and taking care of a lot of things with it! For example, imagine you can just do

module "new_company_member" {
  // some data here
  // some data there
}

and off it goes and automates a lot of steps. Creates a Gmail workspace account. Creates an AWS IAM role, and assigns basic permission, sends invites for Slack, adds to mailing lists, alarm lists, etc. And in the case the member leaves the company, you just delete that patch of code, and all those items are revoked and deleted. So you didn’t forget to revoke that ssh keypair permission on that one instance for internal tools that could cost you.

In case you didn’t notice, I know it’s so hidden in the fine print. I’m a bit in love with it. I manage lot’s of my stuff with Terraform. For fun and practice as well. GitHub repositories, organizations, some account items, etc.

Summed up.

Automate as much as you can, all the boring tasks, all the verifications. Be strict with yourself (but make permission for emergency necessary flexibility of course). Make the CI/CD workflow. Let it be your honest friend.

Beautiful, harsh truth.

At first look, it doesn’t seem like something special, but if you think about it, you understand how true it is and how often we fail it.

This definition applies to all aspects of life, from eating healthy, exercising, reading, and developing software.

Discipline is a habit. If we nurture it, it will come easy to us. If we don’t, we won’t do what we should do.

Discipline in Software Engineering

To succeed as an individual, as a team and as a company we have to nurture it. And when motivation fails us, we have to rely on discipline. Otherwise, quite quickly we can find ourselves in trouble. Usually in form of technical dept.

It's hard, it's annoying and painful. But, it can be equally and more rewarding.

What does that mean for us Software Engineers? When you are tempted to take that shortcut to make it happen fast, don’t take it. When you start telling yourself and Tuesday 13:00 that you should have deployed these changes yesterday, don’t take the shortcut. Usually, it’s just an hour or two maximum of an investment. All those: “The release will be soon”, “I’m late”, “Oh look at the amount of code, I can’t write tests for that”, etc. are lies! At that point, our brain is just lying to us, trying to trick us to take the shortcut!

What do we get from that? Technical debt. What does that mean? Because we were too lazy to spend one more hour cleaning up or doing it right, over a period of time there will be a compound effect of those decisions. Then we will start feeling slow, not contributing properly or just plain unhappy. As one of the speakers, I listened to would put it:

Write those tests!

You know that feeling when you have some code and you really feel like not testing it?

That is exactly when you should write them. Go for a walk, go for a coffee and relax, and come back and ace it! Why? Because you before all, but also your colleagues will be very grateful for it. You will find logic, design flaws and bugs. Above else, you are going to be very proud of yourself! It will help you infinitely when refactoring comes.

Forming discipline for the non-obligatory things

There is another form of discipline you can nurture. You know that moment when you browse through code, and you spot a small segment of code that is, well, bad? It could be something even you wrote a year ago. It could be an outdated team convention. An ugly for-loop I guess? Instead of just skipping it, stop and dedicate 5–10 minutes for some quick safe refactorings. Rename that variable. Rename that method. Extract that if statement. Inline that method.

A safe refactor is usually something we can completely rely on our IDE to do. For example, renaming a variable or a method. The IDE will take care of it without you going around clicking ctrl+c ctrl+v.

In the same way, you have a compounding effect with bad decisions, you will have one with good ones. If each member of the team does this (even if you start that's amazing), PR-by-PR your code will be cleaned up! And you know what comes into play here? Tests! If you wrote those tests and weren't lazy, you are going to want to kiss yourself here for having a safeguard for refactors.

Everything is a habit. Bad decisions, good decisions. We are defined by the small actions we take each day, they all sum up in the end and reward us.