Who is a Software Engineer. Software Engineering VS "Just" Programming

We bring to your attention an adaptation of an article by Samer Buna about the differences between software engineering and programming, or how developing a software concept differs from “just coding”. All software engineers can code, but not all programmers can develop software concepts. Some people don’t like the term “Software Engineer” (aka Software Engineer) because most often we use the word “engineer” when talking about something more physical - construction, for example. Our article, of course, is not about the term itself. If it suddenly causes you rejection, it can easily be replaced with something related to creativity. “Software Creator”, “Software Author”... or even “Software Creator”! The ability to program does not automatically make a person a software engineer. Anyone can learn to code, and it's much easier than it seems. Anyone can create a simple program for their own use, but this does not guarantee that the same program will work for others. My favorite example is this: many of us sing in the shower, but, alas, this performance is not always worthy of a professional stage. Of course, for a high-quality musical experience, you will most likely turn to a pro. Do you need more examples?

• We all learn math and writing in school, but that doesn't make us mathematicians and writers.
• Most of us are capable of preparing a passable and sometimes very tasty dish, but not everyone would dare to prepare a table for 100 people for an embassy dinner party. In this case, we hire a cook.
• Are you ready right now to completely entrust the construction of your new house to the neighbor's child who creates impressive masterpieces from Lego?

My main point that I am trying to convey in this article is that simple programs are very different from programs designed by engineers. The simplest definition of the programming process: drawing up an ordered sequence of actions for a computer in order to obtain something specific as an output, given given input parameters. The process of software engineering is the design, writing, testing, and curation of a computer program to solve problems for many users. It's about creating reliable and secure solutions that will stand the test of time and work for some possibly unknown challenges beyond the obvious. Software engineers know everything about the problems they solve, the solutions they propose, the limitations of those solutions, their privacy and security. In my opinion, if a person does not understand the essence of the problem, he should not even begin to program its solution.

Engineering mindset - search for applied solutions

Software engineers do not consider writing software per se their main goal. They think in terms of meeting needs and solving problems . This is important because not every problem requires a software solution. Some of them can be dealt with using existing programs. The occurrence of some problems can sometimes be predicted in advance, and with the help of competent program design, they can be avoided in the future. Complex problems often require writing a lot of programs. There are tasks that require parallel running applications, while others require sequential execution of several programs. A number of problems can be solved simply by training users. Before starting to create a program, a software engineer asks himself a number of questions:

• What problems should I solve?
• What else can you do besides writing code to solve them?
• What can I do to make these tasks easier with the app?

Program quality and code quality

Good programs are clear and readable. They're easy to extend, play well with other programs, and won't be a nightmare to work with. Code quality is not negotiable. It should be high, that's all. When considering it, excuses such as the coder’s bad mood or too tight deadlines (oh, those deadlines!) are unacceptable. One of the most important aspects of software development is designing the program in such a way that it is easy to maintain and modify in the future (hello, OOP!). Today, almost all software is modifiable, often this process occurs even without user participation or does not require anything from the user other than “your program has been updated, click OK or Postpone.” Of course, users have the right to demand new features from applications (especially if we are talking about long-running enterprise software that is written in Java, or online games that can be played for years). A piece of code by itself can hardly be called useful. The useful functionality of software begins where disparate pieces of applications communicate with each other, exchange data, and work together to perform the task of presenting data and interfaces to users. Programs should be designed with these points in mind! What messages do they receive? What events are monitored? How does authentication and authorization occur? Another equally important sign of a good program is the clarity of the code, not the number of tests the application has passed or even good test coverage. Seemingly simple questions: “Can someone other than me understand my code?”, “Will I be able to write this code today and understand it in a few weeks?” A popular quote about the two hardest things in programming says: Code readability is much more important than is commonly believed. Unfortunately, it is not possible to define precise metrics or parameters for code clarity. Memorizing generally accepted language norms, good software models, and development methods will help in part. But usually this is not enough. With time and experience, true professionals develop, so to speak, a “sense of clarity,” something akin to intuition. A writing metaphor works well here: knowing a lot of words will not help you write something that is concise and clear in meaning. The ability to fix bugs quickly and easily is a key feature of good software. Errors in the program should send clear messages and be centrally logged for tracking. When a new error is reported, the person who will fix it must have the ability to debug it. He needs to easily connect to the system, access execution information at any time, and also be able to easily check the functionality of any part of the system.

Environments and testing

When software engineers develop applications, they do their best to ensure that they work on computers of different architectures and with different operating systems. It is important that the software works at different resolutions and screen orientations, and also that it does not “eat up” more memory and processing power than required. When it comes to web applications, they must work in all major browsers. When creating a desktop application, you need to make sure that it launches and works correctly on Mac, Windows, and Linux. Well, the program depends on the data, then the application should work even in the case of a slow data connection or its absence. To write a piece of software, engineers think through all sorts of scenario options and plan to test them. It all starts with choosing the ideal option, in which everything works without errors. They then document any potential problems and write them into the test plan. Some engineers start by writing code, which they call a test case, which simulates scenarios for all the likely problems and errors. And then a program is written that can work with any of the options considered. The unique ability of a talented software engineer is not knowing how to write code, but understanding what exactly the application should do as an output and how to achieve it. When the customer's software requirements are incomplete and possibly ambiguous, the engineer needs to correctly evaluate and “understand” them.

Cost and efficiency

