Being a software engineer is often misinterpreted role. Emphasis is most often then not on software and not on engineer aka engineering.

The reasons for this are multiple. Deadlines, complexity, lack of pragmatism and worst of all, lack of engineering.

Engineering

Engineering is not your code, your framework, your IDE. Engineering is your problem solving skills, your approach and eventual reach of solving a problem. Engineering cannot be measured. You either engineered something good or something bad. You cannot blame your tool for engineering something good or bad. I cannot blame a regular handy worker for not sustaining a roof enough so it doesn’t break. I will blame an architect or whoever designed the system which was suppose to sustain the roof but it didn’t.

CED

Continuous excusing development

I would assume this syndrome exist as a default state when it comes to most individuals and industries but I’ll mainly speak about software “engineers”.

CED refers to the state of mind of one who continuously complains or blames either tools or language for his spaghetti code. Such individual will in all circles and all circumstances, try to justify its own mess by blaming the stack for all his problems.

It’s suggested that you avoid getting into any discussions with such individuals before they are exposed to a proper CED treatment.

Symptoms of CED 🤯

• Continuous complaints about the language of his own choice
• Continuous complaints about the complexity of the tools of his own choice
• Continuous complaints about the complexity of the code of his own creation
• Picks the opposing side in all discussions and feeds on complaints of others
• Shares random social articles on how horrible something is
• Self-reflection skills lower than the unborn
• Proposes no solution or help on any of the complaints
• Has weak arguments or no arguments at all
• Blindly follows his twitter hero(es)

CED Treatment 🧠

In most of the cases, CED can be successfully treated. Exceptions are mostly individuals with horrible personality traits and only holy or unholy can help those.

For those patients who are willing to improve and learn, it is important to follow the following steps in order.

Raising the self awareness 😇

Very first part of CED treatment is self awareness. Identifying our own weaknesses and the things we can improve at is of the highest significance. Understanding what we know and what we don’t know will get us closer to identifying things we have to improve to be better at what we do, to be better engineers.

Think about the things you encounter every day. What are those things which are making you uncomfortable, nervous, stressed? Work on those. They can be code related, work related, social related. No matter what they are, focus on those and do your best to improve.

Understanding the problem 🤔

If I had an hour to solve a problem, I’d spend 55 minutes looking for the right questions to ask. - Albert Einstein

Like I said in the introduction, engineering is all about solving problems. We can solve the same problem in many ways but what we always seek for is simplicity, efficiency and time required to solve it.

It’s no secret that in software engineering is often different. I can’t even remember myself how many times I’ve started working on something without even thinking about what I want to achieve. I had no clear requirements nor an idea on what I want to do.

Imagine building a massive building without any design plans. We employee a construction company and we tell them what we want from the top of our heads. But even worse, we tell them that we expect the building to have 120 floors and that it should rotate following the position of the sun.

This is often how we think and how we approach projects and mostly, it’s the cause of fail projects, frustrations, lack of understanding and in the end, CED.

To avoid this, gather the project requirements and project specifications, do the extensive research on similar projects or problems you are trying to solve, discuss the problem with other experienced people and lastly, pick the right tools for the problem.

Be master of your language and your tools ⚒️

Fake competence hurts. We often read a five minute tutorial on something and we preach it to our friends the next day. We learn how to configure a 7 lines Webpack file and we are already Webpack experts.

This part somehow relates to the first point of CED (self-awareness). Lack of knowledge causes 99% of complaints toward most tools or languages.

When we are plainly familiar with something and not knowledgeable, we are easily prone to influence and we quickly come to conclusions. For that same reason, we will read a random medium or hacker news article and jump on a sheep train.

We should learn the core parts of our languages and our runtimes. Even more importantly, we should learn the principles of software engineering and how to build scalable and sustainable software.

We should make conclusions relative to our experiences and knowledge of a specific subject. This is the only way we will objectively be able to rationalize and argument about something.

And lastly, if we manage to reach all the points listed above, we will never again have a reason to complain as we will be competent enough to create our own tools or help improve the existing ones. And even if we still do complain, we will be able to do something about it.

To sum up, the best thing you can gift yourself with is self-awareness and objective approach to software engineering. Identify your own weak points, work on them and always focus on the problem itself. Be driven by arguments and concrete knowledge and you will be dealing with less side effects and less unknowns in your life and at your job.

Ignorance indeed often can be a bliss but in software engineering, there’s no space for it.