Erkut Evirgen

It has been about 5500 years since the wheel, one of the most genuine engineering wonders, was invented. The paper is about 2200 years old. The electricity is about 140, transistors reflect 100 years. Only 60 years have passed since the years when software engineering in its own form was known as engineering. Computer scientist and engineer Margaret Hamilton used the term “Software Engineering” for the first time while building navigation systems for Apollo missions. First master’s degree program in computer engineering at Seattle University took place in 1979 and the ADA Programming Language first appeared in 1980. The Rochester Institute of Technology opened its first bachelor’s degree programme in software development in 1996. The IEEE version of “Software Engineering Body of Knowledge (SWEBOK)” was published in the same year, 1996.

When compared to other engineering branches of human culture, computer engineering is a very young discipline. Yet, in history, no other engineering division has evolved so rapidly including the subjects it affected. Engineering devices like sonar, magnetic navigation, photoreceptors have benefited positively from this discipline. The predictability of the world of the other branches was what distinguished software engineering from other engineering branches. Software engineering continued to evolve as a discipline that has to be applied to a world where the laws of physics have changed weekly.

The only resource I had for the integration of a security dongle for a distribution business was the dongle manufacturer’s user manual at my desk and an email address to contact them when needed. It was a great experience for me to develop this application, because I would be able to transfer this knowledge that I have learned to my colleagues, or to share with other engineers that need it. And that information was of great importance. But now, the platforms like Google and StackOverflow etc simplified things with copy and paste which we do a lot. Now we don’t need to explicitly code algorithms that include calculus, trigonometry, and differential equations. We ought to be more relaxed, maybe. We couldn’t relax, though. Because the challenges faced by current software engineers have become more complicated and demands have risen for an average software engineer. They need to know the topics such as “Cross Platform”, “Asynchronous method”, “Security”, “DevOps”, “Distributed Systems”, “Asynchronous Process”, “Data Processing”, “Microservice Architectures”, “Domain Driven Development”, “Reactive Programming”, “Test Driven Development”, “Test/Data-intensive Development Environments”, “Containers”, “Orchestration Tools” and even more. Products can now be built to be open to millions, not as before, to a small number of consumers. An engineer who has no knowledge of TCP/IP literally writes a back-end service that runs on the Microservice Architecture on a DevOps-supported project without being aware of the cloud systems, is now a market-wide non-preferred engineer. They can save the day, but it won’t take long.

Years ago, I recall when using Kylix in an ERP development team for a company, I wrote an updater to get the final version of the executable file for the client from the internal network each time the application is started. It was so unusual and exceptional even for an engineer to be online all the time. The offline use of software and offline individuals are extraordinary and exceptional today.

Developing a new programming language, having knowledge about PL paradigms, writing a compiler or an interpreter were very idealist and romantic endeavours. The people who did these were the heroes of the academic world and they were the people of distinction. However, now, this situation can sometimes even be a weekend hobby of a young developer. There are dozens of new programming languages coming to the market every year, and some have set themselves up for learning a new programming language every year. Things are changing constantly, often unpredictably.

Each computer engineer has his/her own reason to choose this career. Some have made this decision according to the blowing wind, others have lost themselves in the magic of computers from a very young age, and some have believed they were just going to earn some money or status. There are also those who choose this career, either with the pressure or encouragement from their families, or temptation to choose the most difficult departments of college to join.

Nevertheless, if you have taken steps in this engineering discipline in some way, and you want to make yourself someone people always want to cooperate with, you have to be aware that it is critical to react quickly to uncertainty. And I strongly believe that you have to feel the pressure first in order to succeed.

In order to remain valuable in the industry for a long time, without compromising, it is important to aim at grasping certain engineering concepts. Here are some highlights that changed and not changed from these engineering notions which can make you important today:

Things that changed

Time Optimisation

The paradigms are evolving so rapidly. Improving your ability to recognise what one needs to be specialised in is important. For example, recognising that knowledge of distributed VCS systems is now a must, and being competent and adequate about it, but determining if Git is the instrument that is supposed to be chosen “today”. I put “Time Optimisation” at the beginning of the list, because distinguishing important from unimportant and deciding how to spend your time are the most significant skills in the industry today. It’s a remarkable subject to be able to operate the Pareto Principle effectively.

