For The Past 10 Years, I Have Been Engaged In The Profession Of Software Engineering, And I Love This Specialty.

The speed of technological advancement has made the work in this field exciting. There is always something new to learn in the world of software engineering. However, the question arises, how to keep up with technological changes?

On the other hand, we should know what makes us top software engineers.

۱۴۰۱/۰۱/۱۷Release date

“Categories” of developers

In recent years, we have seen fewer job advertisements with the title ” Software Engineer. ” Most of these advertisements are published under the headings of Backend Developer, Frontend Developer, and Fullstack Developer. From a technical point of view, a full-stack developer can be considered the closest job to what a software engineer does. This is where the question arises: when did we become so categorized? Can someone trapped in this category escape it?
I completely understand the desire of software engineers to work in different fields. On the other hand, since everyone knows everything, a software engineer can’t be an expert in all areas of this industry. However, the fact should not be ignored that the software engineer likes to understand the production process of a product from the beginning to the end, learn new things, and work in different areas of product production. In simple words, it can be said that the software engineer, along with dealing with coding, wants to be aware of the product production process.
Let me tell you a short story. I am a software engineer. When I started this career, I was very excited about everything. I learned to code for a specific part of the product; it quickly became trivial without understanding other aspects. In this situation, the software engineer interacts less with other product developers. That’s why I thought if I could do something, why should I put the burden of doing it on the shoulders of my colleagues? There was no specific instruction to work in only one field in my educational stages. My education is in software engineering. Without a doubt, I could have done more with help from other colleagues. My colleagues also willingly helped me to do the work. At that time, as a young software engineer, I was thrilled with this situation. I thought I was doing the right thing.
Sometime later, I thought of learning about the front end. By the irony of the times, conditions were prepared for this request of mine. Interestingly, the backend team I worked with used Java, my favorite language. I tried a lot to interact with Java. I took on the tasks and fixed minor defects. An opportunity to program from scratch in Java was provided. It was at the same time that the identity crisis broke in me. Back then, I was known as a frontend developer, not a software engineer. It was here that I suddenly found myself in the category of job titles in the software industry.
You may be thinking to yourself that this is an extraordinary situation. There are countless jobs for frontend developers. I agree with that point of view, but one of the best parts of this career was the many things I could learn. I wanted to improve and increase my knowledge to become a better software engineer.

Way out of the developer “category.”

How do you think a software engineer can get out of this category? The answer is simple: by searching in other fields. I did that, but it didn’t work. In 2 years, I started learning and working with React and TypeScript. Sometimes I also worked with Node and Brand. The situation was not too bad. I learned much about working with cloud computing and coding a product from scratch. However, I concluded that I had experienced enough in other areas. I am a software engineer who has put aside Java and .NET skills for a while. This situation had to end.
I interacted with Node and Reacted for about four years in this project. At that time, I worked as a senior software engineer. The project manager’s performance was measured. NET. I admit I was disappointed. Not because I wasn’t a quick learner, couldn’t interact with other project members, or was slow; These were not the reasons for my disappointment. The problem was that I did not have the conditions and time to improve. In this situation, the software engineer’s identity crisis reached its worst. I wanted to learn more from .NET experts to improve my skills and compensate for lost time. The fact was that I had not devoted all the last ten years to it. NET. This situation made me feel like a terrible software engineer.
Sometime later, I worked with people whose main goal was coding. These colleagues did not pay special attention to product creation and interaction with its development process. They said to give us the requirements to deliver the code to you. These codes probably had many bugs and were not tested. However, what they were doing was something other than coding.
Let me stop at this part and tell another side of this story about the process of software development and product creation.

Engineering approach

Just as humans have many differences, engineers also have different ways of thinking. I am an engineer who wants to impact a product by coding. My effectiveness in the software development process is as follows:

• Understanding the product or part of it (to the best of my ability)
• By understanding the product, I know the problems we are trying to solve.
• By understanding these problems, I raise questions, concerns, and ideas that may help other colleagues in a product’s research and development process.
• By being active in discussions, I understand the acceptance criteria. Thanks to this information, I write error-free codes.
• Since I have already done basic technical research, I work more organized and get a general idea of ​​how to perform tasks.
• I recognize how easy or difficult it is to do a task.
• Finally, I gain complete mastery of tasks and perform them to the best of my ability.

 

 

As you can see, I did not mention any specific programming language in this process. Software engineering is not always equivalent to pure coding. The ability to solve problems and participate in the project is also one of the other skills of a software engineer.
According to the explanations that were raised, the question arises as to why capabilities such as problem-solving skills and participation in the project are known as the weak point of the software engineer. Instead of seeing this skill as a weakness, you should see it as a blessing. Thanks to such skills, you will become a full-fledged software engineer.
With this interpretation, software engineers are not separated into categories such as frontend developers, backend developers, and programmers. Software engineers cannot do all these things. However, it is better not to get too involved in these categories to eliminate the software engineer’s identity crisis. There is nothing wrong with being interested in other areas of the software industry besides coding. Put the knowledge you have learned into practice and expand your capabilities.