How software engineers spend their time
The curious minds of engineers
Sci-fi and action movies are infamously known to cast tech geeks sitting in a dark room, striking their keyboards and staring intently at their dark screens. While it is mostly true that programmers like to be in the dark, the speed at which they strike their keys is largely fictitious.
It’s important to think of programmers and engineers as problem solvers though they may not always share the same problems with their business counterparts. When presented with a problem, it activates a cascade of biochemical reactions in their brains that makes it difficult for them to leave the problem unsolved. When not presented with any problems, engineers tend to ‘create’ their own problems and attempt to solve them. We are a peculiar breed of people who are highly driven to satisfy our own inquisitiveness.
When you are constantly thinking of ways to improve even the most mundane tasks, you’d realise there are more challenges to solve than what are apparent. Peeking through the insatiable mind of an engineer, you would find that the world around us is teeming with ‘problems’ that beg to be solved. Our fulfillment comes from solving problems. The more problems we solve, the happier we are.
We’ve heard of the Kubler-Ross Grief Cycle. The emotion curve of a software engineer is no less different as they venture into the unknowns of building a product or feature. We can break this down into 6 stages, each highlighting the ups and downs in the life of a programmer.
The planning stage
Typically, when any project kickstarts, the people who are involved tend to spend a fair amount of time planning for it. Take a real estate project for instance, the developer would spend some time examining pressing questions such as how much is the project going to cost? What sort of profit margin are we looking at? How many workers do we require? What materials should we source for? How long would it take before we can sell our first unit? The planning stage is not limited to new projects but can happen quite frequently as programmers start changing things in an ongoing project. We’ll talk more about this in the following section.
As you watch your favourite cooking shows, you’ll notice they all begin by introducing the assortment of ingredients they plan to cook, followed by a brief explanation of what they plan to do and only then the actual cooking starts. The world of software engineering is no different. Such ingredients are commonly known as artifacts, and it is essential to lay them out first. You wouldn’t want to have a sizzling hot frying pan alongside a defrosted steak only to realise you have no tomatoes or mushrooms to go with it! Such scenario is frustrating to the cook or worse, it can derail the entire plan when the necessary ingredients are not readily available.
Now imagine you have to develop an app. Sure, there is a lot of coding to be done, but let’s take a step back. You have to make a few decisions at first, such as technology selection which involves choosing from the hundreds of languages and frameworks you’re going to use for the upcoming project.
Next, you would need a database to store whatever data you’re planning to collect or process. You may end up choosing a framework to speed things up and develop your own logic that collects this data, processes it and then stores it in the database. Depending on how you choose to develop your app, you may end up using the client-server approach where part of your code resides in your users’ smartphones and the rest resides in a server somewhere that’s connected to the internet.
Once you’ve figured out the tools you want to utilise and the approach you’d like to take, it is now time to plan further. You would need to draw up certain architectural diagrams and get a senior engineer to validate certain hypotheses in your proof-of-concept.
The excitement stage
Software engineers are somewhat ‘lazy’ in a good way, as they tend to hate repetitive tasks. When a programmer realises that he or she is going have to do something more than twice, they’re likely to think of ways to automate that process in order to escape the feeling of repetition. That in itself is not at all a bad thing but it’s definitely worth mentioning as it may end up causing more problems that no one asked for.
Excitement among software engineers generally happens when they hear the word 'new project' as it presents a fresh set of problems to solve and opens doors for engineers to escape from their current projects, which by now bores them to death. In other words, it allows them to move away from repeating the same tasks everyday and start something new. Remember, programmers hate repetition.
Due to the hate of repetitive work, engineers will likely explore a different approach for the new project - perhaps something they’ve always wanted to get their hands on but is not permitted by their current project. Experimenting with new approaches allows them to expand their knowledge and make themselves desirable in the job market. Hence, at times, engineers tend to deliberately choose to adopt new methods and frameworks that they may not be familiar with.
The coding stage
The way computer software is written is highly structured, and programmers thrive on having things in order and under control. Multiple files of colourful text are classified and grouped together depending on their nature, each of these contains a specific set of instructions that tells the computer how to behave once a certain set of criteria is met.
For instance, one file does nothing but changes the font colour to red, another might contain the error message that is shown to users if they enter a wrong password, while another file may contain a logic that reads the time of day and provides a nice greeting message when a user logs in.
Sounds pretty straightforward right? And it is! Writing the actual instructions for a computer to do something is pretty much the easiest part of coding and should be the least of your worries. On the other hand, arranging the same files that contain millions of lines of codes collectively and telling the computer which instructions to execute first and when, is the hardest part of the job! This is due to the fact that computers don’t have common sense like humans do to figure out which set of actions should come first.
All the components I mentioned in the planning stage (database, framework, programming language, mobile app) are designed to be standalone tools. Yet, they serve as additional tools and libraries of codes that allow you to connect one component to another such as the database of your choice and your selected framework. Such things can be called a 'driver' sometimes, which falls under the big umbrella of developer tools.
The concept of drivers may ring a bell to some early adopters of technology. Plug-and-play is a common concept that we’d expect from any product nowadays, but it wasn’t always the case! Peripheral devices back in the 90s were packaged with a CD that contains the product’s driver, and as you install your new fancy graphic card, your computer may generate an 'unrecognized device' message until you install its driver.
Consumer products have come a long way since the 90s as modern consumers expect any product in the market to just work when plugged in. Developer tools, however, are designed with the assumption of whoever ends up using them will have the necessary technical skills to install the driver and figure out how it works.
Programmers spend a huge chunk of their time figuring out how certain things work. We all know that understanding the question is half the answer. Similarly, understanding how something works is the ultimate answer a programmer is looking for. The other half of a programmer’s time is spent on coming up with creative ways to attach these things together, or in other words, integrate different components together to make up a system that does what they want it to do.
The panic stage
Senior engineers and technical leads usually know not to attempt to learn on the job as it can lead to unexpected disasters down the road. This generally comes from decades of experience and having seen too many failures in production. Yet, many still choose to learn new things in new projects. Did I mention we are hard-headed too?
There’s nothing wrong in learning something new on the job for as long as time permits, and risks to business are well-contained. The issue lies in the size of the tool a programmer is trying to learn. Reading a user manual that is 3-5 pages long for a code library seems fine, however, trying to use an entirely new programming language without an understanding of how it really works will only result in catastrophic failures.
You can imagine how much time has already been wasted just trying to figure out how all these components work and how to integrate them together. By now, the programmer has probably only a couple of weeks left before the project is set to launch. All that is accomplished to date are a few proof of concepts and diagrams that require a few months’ work to develop.
The panic mode is somewhat guaranteed to occur in every large project as people tend to underestimate the size of it from the get go, and that’s mostly due to lack of experience or improper mapping of requirements. Within such tight timelines, engineers tend to revert to the approach and methods they’re most familiar with, abandoning their lofty ideas (and wasted hours) of pursuing something new. It is at this point where they have to go back to the drawing board. A period of crunch time and sleepless nights is generally expected.
Rest assured, the project is going to be delivered on time, or at least, a working version of it will. What this means is engineers are likely to take certain surgical shortcuts, which allow things to work, but is certainly not best practice.
Over time, these short cuts accumulate to become what is known as tech debt. Never underestimate the gravity of each tech debt as this can pile up faster than one can resolve. The inability to catch up on rectifying tech debts is the downfall of many tech startups.
The 'brain-gasm' stage
Frankly, this wasn’t apparent to me at first until my partner highlighted it. After some digging, this actually turns out to be true. There is a certain euphoria that programmers experience when they watch their code running or being compiled and merged.
There is also a certain phobia or superstition that if they are not glued to their screens while their code is running, something bad is going to happen. Hence, they would rather sit idly in the same spot for a few hours, paying attention to what their computers say about their code. It is as if their mere presence will increase the odds of success.
In reality, this is partly true. Things can truly break at any point for many different reasons, and being there when it happens to fix the error can save hundreds of hours deciphering what may have gone wrong. Sometimes, they’ve just missed a dot somewhere.
The whining stage
So they’ve chosen their tools, juiced their brains to come up with conceptual diagrams and written dozens of files with hundreds of lines of codes. Next, developers tend to spend quite a good deal of time doing nothing but staring at their screens and reading their code (or other’s) to try to understand and imagine how the code will behave once it gets uploaded into the computer’s brain or CPU.
The larger the software code base, the harder it is to modify it. Thus, programmers resort to spending more time thinking of ways to make surgical changes to avoid breaking something that’s most likely written by another programmer. This is an example of how the planning stage can occur frequently.
The whining stage often occurs as a result of unresolved tech debt, the larger the debt, the more inconvenient it becomes for engineers as they are forced to become more operational than innovative.
A well-designed system is supposed to include the necessary interface to configure and control its behaviour. Think of Microsoft Windows and all its versions. They all come with their own settings panel that allows users to tweak things to their liking. It is very unlikely for users to require support from Microsoft’s engineers given its product maturity.
Startups and other businesses, however, do not have the luxury of time to create such settings panel. The lack of such self-service capability results in operational bottlenecks at the engineering level.
Programmers in this position tend to receive tonnes of instructions to aggregate and export reports that support the business, as well as making a whole lot of superficial changes. Operations like these are critical to keep the business going but has no value from an engineering or innovation point of view. Whether a button is red or blue in colour, it does not affect the way it works.
It’s essential for managers at this point to keep an eye on the team’s energy and listen to their feedback. Failing to address engineers' concerns would only result in them wanting to seek excitement somewhere else.
The whining stage is often the result of a business that under-appreciates the technological aspect and instead, focuses more intensely on the monetary aspect of the business. It is a phase of unnerving frustration to engineers who require the environment to innovate and build, leading back to the excitement stage when a new project comes around, as discussed earlier.
Final thoughts
I hope this article has provided you an idea of what may be going through the minds of engineers. The intention of this article is to highlight the gaps where engineers can provide their valuable inputs and change the course of a project you’re embarking on for the better.
The engineering thought process is skewed towards technical problem solving which may not directly portray relevance to the business. Involving your engineers in making business decisions can bring about tremendous value. Even in the planning stages, they have the ability to provide feasibility analysis before the company decides to invest in a risky project.
Software engineers tend to go wild with their creativity and solutions. Exploring different and new ways of solving a problem keep them motivated and focused. This is good as it allows them to be more efficient over time. Instead of suppressing their creativity, which often involves a great deal of research and experimentation, come up with creative ways and time-boxing to manage their interests perhaps by introducing side projects on top of pre-defined tasks.
Finally, remember that software engineers are problem solvers who hate repetition, so make sure you never run out of brain teasers and puzzles for them to solve. Do gauge their interest levels toward a particular business challenges every now and then, and shuffle things around to keep them motivated, interested, loyal and wanting to keep coding.
