"Laziness is my superpower": 5 qualities of an ideal Software Engineer

— I am a Software Engineer to the bone. I have been in the profession for almost 23 years. Most of that time, I worked as an engineer. For the last five years, I have been a Delivery Manager and Product Owner. Now, I am working together with colleagues to create a product as part of the EngX initiative. I continue to program, write code.

Who is a Software Engineer

Who is a Software Engineer today? This is someone who is engaged in engineering activities in our industry, namely the creation and maintenance of software. Business analysts, developers, testers, DevOps — everyone you can see at a team meeting, they are all Software Engineers with different specializations. A modern engineer should have developed engineering thinking and Agile thinking at the same time. We work with rapidly changing technologies, complex business processes, and diverse ways of interaction, so we need Agile thinking in order to be effective in work, and engineering thinking to be productive.

There are two terms that I think many people misunderstand: Agile and Full Stack Developer.

Agile

— Agile doesn’t mean "flexible" in this context. Agile is about adapting to constantly changing external and internal conditions. I can understand the error of the translator who translated Agile Methodology as a Flexible Methodology. The word "flexible," though, is associated with a change in shape and with pliability; that is, with adaptation through a change in one's internal state to external conditions. The word "agile" is associated with the speed and direction of movement. Unlike “flexible” the word "agile" is much more consistent with the concept of Agile and what businesses expects from it. As engineers, our task is to be ready at any moment to change the direction and speed of movement in order to meet the new requirements of the market in which our software works. This means we should not have extra "fat and tails," which prevent us from being agile; I am referring here to technical debt, poor code quality, lack of unit tests, etc.

Full-Stack Developer

— We consider a Full-Stack Developer to be a developer who can cover both Back-End and Front-End. Customers understand Full-Stack as a full development cycle works: from collecting requirements to release. The developer must know and be able to:

• Collect and clarify requirements, interact with a business analyst;
• Interact with the UX designer to understand UX and implement it according to the project goal;
• Understand the architecture of the application and follow the code standards established by the architect;
• Write and review code so that it conforms to the architecture and quality standards adopted for the project, work collaboratively with other developers to reduce the number of errors, and, accordingly, the overall development time of the application;
• Test their code and its integration into the application, create unit and auto tests, actively interact with the testing team; and
• Create build scripts and interact with DevOps when deploying the application.

— The work of a Software Engineer is done when the application gets into production, works there without errors, and benefits the end user. A Full-Stack Developer is a Software Engineer who does everything from start to finish — from requirements to delivery. They participate at all stages of the software creation process.

A developer who creates their own pet project, as a rule, does everything themself: from collecting requirements to deploying/delivering a product. In large companies, and on large projects, these functions are performed not by one person, but by different engineers with different specializations. But it is necessary for a Full-Stack Developer to understand and participate in all areas of the production of the final product.

What qualities should a Software Engineer have

— We at the EngX (Engineering Excellence) initiative have been thinking for a long time about the qualities that an ideal Software Engineer should have, and have concluded that engineers should:

1. Be inquisitive.
   This means: look at the world around you, don’t lock yourself in, don’t stay in some limited flow; be interested; participate in various activities besides the project; go to different hackathons; and attend meetups on new technologies. Actually, hackathons are better than meetups since you can practice writing code in them.
2. Have a sense of proportion.
   A curious person can get hung up on abstract things and delve into excessive improvement. It is very important for an engineer not to abstract the product from the outside world. You need to think about the end users, about what kind of product you’ll end up with and how soon they will receive it. The profession of a developer is not just writing code and loading testers with work. Caring about the result, awareness of your contribution to the world — these are the principles that an engineer should be guided by. The engineer interacts with the rest of the team so that their changes are integrated into the overall system and work properly and on time.
   The concept of right on time means doing what is necessary and sufficient to meet the requirement, in a way that allows the rest of the team members time to do their work on the same requirement. But do not forget about the quality of the code, which greatly affects the future "just in time" development. And early detection of bugs is also crucial. The sooner we identify a problem, the less time will be spent on solving it. That’s why we carefully read the specification and point out errors in it.
3. Be able to work in a team.
   Juniors often cannot get work in large companies precisely because they have no experience working in a team. In large companies, no one works alone; everything is done by a team. The sad thing is that most online courses and mentoring programs do not provide this experience. Most of them are aimed at individual work, individual study of the material, and individual practice in writing code. They do not provide knowledge about how to: collect requirements, design an application, test it, install it on a server or create a distribution kit, in any way other that working independently. This is very short-sighted, and a problem that needs to be addressed somewhere.
   Of course, specialists can be trained. Training is complicated, however, by the fact that there will inevitably be a lot of mistakes that may delay the project. Plus, as the trainee, you need to find a person who will tell and show you how to do things properly. Such a person is a valuable resource. Working with one will help juniors and even the middles quickly join in the work and be productive.
   I had the experience of creating a project lab at EPAM, in which I gathered junior students into two teams, and we did two small projects. I acted as a Product Owner and mentor and trained them as a team that produced a full development cycle. I showed them that working on a project is not just about writing code, but involves many things: working out requirements, testing, deployment. After three months of working on projects, the students said that they had gained good experience and an understanding of how to work in a team.
4. Be lazy.
   You've probably heard the expression: "Laziness is the engine of progress." This is exactly the case. I call laziness my superpower. This, of course, does not mean that I am not doing anything. Your laziness should be such that with a minimum of effort, you get the maximum result. If, for example, there is some kind of routine action. I'll take the action once, but for the next time, I'll come up with some simple way to make sure that it requires less time and effort from me. If you do everything head-on every time — meaning that when you are given a task, you immediately do it — that's not good. Instead, you need to think. Be too lazy to do it right away, find a simple, beautiful solution that will provide more benefits and take less time and effort to implement. In general, an engineer should think more and do less.
5. Don't slow down.
   This may seem to conflict slightly with the previous suggestion. There is an expression: ”Fast try, fast fail”. This means that it is better to try to do something sooner, quickly confirm that it does not work, and abandon the idea. It is difficult for us to accept this. We were taught not to make mistakes. In fact, mistakes are acceptable; people learn from mistakes. If we are afraid to make mistakes, then we will think for a long time, verify, and still will not avoid falling.

A good engineer should have qualities that contradict each other. Be passionate and measured, be lazy and don’t slow down. It is important to find a balance between these qualities and employ them correctly. You do not need to do everything head-on at once. The most direct way is not always the fastest, you can burn out from excessive efforts. But you won't gain the experience you need without mistakes.

Of course, do not forget about soft skills. All people, in all positions, need them. Juniors need them for successful work in a team, more mature specialists need to develop them to move further up the career ladder.

What to read

— And finally, my top 5 books for a good engineer:

1. Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin;
2. Code Complete by Steve McConnell;
3. The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin;
4. The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt; and
5. Elegant Objects by Yegor Bugayenko.

Do you want to talk about Engineering Culture? We invite you to Discord Anywhere Club.