Search for a command to run...
how any developer could create a better Developer Experience for teammates
I'm a Full Stack Developer, Software Architect, and Aspiring Technopreneur, looking to fuse entrepreneurship and technology to deliver quality-of-life improvement products.
No comments yet. Be the first to comment.
Code editor with AI Agent, Real Time Data Synchronisation, WoW Server Simulation
dockerised macOS, Golang, ScyllaDB and Kubernetes alternatives
I want to rekindle my interest in programming again, and this time I choose to go with Golang.
homelab and personalised computing environment for home.
how I approach chess through various stages in my life.
On this page
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.
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.
sources from: https://hygger.io/guides/agile/manifesto/
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. 💻
A few things for consideration:
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.
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.