What is a Sustainable Developer?

I was recently asked to describe what I felt were the traits that exemplified modern, professional software engineers. I wrote pages of notes trying to describe how I felt and why, but the most effective way I found to describe what a Sustainable Developer does is to point out the differences from the traditional (i.e. bad) way of developing code.

Traditional development practices

  • new features are done as quickly as possible
  • changes are done as quickly as possible
  • each developer works in a single part of the code
  • developers rarely talk with each other except to decide on an API
  • bugs are an inherent part of having custom software
  • servers and software will randomly break and we work all night to get it back up
  • the tech team’s work is too volatile to do meaningful long-term planning
  • bigger changes mean bigger risks
  • eventually the code is rewritten because the existing codebase is unmanageable

Sustainable development practices

  • Developers are a team and everyone is responsible for every part of the code
  • Developers follow the Boy Scout Method: if you touch code, you must leave it better than when you found it, never worse
  • Developers use emergent design and the SOLID principles to guide how code is written
  • The developers will work closely with the customer to deliver exactly the feature required
  • New features and changes are done in order of business priority
  • Happy developers leads to good decisions – deadline pressures are detrimental to solving a problem effectively
  • Code quality is never something that can be compromised; only features, time or resources are the dials to change
  • Developers don’t write bugs in the first place so they never have to debug later
  • Software is trustworthy; changes are never scary because the code is well encapsulated, easy to read and never “clever”
  • Code will have automated unit tests over it to alert other programmers when they might be introducting an unexpected side effect
  • servers are stable and trustworthy; instability and failures are rarities
  • Development teams are never larger than 5-10 people; developers cannot communicate effectively to a large group
  • Pair-programming is a must when training new developers in the codebase or when sharing knowledge between senior and junior developers
  • Team health and current status are always clearly communicated – less “unexpected” surprises and planning is a meaningful activity


So really, this boils down to about 6 major viewpoints that differentiate a sustainable developer from a traditional one.

Stability and quality are the primary focus of Sustainable developers

Having bugs in the code is comparable to having cracks in a housing foundation; each one is dangerous and expensive to fix. Nothing unexpected should ever happen when using or changing the software.

Sustainable Developers maintain codebases for the long-term

We don’t work in churn-and-burn projects; we live in this codebase now, we better prevent an infestation of bugs. The code needs to be easy to read, easy to maintain and even easier to debug. Code that does something wrong should be very easy to spot because the code is simple, clear and concise.

Communication between the developers and the customer drives all code work

We only build what is requested, and we build exactly what is requested. Requirements gathering is a difficult part of the job, but prevents us from wasting time on incorrect or useless features.

Communication within the development team

We all have strengths and weaknesses, learning and cooperation is best for the team. Daily standups so the team is aware what others are working on, weekly or monthly retrospectives to analyze longer-term issues or to air grievances within the team are all important for keeping the developers happy and the code running smoothly.

Education and experimentation

Well-informed developers make well-informed decisions; lectures, classes, building prototypes, and research are all crucial parts of a developer’s day-to-day.

Time pressures are kept away from developers whenever possible

Effective planning is critical to keep developers from the “death march” typically associated with traditional development. Late nights and sleep deprivation only lead to bad coding decisions and bugs in the future. If a developer is informed that a feature must be out by a certain date, the temptation to cut corners to try and hit that date is large, but the long-term cost is much larger.


Published by EyeOfMidas

Game Programmer, Web Developer, Linux Server Admin

Join the Conversation

1 Comment

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: