What Does a Developer Do?
This is such a basic, fundamental question, the gatekeepers of the programming industry have already written off this article as a waste of time. I, however, believe that this is an idea worth exploring. This is just an exploratory piece from one individual’s point-of-view to help us better understand what a developer does in their day-to-day. This is not exhaustive and will not qualify for an appearance on Hypercritical, but I hope it is helpful none-the-less.
High Level Definition
In order for the reader gaining a proper understanding, I will give a very simple definition of what a developer does. A developer takes project requirements or specifications and translates them into code. And while this explanation leaves out a great deal, it communicates the essential elements the reader needs to gain a basic understanding of the role of software developers.
Greenfield VS Brownfield
Developers solve many challenging problems and the daily responsibilities of a developer will vary largely based on their role, the organization, and their experience level. Developers will generally work within two categories of software development in their career. The industry term for these are Greenfield and Brownfield Software Development.
Greenfield Development
If you are lucky enough to start working on a fresh project, one which has never seen the light of day, one which has few limitations, count yourself lucky. Such a project is a bit of a rarity and is often referred to as a Greenfield project.
In his article Software Development: Greeenfield vs. Brownfield Donn Felker describes it well,
“Greenfield Development happens when you start a brand new project, as in, clean slate development. No legacy code lying around, no old development to maintain. You’re starting afresh, from scratch, from a blank slate, with no restrictions on what you’re doing (other than business rules of course).”
Brownfield Development
In most cases, you are likely to inherit the vision or code base for the project you are building. If you are new, you might have been brought on to implement new features or convert legacy code to the new code base. Whatever you build needs to work alongside code which can be much older or even could be built using a different programming language.
A post on Stack Overflow created by users Bombe and edited by Bill the Lizard describes Brownfield development this way,
“Brownfield development is a term commonly used in the IT industry to describe problem spaces needing the development and deployment of new software systems in the immediate presence of existing (legacy) software applications/systems. This implies that any new software architecture must take into account and coexist with live software already in situ.”
Process and Perspective
Whatever your role, there is a good chance that you will encounter a bit of both types of development work. Many positions involve a combination of greenfield and brownfield development. It is highly likely that you will not be doing 100% of one or the other. So being aware of the types and their pros vs cons is an important part of understanding what it means to be a developer.
Understanding the categories of development work does a lot to frame the work that developers do. Essentially, developers will be working on something which already exists or they will be creating something from scratch. When working on an existing project, sometimes a developer will be updating an existing feature or possibly adding a new feature to an existing product. Many times, but not always this feature will be communicated via documents which are called mock-ups or wireframes.
Sometimes these wireframes are created by a user experience(UX) designer or user interface(UI) designer and sometimes the developers will be responsible for working through the wireframing process before turning them into code. Regardless of who, the team will take the project specification and create a mockup of how that plays out in reality. Once the process is solidified, the developer will begin creating the code behind the feature.
Sometimes these wireframes are highly detailed or high-fidelity wirframes and sometims they are more of a guidline to go by. Often times if a designer has created the intial wireframes the designer will hand off any accompanying artwork to the developer. The developer will then use the artwork to flesh out the wireframes into a working application.
By understanding the two types of development along with a general idea of the typical process of development, it helps to gain a better understanding of the role of a software developer. While admittedly these explanations were a bit over-simplified, I believe they served to inform the reader regardless of their background. I hope to add more layers to this conversation, but I hope this serves as a great starting point for many seeking to understand what a developer does.
