Skip to content

Instantly share code, notes, and snippets.

@Nordes

Nordes/notes.md

Last active October 18, 2022 02:39
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Nordes/18dfe46f9f99c5e690e7210b58464afd to your computer and use it in GitHub Desktop.
Save Nordes/18dfe46f9f99c5e690e7210b58464afd to your computer and use it in GitHub Desktop.
Download ZIP
DevX Notes and references
Raw
notes.md

!WIP!

DevX - DEVeloper eXperience

Basically this bring us to the developer experience or in other words, how to make a perfect environment for the developer so that he can focus on his main job (Thinking + Coding). Think of it as the "iPhone" UX that ever existed which kind of broke the pre-existing "known" design for phone.

I first heard about it at work and then started to look for what it can be. I was already doing most of it as part of my DevOps experience in many different companies. In fact, my role often consisted of removing the clutter and the repetitive job from myself and my team. If you see an opportunity to automate or simplify your life, my phylosophie is to simply "Just do it!".

DevX, you can also put it in some way with DevOps. Since the DevOps will do Development and Operations, the DevX combine that and push it a bit further in order to create a better environment where people will wish to join your teams and your company.

When there's an error, I can see what caused it quickly.

I can find out where each piece of data came from.

When it's time to make a decision, all the information I need is right there.

As the system changes in ways that I care about, I learn what happened, without a lot of irrelevant news.

When there's something important to remember, a computer remembers it for me.

To change the system, I can express my intention concisely, and a computer implements it thoroughly.

Ref.: Jessica Kerr at QCon London on "Why DevOps is a Special Case of DevEx"

Why It matter

  1. Improve Your Overall DevOps Performance and Demonstrate Business Value
  2. Boost Productivity to Stand Out in a Competitive Market

If the developer experience creates too many negative emotions such as frustration, helplessness, uncertainty and uselessness, the developer leaves work feeling unsatisfied and disengaged. This leads to burnout and stress.

...

Organisations that invest in developer productivity perform better in their respective markets compared to their peers.

...

Understanding the interaction between teams is crucial for a good developer experience. Building your own internal shared responsibility model helps. An example of a shared responsibility model we’ve used is below (see link) Ref.: Developer Experience: How to Create an Awesome DevEx in the Enterprise

What does it means "DevX Tools"?

By tools, we mean that all the necessary tools can be used in order to automate our work. Start small, go big. Not all can be done at the same time and you will have to fight some battle (Ex.: Purchasing license, etc.). If the tool does not exists, put some efforts to build it. Maybe it can be a temporary solution, but in some cases, it can fill a gap that will benefit to all your automation.

Having DevX practice will be attractive for people who wish to join your organization.

Creating better DevX will not only influence your ability to attract new people but enhance your ability to hold on to, empower and upskill the teams you already have.

Ref.: Bridging the Developer Experience (DevX) Gap

In some words, the DevX Tools are the tools that the developer teams feel comfortable with.

What does it includes

Based on different articles, I am trying to pull all together the "thing".

  • Create Fast Feedback loops
  • Try to create a culture
    • "Each interaction has a feedback loop. Quick feedback loops create a highly effective environment for developers. Slow feedback loops reduce developer effectiveness. Manual interactions are slower. For example, raising a ticket to ask another human to do something that could have been automated." (Ref.: Developer Experience: How to Create an Awesome DevEx in the Enterprise)
  • Try to build a proper journey for the application (flow to delivery)
  • Try to use the mind of people as much as possible (Full potential, not monkey typing)
  • Try to speed up delivery of software to support business operations
  • Try to improve the overall customer experience in short cycle

Challenge: It is not because an organization implement DevOps practices that they can scale easily. (See The State of DevOps Report 2021)

Developers need an environment where they have the confidence to innovate and contribute back to their community, help grow the business, improve their skill sets and further their careers without being limited by the people, practices and tools around them.

Ref.: Bridging the Developer Experience (DevX) Gap

What it doesn't includes

  • Asking people to do repetitive tasks
  • Asking company to have a lot of silos

... This means that developers are being forced to take time away from writing code—the reason why they are employed in the first place—to dedicate valuable time and resources toward understanding and managing issues associated with highly complex, multi-cloud toolchains that are often being held together by nothing more than sticky tape and string.

In other words, the very same market that is telling developers they can have anything they want to do their jobs more efficiently is simultaneously telling them that piecing the whole thing together is their problem. This is the gap for developers: It’s a gap between expectations and current reality. And a bridge across that gap needs to be built for organizations to get the most out of DevOps.

Ref.: Bridging the Developer Experience (DevX) Gap

How to put in place this practice

...

Predictive tests selection

This one is complicated, but if we can do predictive test selection, it avoid retesting the entire system every time when only one part of the system changed.

One way of doing this, can be by using some metadata tags or similar within your tests. This way, you can test only one part of the system.

Note: Tests are often the bottleneck of all the development & deployment.

Feature flags

Feature flags can be part of this in order to move work to production even if now all the feature is completed. In a different perspective is that we can disable anything failing within the new deployment really fast.

Existing Tools for this:

  • ...tbd... (see gitlab proposition, it seems like a nice one)

Deployments

ArgoCD can probably do it properly. .... NEEDS TO BE LOOKED INTO .... I know FluxCD can do something similar to what we need, but it would require a build to interface with the cluster to enforce some versions.

Monitoring

Need to have proper alarms and proper error messages trapped.

  • Report on the health of a system
  • Report on the health of the product, as experienced by end-users
  • Monitor for key business metrics
  • Monitor for key systems metrics
  • Enable debugging during production
  • Deliver access to data that diagnoses problems and provides a path forward

(Ref.: DevX in DevOps: How Developer Experience is Affected by Your Pipeline)

Basically what it will give

  • Faster time-to-market
  • Faster development
  • Empowering the dev.

References

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment