Two stand-ups and three meetings before lunch — I could barely find the time to respond to my most urgent emails. After wolfing down my sandwich, I remembered an ongoing dispute on the software engineering Slack channel that was turning ugly. I resolved it, but only after forty-five minutes. When it was code review time, it was well into the afternoon, followed by a design session around a whiteboard. At 5 PM, my energy spent, I sat down to write code, knowing the work was coming home with me.
“Still at it?” a colleague chided at 7 PM. “What is it you do all day?”
Perhaps harsh, yes, but a good question. This is not a unique day nor is it the least productive I have had. My colleagues often complain of their lack of hours dedicated to writing code due to everything else that comes with the job.
So, what do software engineers do all day?
Hacker, coder, programmer, dev — there are many job titles assigned to the beloved trade of crafting software, and the most ceremonious of these titles is “software engineer.” To answer what a software engineer does, we must first talk about what software engineering is.
Software engineering is the process of designing, building, testing, and operating software to solve a problem. In his book Modern Software Engineering, David Farley defines the practice as "the application of an empirical, scientific approach to finding efficient, economical solutions to practical problems in software.” A software engineer finds the best way to create software by doing what works and discarding what doesn’t.
This article discusses what software engineers deal with in their day-to-day work. Many of their tasks do not involve writing functions or creating classes, but their ability to leverage effective solutions is an indispensable part of the responsibilities of a software engineer. However, at the core of their duties, software engineers write code to turn designs into workable products, adhering to best practices and standards.
Introduction to software engineering
From the smartphones we use to the websites we visit, software engineering plays a crucial role in shaping our digital experiences. Whether it’s the seamless functionality of a mobile app or the security of an online banking system, software engineering is at the heart of it all. This discipline ensures that the software we rely on daily is reliable, efficient, and user-friendly.
Software engineering is the backbone of the digital revolution, enabling the creation of software solutions that transform the way we live, work, and interact.
Brief history of software engineering
The field of software engineering has evolved significantly over the years. The term itself was first coined in 1968 during a NATO conference, marking the beginning of a new era in software development. Since then, the field has undergone tremendous growth and transformation.
Initially, software development was a chaotic and unstructured process, but over time, it has become a recognized discipline that combines computer science, mathematics, and engineering principles to develop software systems.
What do software engineers do?
As discussed earlier, a software engineer does many things in their day-to-day, including software engineering design, code review, testing, support, and more. Let’s look at these tasks in more detail.
Software engineering design
Writing code without first considering its shape and place in the system landscape leads to wasteful software that is inefficient, difficult to maintain, and costly to change. Worse, badly designed software is impenetrable to other engineers.
A software engineer must spend a significant portion of their time understanding the problem, the existing software, the dependencies, and the interacting components. To illustrate their design, software engineers produce design artifacts such as UML or C4 diagrams, often handing these over to junior engineers or developers to implement.
As a general rule, the more senior the engineer, the less code they write. Senior systems architects play a crucial role in this design process, collaborating closely with software engineers to shape the infrastructure and maintain IT standards.
Just as a chess player will only move a piece after first studying the entire board and considering every outcome several steps ahead, a software engineer must refrain from starting coding without designing. Experienced practitioners will review design patterns and integration methods and make decisions based on painstakingly collated tradeoffs.
This process may seem esoteric and wasteful to the casual or junior observer. But engineering doubles down on what works. Rarely has design time, informed by lessons learned by generations of engineers, failed to pay off exponentially in development and maintenance. The book Fundamentals of Software Architecture by Mark Richards and Neal Ford will boost any developer's journey to becoming a software engineer. Richards’ website and YouTube channels are a free public service.
Communicate
Meetings have a reputation for squandered, unproductive time. To the engineer, they are anathema, a theater in which extroverted middle managers may spew their corporate buzzwords and justify their needless presence. In some companies, this is true.
However, software systems are rarely so compact and simple that one engineer is enough for their production and maintenance. Even successful projects with a single creator often end with a team, even a community, of contributors. Solo projects do not scale, and teamwork is crucial. Engineering is a human process as much as it is technical.
For this reason, a software engineer must master clear communication with teammates. The larger the team, the more communication is needed. Meetings, stand-ups, and side-desk discussions are inevitable, but they don't need to be unproductive. Engineers will find a solution and ways to do more with less time.
Debugging Teams by Ben Collins-Sussman and Brian W. Fitzpatrick provides an excellent blueprint for strong communication practices in an engineering team.
Test
Most mature project or development teams will have a quality assurance (QA) function, but the QA phase is almost always late in the life cycle and leaves little opportunity to correct serious design issues. QA engineers tend to focus on the big picture, whether or not the software behaves as expected, often without insight into how it is working. User and Business Acceptance Testing (UAT and BAT) are even less concerned with the details.
Software developers and engineers are concerned with ensuring that their software not only works but also works well. Every class and function should do exactly what it was designed to do. There should be no side effects that could cause problems later in the software’s life.
Whether through informal testing or full test-driven development (TDD), software engineers must control the quality of their code down to each function, often writing as many, sometimes more, lines of unit tests than production code.
Testing one’s software may seem like grading one’s own work. But software engineers have the most profound understanding of their code and are best positioned to test it at its most fundamental level. Software engineers, in general, are professionals who take pride in their work and will not knowingly mask defects with junk tests.
TDD is a best practice across the industry. It puts the tests first, guiding software development by writing tests before the code. In this mode, the tests fail when first run, and the engineer writes just enough code to make it pass (like returning a hard-coded value). The engineer then refactors the code until they have a working, production-class deliverable. Test-Driven Development by Example by Kent Beck is an excellent place to start and a great example of TDD in action.
Code review
Code review (also called peer review) is the practice where software engineers examine each other's source code to ensure its quality, functionality, and compliance with best practices before it is integrated into the main codebase.
Code reviews are mandatory in some companies, especially in regulated industries like banks. Some teams take this further by building automated code review tools into their release processes. These tools use probabilistic models to detect vulnerabilities, inefficiencies, defects, and malicious statements in the code.
Code review, while yet another demand on the engineer's time, saves costly errors slipping through the net and offers more junior developers on-the-job coaching. Moreover, rather than being a critical or hostile process, it fosters a sense of shared ownership in a team.
Document
Even the tightest teams are not a hive mind, and what is obvious to some will be opaque to everyone else. Despite its importance, documentation in engineering teams has become less popular for many reasons. A key reason is the Agile methodology, which prioritizes working code over thorough documentation.
Documentation decays and can become outdated before the software it describes reaches production.
Many developers do not favor writing documents—clean, well-structured code is self-explanatory. While this is true for software components, the best-named classes, functions, and variables can rarely express the "bigger picture" of how the software fits into the ecosystem.
The self-documenting code argument rarely holds in teams where documentation is not a valued part of the culture. In many cases, engineers see self-documenting code as a shortcut or "get out of jail free" card. Engineers who do not take documentation seriously are less likely to document their work, be it in the code or anywhere else.
Documentation is an overhead, but should never rule out a documentation discipline. Just as engineers must maximize the time-value ratio of meetings, they must also be prudent with how much time they spend writing documentation. A strong software engineer will judge the appropriate level of documentation needed for a project rather than write an essay where a single diagram will do.
Docs for Developers: An Engineer's Field Guide to Technical Writing by Jared Bhatti, Zachary Sarah Corleissen, et al. is a go-to book and essential reading for any software engineer.
We recommend the C4 Model for creating clear and simple design diagrams.
Support
No amount of QA or code reviews will guarantee flawless software. Even in the strongest teams, something will break. Software engineers are the most qualified to support their own software, especially early in its life. Engineers are regularly called upon to investigate defects found in QA or in production. Often, the code is functioning correctly, but the engineer bears the burden of proof.
Projects often have a "warranty" or "hypercare" period, during which engineers must be available to support their software should it go wrong. A malfunction may only be discovered later in the feature's life — such as at the end of a month or during a period of excessive load. The original engineer may have left the company, and another engineer who is less familiar with the code will be required to support it.
Most software engineers will prefer to work on new things, but supporting what came before is essential in any business. This is the strongest argument for a strong documentation practice.
Estimate
Product managers or product owners must decide among competing priorities and cannot do so without informed estimates of the cost for each. Just as the engineer is the best qualified to support their software, they are also best placed to determine the cost of building new features.
Estimates can range from "T-shirt sizes" to numbers of days or dollars, and are almost always caveated with confidence ratings or percentage allowances. Teams that use Agile methodologies often provide estimates in "story points" — units of measurement not tied to time or currency but rather serve as comparators for prioritizing work, building consensus, and accounting for uncertainty.
A software engineer can expect the amount of time spent estimating to increase with their experience.
Planning releases
Releasing code into a production environment ranges from simple to choreography of tasks involving infrastructure, DevOps, and other teams. Even in continuous delivery (CD) environments, where the route to live is automated, software engineers are indispensable in managing releases in a safe, coordinated way.
Some releases update a single executable, while others demand database updates or even migrations. The software engineer has been pivotal in the development process, but the job is not done. They must organize the release and create back-out plans — more documentation. During the release, often during odd hours, they must advise and support the release team. In some companies, the software engineers are the release team.
Code with programming languages
By no means least, a software developer writes software. Depending on the team size and structure, engineers will spend part of their day churning out code. This usually involves configuring integrated development environments (IDEs) and setting up application environments (databases, messaging pipelines) on their local device.
Writing modern code and tests often involves managing build dependencies, development frameworks, and runtime environments. Development requires careful attention to non-functional concerns, such as logging and security. Many companies have coding standards and style guides. Engineers will spend time refactoring, optimizing, and debugging their code and that of others.
Engineers rarely have the luxury of writing new software “from scratch,” and they often must change existing source code, spending hours first becoming familiar with it. This is where the less glamorous tasks of documentation and communication become crucial.
Learn
Successful software engineers regularly upgrade their knowledge. New technologies, programming languages, platforms, and methodologies emerge seemingly daily. The industry is never at rest, and whether on company time or their own, the engineer must make learning and development a core part of their life to keep up. Continuous learning is essential for a successful software engineering career.
Colleges give software engineers the crucial skills they need to program but do not always teach best practices, design patterns, integration patterns, and methodologies. These must be learned by the software engineer on their own initiative.
Books like The Pragmatic Programmer by Andy Hunt and Dave Thomas and Clean Code by Robert Martin are must-reads for someone who wants to become a software engineer.
Types of careers in software engineering
Software engineers can be categorized into different types based on their areas of specialization, skills, and expertise. Some common types of software engineers include:
- Application developers design, develop, and test software for various industries, including gaming, finance, and healthcare. They focus on creating user-friendly applications that meet specific business needs.
- Systems developers focus on developing software systems, including operating systems, network control systems, and database management systems. They ensure that these systems are efficient, reliable, and scalable.
- Web developers specialize in developing web applications, including front-end and back-end development, using programming languages like HTML, CSS, and JavaScript. They create interactive and dynamic websites that provide a seamless user experience.
- Mobile app developers design and develop mobile applications for Android and iOS devices using programming languages like Java, Swift, and Kotlin. They focus on creating apps that are optimized for mobile devices and provide a smooth user experience.
- Cloud engineers specialize in developing cloud-based software systems, including cloud infrastructure, migration, and management. They ensure that cloud solutions are secure, scalable, and cost-effective.
- DevOps engineers focus on ensuring the smooth operation of software systems, including deployment, monitoring, and maintenance. They bridge the gap between development and operations, ensuring that software is delivered quickly and reliably.
These are just a few examples of the many types of software engineers. As the field of software engineering continues to evolve, new specializations and areas of expertise are emerging.
Popular programming languages
Programming languages are the building blocks of software engineering. Here's a brief overview of some of the most popular programming languages used in software development:
- Java: Known for its platform independence and object-oriented design, Java is widely used in enterprise applications and Android development.
- Python: A versatile language used for web development, data analysis, machine learning, and more, Python is praised for its readability and simplicity.
- C++: A high-performance language used for building operating systems, games, and other resource-intensive applications.
- JavaScript: A client-side language essential for web development, JavaScript enables the creation of interactive and dynamic websites.
If you want to explore more about what programming language you should learn, check out this article.
Conclusion
The software engineering field is challenging and rewarding. But the caricature of the lone coder rarely holds. A software engineering team is like an army with soldiers working in lock-step rather than heroes acting alone — just as the strongest builder cannot raise a skyscraper alone and a brilliant surgeon cannot carry out surgery without a competent team.
