Developer experience

Photo by Annie Spratt on Unsplash

when the first thing you googled what's DX (Developer Experience) you may come across an article from redhat.com.

Developer experience describes the interactions and feelings that a developer has when working with a body of code in order to meet a specific objective.

My take on the Developer Experience

I have a renewed perspective of Developer Experience when I was reading the book on Montessori education for kids. Essentially it is describing how to prepare the environment, to complement the parent and child interaction.

translating it to our context, this may become preparing the environment to complement the interaction between the People and the Technology.

Let's start with people. It's only by becoming the better employer, able to retain employees grow them to be 2x if not 5x or 10x Developers. Building Talents in another word translate to a higher chance of success.

People interaction probably are the hardest however collaborative behaviour could be advocated.

• creating a fixed routine for different activities. Adopting an Agile Framework, either kanban or scrum helps. Expectable routines create a sense of comfortability for everyone. and the following agile manifesto would help to guide us in many debatable situations.

sources from: hygger.io/guides/agile/manifesto

• People has a different level of imaginations. Software development is often a highly abstract art, the creation process is hardly tangible. Thus creating visuals that assist others in understanding is an ideal approach.
• create different views for different audiences. developers may want to data structures, tables, wireframes or flow, business users may want to see screens & flow, stakeholders may want to see components and timeline, roadmap.
• do a pulse check on your teammates, ask if they have troubles in their development task. Instead of going solo, going in pair-programming works.

Decide on the Technology, Infrastructure that is optimized for your team delivery.

decision plays an important role. sometimes we may pick the easiest framework at the beginning and over time then we face problems maintaining it as the code becoming larger, and we have scalability issues.

We realize we may need to overhaul a bit, or doing some refactoring such that we could developer faster in the next iteration. Let's look at some popular opinions versus some conventional choices. The possible flip side of the situation.

• utility based, libraries vs opinionated framework, this gives developer freedom in the former choice, then over time when there are more developers, more business requirements, everyone has their style and way of structuring the codes, more utils being added.

• the microservices vs mono-repo, monolithic design, it's nothing wrong to pick microservices, it gives a certain degree of freedom. it also means increasing demands on the team size more redundant infrastructure, and setup, introducing certain complexity.

evaluate what's best for your situation. Everyone's mileage may vary. Trust the gut feeling. Take it with a pinch of salt. You just need to courage to make it happen.

Loose Coupling and High Cohesion

this is one of my favourite guiding principles when managing technology. Applying the right amount of abstraction to make things simpler, show people what actually need from your class, your service, or your API. Things should be loosely coupled, reducing any dependencies on others. such that impacts are dampened, and made minimal, avoiding the domino effect of ... collapsing.

Write readable code, may employ longer variable name, annotation, comment, descriptive API routes, setup an accessible swagger document that allows instant testing, or GraphQL Playground

Last by not least, share your favourite IDE + Extensions that delight your day to day working experience. 💻

Cultivate a delightful and safe environment for collaboration, question and discussion

A few things for consideration:

• how easy to boot up a local development on a developer machine?
• is there a quick start markdown README.md to provide insight into the software?

• do you have a communication platform for questions, pinned notes, and different spaces for specific topic discussion? - think of tools like Slack, Discord, or Webex, (with workspace & team in mind)

  each individual can do something to change the energy & atmosphere in a team. If you practise being calm, it generates a sense of peaceful moment with your presence. if you're helping people with understanding, providing clarity, people feel good with your presence too. If you're volunteering to assist in those seeming important works by gotten least attention (e.g. project configuration, document, build automation tools, scripts, posting of information, organized materials & docs), you might notice as-if the entire engine runs with lubricant, and things go smoother

Always keep trying (regardless if disappointment, mismatched expectation happened). Aim to create a Positive Learning Experience for your teammates. The harmony ends the moment when someone said he/she tried. There are ups and downs, just learn to rejuvenate over the never-ending journey of development.

Meanwhile allow trials and errors, creating a safety net, and allow the margin for any experiment. Practising effective source-control like Git, mastering the proper tagging, branching, cherry-pick, interactive rebase, could almost save disaster that happened to the project code repository.

TIPS: if someone ever struggled to set up the complete environment, make some of the components shareable, runs it in the cloud, creating a common backend API, or shared database. this would greatly enhance the developer experience.

At the end of the day, culture plays a large part in determining the overall success of the project execution.

• Are we helping each other to be better Developers?
• Are we creating competition or we're welcoming voluntary contributions?
• Are we creating a vicious loop to add stress & question to everyone or do we pause for a moment to assist our peers in delivering their work?
• Are we the ever-busy person, or do we actually make time to assist our teammates to solve problems together?

TIPS: a fully 100% utilized day is most probably the unproductive approach. Less is more. Make room for imagination, experiment, and exploration.

Many aspects were actually answered in the Scrum methodology. We do carry the responsibility to shape our environment, value adds to the technology and positively influencing our colleagues for a better developer experience.