Deep Focus

It takes deep work and focus to be able to see a complicated system or a story in terms of simple parts or to make them simple. As technology progresses, anyone who does not develop this skill will probably be left behind. Staying in deep focus amongst distractions like mobile notifications, funny YouTube videos and WhatsApp messages, will be the one of the most distinguishing soft skills in the years to come.

Soft Skills

Although experience is even more relevant at times when access to information was difficult, now, at t=0, an engineer can reach any technological or architectural information easily. Just because some developers have stored this historical information (or a boutique knowledge) in a custom knowledge hierarchy, companies do not have to bear their bad personalities. Software engineers with zero social skills are going extinct. Engineers, who are cocky and whose communication skills are not developed, are not preferred by companies regardless of their technical level.

Knowledge of upcoming technologies

I’m talking about the people who try and put aside new technology/libraries/tools and move on. Trying Alpha Preview/CTP/Beta and the latest technologies you see coming up, libraries, tools, devices and reading some articles/manuals makes you much more efficient, desirable, searched and valuable now compared to the old days.

Things that didn’t changed

Continuous and Fast Learning

Challenges are very volatile and something new can come up at any time, unpredictably. Learning about something often implies expense, so it’s better to move early in order to break through the learning curve. Remember: “The more you know, the more advantages and differences you get.” Don’t say “I’ll learn it when the time comes.” It is imperative to attend conferences, monitor hot topics in universities, to join the IEEE and/or ACM, to become active and to expand the information network. It is necessary to review papers and be active in local organisations. There are engineers who instinctively do it right. But being able to express the theoretical context is also important.

In every software engineer’s reading list, these books should also be included:

Code Complete, Pragmatic Programmer, Clean Code, Design Patterns, Refactoring, Peopleware, Mythical Man Month, Algorithm Design Manual, Programming Pearls, Structure and Interpretation of Computer Programs

Behind the scenes

It is also a challenge to go to the root cause and behind the scenes to grasp languages, libraries and paradigms. You have to understand evolution and the history. For instance: Why does React.js have such popularity? To understand this, the individual must first understand the history and evolution of Javascript, how DOM works, and how DOM manipulation makes sense and why it is so common. The chronological cause and effect relationship helps to better understand the technology in question, as well as to understand whether to spend time in that technology or not. So, it is not important to use them, what is really important is to know what they are good for.

Fundamental Principles and Context

It is critical to internalise the concepts of SOLID, Design Patterns, General Principles (KISS, DRY, GP etc.), Modularisation Principles (Model Principle, Information Expert etc) and more (from Pragmatic Programmer Principles). One has to be aware of data structures and space and time trade-offs. It is not only important to know the difference between Arrays and LinkedList, but to explain the implementation of hash tables and handle collisions. One needs to be familiar with the entire programming stack, hardware (CPU + memory + cache + interrupts + microcode), binary code, compiler, interpretation, garbage collection, problems such as heap - stack, memory addressing, multi-threading, concepts of synchronisation. It also seems that knowledge of the network protocols, automated/functional/load and UI tests will remain critical and necessary to be a successful and wanted engineer for a long time in the industry.

Failure

And learning how to cope with failure. (If you’ve never failed, you haven’t really tried.) Personally, however, I believe that not all mistakes can be equally forgiven. Lessons learned should be interpreted emotionally-free, and then any risks to be taken should be well considered.

Traditionally, engineering means constructing, operating or predicting behaviour under certain working conditions using scientific principles to design or create any process, instrument or structure, and all that is done is intended for a specific function. For software engineers who are currently trying to shape their career, under the conditions available, all the things I mention are about choosing the most suitable solution. Engineers who want to remain valuable should analyse the existing constraints well and apply engineering to their own lives in order to maximise the objective function for their career.

When I applied the engineering principles to my own life based on what I have learned from past to present, I arrived at these conclusions which I have mentioned in this article. And I hope these conclusions will help those who really care about this issue, in their analysis.