Everyone hates to waste time and effort. 

For developers, spending time on things that may not matter at the end of a sprint gets in the way of time spent problem-solving and writing code. If an organisation wants to improve developer experience (DX) and get the most out of the efforts put in, then we have to know where to focus.

Perhaps even more pertinent, with ongoing talent shortages and shaky economies in ANZ, getting the best out of precious developer resources is paramount.

For many developers, anything that is not directly related to their end goal of putting together software can be perceived as negatively affecting DX. This can include meetings and reviews that aren’t focused on code. However, listening to a strong brief once in a while regarding business goals can be an efficient way to inform a developer’s actions and decisions around how they code and the tools or platforms they use. 

That meeting might save a developer hours of wasted work due to a lack of communication or misunderstandings.

Just as developers hate wasting time in meetings, they should avoid wasting time on unnecessary code, too. A developer may have assumptions about what the software infrastructure needs in order to function, but are those functions correct in practice? Are there dependencies that need to be looked at, or are there elements that aren’t required? To improve DX in the area of software variables, we have to look at what exactly the real challenges are and where time and effort waste can be avoided.

Look at runtime operations
So, how do you know what is actually needed in your software deployments and where you need to focus your efforts? 

One approach is to look at what is actually used rather than what you assume you may use. We may rely on standard, third-party, pre-packaged container images that host all the components that another organisation’s developers believe need to be included – and we continue to use those images any time we need to spin up a new container. 

But think about it: do each of your containers need all of that code every time you call it?

Looking at runtime environments, a developer can see what is actually happening in applications, including what is being called and what is not. Over time, this will show if there are components in the software images that don’t ever get used. These unused components add unnecessary security risk and maintenance requirements for developers. Rather than using base container images that are bloated, developers should prioritise time to reduce container image sizes across their libraries and repositories as much as possible to reduce maintenance requirements and security risks.

This improves DX by making it easier for developers to keep their focus on what truly matters: writing and improving software code. 

Demote container bloat 
Reducing container bloat also makes containers perform better. When you are dealing with hundreds or thousands of containers as part of a microservices application, every size reduction leads to a cost saving on cloud resources consumed over time, and that can add up to be quite substantial.

DX is about making life easier for developers so they can build software and create code. By looking first at what is running, developers can keep their emphasis on what is really valuable and avoid the headache of maintaining bloated containers.

Making life easier for developers also has the added bonus of increasing their job satisfaction. With the Australian Federal Government’s Skills Priority List still classifying developers as an area of ‘strong demand’, every little bit helps to increase job satisfaction – and retain the crucial talent needed to take a company forward.