What Does a Software Developer Do?
Before I began my career as a software developer, I believed in the stereotypes. I assumed the Hollywood-crafted archetype of software developer was real. I imagined a team of software engineers looked like a herd of people, mostly white men, hunched over their computers clacking away at keyboards as they stared at multi-colored text on dark screens spanning three monitors apiece. Each workstation resembled a playground of idolized figurines—superheroes, villains, video game stars, replica weaponry, an assemblage of geekery. And I idolized their abilities.
I ooh’d and ahh’d at the hackers, the codesmiths, the wizards of wetware, the people with insight into the most pivotal technology humankind has ever produced: the computer. They were capable of moving digital mountains, and I wanted in. To an outsider like me, their level of understanding appeared unobtainable by mere mortals, only granted by the gods themselves, or perhaps Mark Zuckerberg. But this image was a fantasy that limited my understanding of what a software developer truly is: any person who builds digital products. For an example that tore down my false image, I turned the clock back to 1840, to the time of the first software developer, to the time of Ada Lovelace.
The First Software Developer
Ada Lovelace was a mathematician, a brilliant one. At only 20 years of age she corresponded with Cambridge professor and inventor, Charles Babbage. Among other things, Babbage is famous for inventing the Analytical Engine (the world’s first general-purpose computer). Due to financial constraints, the computer was never built; however, that failed to prevent Lovelace from programming the unrealized creation.
Lovelace wrote a sequence of instructions for the Analytical Engine that would task the machine with outputting a Bernoulli sequence—this was the world’s first computer program, the world’s first piece of software. Whereas Babbage believed his engine was merely a tool to solve mathematical expressions, Lovelace saw what modern humans understand implicitly: numbers in a computer can be a letter in a book, a photo on a screen, or music on a speaker. She understood that a machine that manipulates numbers can manipulate anything numbers represent. In modern computing, binary 0s and 1s translate to web pages, audio files, flight controls, and yes, even mathematical results.
Before the first computer was ever built, Lovelace knew that computers would enable humanity to perform remarkable tasks—one hundred years ahead of schedule (how’s that for on-time delivery?).
What Does a Software Developer Do Now?
To program the Analytical Engine, Ada had to design punch cards that fed instructions to the machine. Today’s software engineers have it a little easier. The majority of software developers work at a high level of abstraction to separate them from the literal instructions that manipulate the computer’s stored numerical data. In the case of applications that run in the browser, the abstraction begins with the JavaScript programming language, leads to a browser that interprets and executes the language, followed by an application layer that supports the browser, and ends with a kernel that executes instructions directly on computer hardware.
At each point in this abstraction, software developers once had to work directly with that layer to build applications. The earliest transistor-based computers were fed a series of hand-written 0s and 1s to complete a task. To build that task-completing program, a developer had to understand the machine’s specific architecture and be aware of its limitations before producing a single instruction. In modern development, specialized programs known as compilers and interpreters do the heavy lifting. These tools convert human-readable programming languages (code) into instructions that a machine can execute. Instead of programming the machine directly, software developers produce code that ultimately performs some task for the person who owns the computer on which the code executes.
But regardless of how the developer completes her work, her goal has always been and will always be to deliver a digital solution. The exact tools, processes, and platforms that support the solution are underlying details that have changed over the course of computing history. A hundred years ago, real-world limitations forced Lovelace to program her Bernoulli sequence by hand for a machine that didn’t exist. Today, a software developer can build that same program in minutes and deploy it to billions of real devices. The latter approach is far more successful, but both developers achieved the same goal: create a solution using discrete, digital tools.
That’s an abstract understanding of what a developer does, so let’s look at what they literally do daily.
Day-to-Day
Depending on the specialty, a software developer narrows focus to one of several elements of software: user-facing, back-end, security, operations, shared tools, networking, quality-assurance, or something I’ve missed. In established organizations, developers generally remain within their lanes; interface developers master the front-end, operations developers continue to improve automation and delivery, and so on and so forth. But in scrappy startups where developers are few in number, the organization demands broad skill sets and Swiss-army-knife-like versatility. But regardless of where they work, each developer generally has one of four tasks to accomplish any given day: fix, review, maintain, or build.
Fix
Fix refers to debugging or otherwise correcting errors in software. Users and internal stakeholders submit bugs to an issue tracking tool. A tech lead (senior developer) assigns these issues to one or more software developers. This work requires the developer to reproduce the error in a sandbox environment (a testing environment that is isolated from production) and trace its origin. Once the error is found, the developer proposes a solution (bug fix) and submits the fix to their team for review. Speaking of reviews, let’s discuss the next task nearly all developers do.
Review
In ruthlessly organized teams, developers submit code for review before modifying the product. Reviewing code often demands a critique of its efficiency, formatting, correctness, and adherence to team standards. Reviewing code is a not-fun-but-necessary element among successful software teams, much like maintenance.
Maintain
To maintain software is to make modifications to source code that improve the software’s performance or reestablish broken dependencies. Few codebases exist in bubbles; they often communicate with external libraries, databases, or APIs. In other words, they have dependencies. When these need upgrading, developers who rely on them are asked to do complimentary upgrades. But I’ve left the best kind of upgrades for last.
Build
Software developers generally agree that building is the fun and invigorating aspect of software development. To build is to create new elements, features, or entirely new products. This part excites developers; they live to bring something new into the world from their own hands.
But what does it take to do these tasks every single day?
Required Skills
Programmers have come a long way from feeding a series of machine instructions to a computer by hand and so have their tools. But the skill set demanded of software developers has remained relatively consistent. Here’s a brief but competent list of required skills.
Reading and Writing Documentation
As noted earlier, few software products live in silos. Developers who integrate third-party libraries into their software must understand how those dependencies work before they can make use of them. And mastering dependencies often requires reading documentation—often more documentation than the developer would like to read. Virtually every tool available to developers comes packed with it. Unfortunately, not all is well-written, maintained, or easily navigated. The developer who can decipher documentation has an unfair advantage over one who cannot. But there’s another half to this skill: writing.
There’s a lot of documentation out there; someone wrote it. In well-organized teams, the developers write the documentation. The primary purpose of this text is to educate both new and existing teammates. Codebases often grow too large for a single developer to navigate readily. The documentation in the code helps employee inductees and seasoned team members understand how the code is organized, which parts are responsible for which tasks, how to establish a test environment, and more. Speaking of writing...
Written Communication Skills
A lot of the work developers do is digital; it makes sense that they prefer to communicate that way too. Emails, comments, and chat messages deliver requests to developers daily. Therefore communicating effectively through these channels is critical to a developer’s success. Miscommunication can lead to delays, errors, hurt feelings, and wasted effort.
Linear and Non-Linear Problem Solving
A developer is nothing if not a problem solver. And problems in code often require both linear and non-linear thinking. By thinking linearly, as all developers are required to do, they understand the logical flow of a program. Machines perform one instruction at a time, and a series of instructions compound to a task. Code mimics this behavior by working similarly: each line precedes the one below it, each statement precedes the one to its right. Without strong linear thinking capabilities, developers will struggle to write code, let alone understand it.
However, developers must also activate their non-linear thinking patterns. As in most trades, the completed work can be done in different ways. And while a standard linear way is sometimes easiest to code, it may result in inefficient or clunky software. For example, should a personal social media feed check news sources for updates every second while the page is open or should the updates ping the user’s screen when available? The first approach is costly but relatively simple to implement, whereas the second requires a little more legwork but ultimately reduces the number of network requests and CPU cycles dramatically.
Ability to Learn
Finally, all developers are required to learn. Teams frequently introduce new tools, processes, and even programming languages into their products. Managers and tech leads expect their staff of engineers to keep up to date with the changes and even promote new and improved ways of delivering products that save time, money, or both. More importantly, the career path of nearly all software developers is liable to take a turn or two as platforms evolve and technologies emerge.
For example, have you ever heard of a Commodore 64? If not, that’s likely because it was a device that dominated the home computer market…during the 1980s. Then, it disappeared. But during its heyday, developers built and published over 10,000 pieces of software for the Commodore 64. It is safe to assume that some of those developers are still writing code today, but for markedly different machines. Those developers had to learn how to work with new machines using new languages.
A similar transition occurs today: the one of PC to mobile. The Android operating system, an OS that quietly launched in 2006, now powers approximately 2 billion devices worldwide. That’s a big shift in technology that will require many developers to adjust their career path, a path that must edge toward “the new” to survive.
Career Path
Beginning developers advance as their contributions grow broader and their thinking grows bigger. After plenty of time spent fixing bugs, reviewing code, and building features, organizations provide quality software developers and engineers the opportunity to advise on architecture and long-term product trajectory. At this stage, developers can transition into a role as senior developer, architect, or similar title. These senior positions remain product-focused but as previously stated, require the developer to think about and evolve the tools, technologies, and processes that underlie the product.
Alternatively, some developers choose a managerial route: the tech lead, IT manager, or similar position. This role may involve some coding but focuses primarily on the people working under them and delivering projects on time. Regardless of which path a developer chooses, they all can expect one thing: change.
The Cutting Edge
Software lives on the cutting edge of technological innovation, and developers are expected to keep up with changing trends and techniques. Rather than remain fixed to a language, IDE, or text-editor, developers who want a long and successful career must align themselves with the idea of delivering high-quality products, not the process that delivers them. Some developers focus on the tools and get giddy about the languages they get to work with every day, but a fixation on process is short-sighted.
Marc Andreessen coined the phrase, “Software is eating the world,” and the last bit of the world software intends to eat is software itself. Emerging technology will dramatically change the way developers work in the next 50 years. The next generation of engineers will build products using automated workflows, natural language compilation, and artificial intelligence. If that excites you, then a long-lasting career in software development might just be the one.