A software engineer can fix the problem quickly in most cases. If you think hiring an "expensive" experienced programmer will increase your costs, think again. The more experienced the hired programmer is, the faster he will be able to provide a simple, neat, reliable and easy-to-use solution. In the long run, this will definitely reduce software development costs. It is also necessary to consider the costs of executing the program. Any program uses computing resources, and they are not free. For example, caching frequently accessed data is one of the possible strategies used to achieve the desired result. But this is just one of probably hundreds of tools and solutions that can make a program faster and more efficient. A novice programmer may provide you with a cheap solution, but using such a solution will ultimately cost you and your clients much more than if you worked with an experienced developer who created an effective solution in the first place.

Focus on user experience

A good programmer develops with User Experience (UX) in mind. Human-machine interaction is a topic with endless research and solutions. The more solutions are applied, the better the program should turn out. Here are a few examples, just to give you a feel for what this direction is:

• When designing data entry forms such as e-mail, a good program should ignore the case of the e-mail address. It shouldn't throw an error if the CAPSLOCK key is pressed because the email address is unique in lowercase. If the program accepts a new email address as input, check it early in the input process to alert the user that they are using the wrong address format. This solution includes both obvious checks like the missing “@” sign, and also not so obvious ones, such as checking for the wrong order of characters like “gmail.ocm”

• When the user is redirected to perform some action, a good program should remember his current position and return him back after he is finished. A good program should also remember the data already transmitted by the user, which is important for further interaction with him.

  Let's say you're searching for air travel as a Guest on Expedia. Later you decide to create an account. The app should save all your previous searches in the new account and you should be able to access them from other devices.




• A good program is designed with user behavior scenarios in mind. You don’t just need to add new features on a “so-so” basis; put yourself in the user’s shoes. One day I was booking plane tickets and forgot to include my frequent flyer number. After receiving confirmation, I decided to go to the airline's website and add it to get the discount. To figure out how to do this, I fiddled around with the site for a good 10 minutes. The application was so unobvious that I simply wandered aimlessly through different pages of the site in order to find what I needed. Later, I discovered that I had already landed on the right page a couple of times, but I didn’t even understand it, since the field I needed was lost among other similar fields of a huge form.

  It turned out that in order to edit the trip information, I needed to scroll through about twenty lines of the form, enter the loyalty card number and phone number, without which the form could not be sent for verification. This is an example of a program that was developed without thinking about how comfortable the user would be with it.

Reliability, security and safety

In my opinion, the most important difference between a professional software developer and an amateur is taking into account parameters such as reliability, security and safety of the application when creating it. Parts of the program must be tolerant of incorrect input, incorrect states, and incorrect interactions. This is indeed very difficult to enforce and is the main reason why we hear stories of people dying due to software bugs. Users have entered, are entering and will continue to enter incorrect data into the program. This must be accepted as a fact. Moreover, some will do this on purpose, with the goal of breaking the application and getting to the resources available to it. Here's a real-life example: The person allegedly responsible for the recent Equifax data breach is accused of failing in his job responsibilities, which was to develop solutions to resist bad and malicious input in all software products made available to the public. Incidents related to information security involve not only incorrect and malicious input, but also incorrectly entered data. If a user has forgotten his password, how many times can he try to enter it? Will you block him after this? What if someone else tries to block his account? Can a user transmit their credentials over an unencrypted data channel? What if the login request came from an unusual location? What will you do if the login attempt appears to be automatic? What have you done to protect your users from cross-site scripting, cross-site request forgery and common phishing? Do you have a backup strategy in case of a DDoS attack on your servers? These questions highlight just some of the issues that need to be considered. The protected program does not save important information in text form. It protects it with a complex one-way cipher (one that is easy to encrypt but nearly impossible to decrypt without the key). These are backup measures in case the program is hacked. Hackers will discover encrypted data that is useless to them. Unexpected problems arise even in the best programs. A programmer who is not prepared for their occurrence can hardly be called a professional. Until he expects unexpected behavior, he is not an engineer. He is the “author of unsafe programs.” Errors in programs are not always obvious. Our intellectual ability to anticipate and prevent known errors is limited. This is why software engineers understand the importance of good tools to enable them to write correct and secure software.

Required Tools

There is no doubt that we need different and good development tools. Their role is often underestimated, but in fact they save a lot of time and effort, simplifying some tasks by an order of magnitude. Imagine if you still had to upload files via FTP for deployment, so to speak, the old fashioned way. Imagine debugging network and performance issues without Chrome DevTools! And how inefficient it would be to write JavaScript code without ESlit and Prettier these days! Any tool that reduces feedback time as you write code should be welcomed. When I find a tool that was previously unfamiliar to me, but is truly useful and effective, I can only regret that I did not use it before that happy moment.

The evolution of software engineering

No one can learn software engineering in two months, six months, or even a year. You won't be taught how to be a software engineer in a course, university, or boot camp. I have been studying for the last twenty plus years and continue to study now. I was able to comfortably call myself an experienced programmer only after a decade of learning and developing, creating and maintaining applications used by thousands of users. Software engineering is not for everyone, but everyone should learn to solve their problems using a computer. If you can learn to write simple programs, you should. If you can learn to use publicly available software, you should. If you can learn to use open source software and customize it for yourself, you have a superpower! Every day brings developers new challenges, new problems, which is why software engineering is needed. The main task of this profession is to create software so that an ordinary person does not have to deal with it for many years. So that there is no need for long studies to interact with programs. And yet, software engineers are constantly thinking about creating better tools that can solve more complex known problems, and doing everything possible to ensure that new problems appear as rarely as possible.