Photo by Austin Distel on Unsplash
Those Little Things that affected the Developer Experience, and yield Impact on the Project Delivery
4 min read
After reading this article on Linkedin I agree that "work has become more transactional as social circles shrink to family and closest friends". Minus the part good/bad for the business, let's take this context, and talk about how we as Developers and extended team members work together in coding, delivery of features, and products.
Bonding and Candour
I think it's important to have Engagement between Developers and also the extended team. A genuine exchange of what's difficult in the current work implementation, or impediment creates trust. That kind of transparency leads to team harmony. A lot of supporting ideas from the 5 Scrum.org core values. Most important is expecting some form of courage and openness, thus leading to the adoption of a few core values like 'focus, commitment, respect'. On the other hand, I think shrewdness & scheming are something definitely need to be avoided. I mean encourage a higher level of transparency by communicating the context, adding description and elaboration to the statement that was presented. Even if someone utters something silly, give them a chance, and provide a safe environment to step down.
Build Tools and Swiss-Army Knife to your operation problem
consider building small tools to assist your developer to run things, to fixing things. Such to automate the deployment process, that could instantly serve their code from local to the shared Development environment that others could validate and audit. The smoothness in the development work would really give a good impact on the overall team morale. Another example would be considered a minor script that reset some system behaviour in case testing went wrong, or some data reset script, dump restores database script.. Anything you think that would bring the Quality of Life improvement to yourself, and your team, that's something worth investing a little bit of time to make happen.
Think about how you build & develop your solution
creating a platform that makes development work iterable, and repeatable at such would reduce the strain and stress on your development team, such that they could allocate energy for high-level thinking. For example, when introducing a new entity in the database, there is often the need to build the CRUD operation and REST API.. just if those things could be replaced with a framework like Strapi? (strapi.io) or some headless CMS then the developer could allocate their time for other frontend customization, or more advanced business algorithms. Indirectly those redirections of energy would result in a more productive team, and better quality of delivery, less error-prone.
The trick is.. write as little code as possible, then less work for the developer to debug things.
Complicated Works that require more than 1 person to handle it
in the workplace, it's mostly about interdependency. From time to time we have works that require a deeper thought process. Thus I'll say to split into smaller chunks, walk through all the developers to have a common ground of understanding the context, the rationale why we need to build that, and what technical path we have traversed down.
Preparing a guided conversation, and implementation plan, would create alignment and improve the team morale. Ask them any questions, ask them if any concerns, attempt to spark conversation, and give everyone a chance to be heard. Perhaps from their angle, that would help to validate the idea. Sometimes, people have a brilliant idea that I would find well compensate for what I'm lacking.
Promotes Higher Degree of Communication
Encourage team members to pick up necessary soft skills, and communication skills ability. The ability to explain that intangible context, really saves our time and effort to search in the blind or avoid some unnecessary implementation, and code duplication. Moreover, don't set a trap for your peer developer, if you see a problem, probably you can see the solutions too. Otherwise, alert the team to brainstorm together
Summary of my view on Developer Experience
DevExp is about shared responsibilities, each one of us plays a part in shaping the experience for others, either by improving the IDE and project setup, CI/CD, creating tools, all the way communication style, and collaboration methods.
Hence, how about something to hear from you, fellow reader? Are there actually tools you want to mention that may change the landscape of programming?
Did you find this article valuable?
Support William Cheong Weelau by becoming a sponsor. Any amount is appreciated!