Top 12 Things Every Software Engineer Should Know

The first version of this article had the title Top 10 Things Every Software Engineer Should Know. Since then, it has been visited by tens of thousands readers. Some gave me feedback and I learned a lot from these comments. Many Thanks!

Contents

The list is still a personal collection of important things I could learn in the last twenty years as developer, project manager, line manager and IT architect in various industries. As an individual selection of what is important, it doesn't necessarily reflect the opinion of software engineering organizations and/or some experts.

There is no strict ranking in the list - though I tried to put the more important things to the top. The technical and business know-how is more important for younger software engineers and the soft skills getting increasingly relevant for senior software engineers.

Fundamentals of Emotional Intelligence

Almost all of us work in teams. In my first year after university, I had the opportunity to work on a clear big task without any customer and the need to talk a lot with peers. It was pure haven. Just do a complex task and have fun with the compiler. Later the trouble started with more complex tasks, increasing responsibilities and the need to work with people I didn't liked at all.

During my professional life, I attended some so called soft skill courses. In these lessons I learned a lot about communication techniques, negotiation strategies and team dynamics. All this have been mechanical tools or psychological theories. Good to know, but the concept of Emotional Intelligence is something different.

The Wikipedia definition of Emotional intelligence starts with the sentence "Emotional Intelligence (EI) is the ability to identify, assess, and control the emotions of oneself, of others, and of groups." [1] The important key word in this sentence is emotions. Emotional intelligence describes the role of emotions in our lives.

Some years ago, I attended a project meeting with some senior management and the boss of my boss said something to me which sounded like "Markus, you forgot to give me the information XYZ in time!" I felt embarrassed, like a culprit and explained him that he was not right. The result was that I won the discussion with him and from that day I lost an important supporter in the company. My reaction was stupid and worthless. Yes, I won one battle, but lost the war.

The root cause of this disaster was an automatic reaction on my site and a reciprocal effect between this senior management guy and me. With better sense of self and self-regulation, I would have been able to manage the situation in a better way.

If you leave sometimes a meeting and say to your self "Oh shit! Why did I say this?", maybe it would be a good idea to learn something about Emotional Intelligence and yourself.

Algorithms & Big-O-Notation

When I stated to develop software it was absolutely necessary to know a lot about data structures and algorithms. The reason for that was the missing availability of standard implementations. Today most languages have comprehensive libraries for container, sorting and other operations.

Still it makes sense to know more. There are two main reasons:

correct use of the standard libraries and
some times you need individual solutions.

You should be able to analyze your own or others code. The Big-O-Notation is the standard method to describe the expected consumption of time or memory depending from the number of data. [3]

If a manual analysis is too difficult, just make a micro benchmark and measure with test data of different size. Draw it in a plot and find a good fit of a possible model function. This is always better than nothing.