Working Better with Developers
Good Developers are a Rare, and Expensive Commodity
A Developers time is best spent doing the work that really makes a difference for your team and your product. While there are many topics to cover for how Developers may manage their time, there are things we can do to allow Developers to spend more time working on the problems they specialize in.
Here are a few thoughts on how to improve team performance and culture.
Learn how to Perform Common Tasks
It is great to spread the work load out amongst teammates. In the case of conserving Developer hours, look for ways to take common tasks into your own hands. For example, does your Developer frequently need to send an email to ask another team to perform a common task? Try to learn the details of that work and see if you can handle it yourself or delegate the task to another member of your team.
Learn how to do more things on our own that do not necessarily require a Developer to do. While in our day to day tasks - of those tasks which ones are done with software that we could learn to use ourselves? Better yet are there ways we may build automation around those tasks so no one has to do them again?
A simple example of something anyone on the team can do is when new work needs to be added to a project management tool.
Mitigate for Developer hours by taking the time to go into the tools and perform the data entry required. Later during the next planning meeting bring the project up to the Development team.
The best teams are joined by non-technical individuals who ask great questions and are willing to get into the mix with their Developers. Take on new challenges and get creative with how you conserve Dev hours.
Break Down Projects into Smaller Parts
Project scope has been one of the more difficult topics I have seen professionals grapple with. It is harder for professionals to break down larger thoughts or technical projects into smaller parts than it is to handle them all at once. Challenge ourselves and think creatively about our products and define clear milestones. From those milestones define tasks that need to be do be met to accomplish each of them.
When uncertain as to how to break down a project seek consultation from the team. Openly discuss the project and the steps required to complete it. From that meeting take the discussion and document each point that needs attention and celebrate each win along the way.
A baseball game has never been won by a single swing of the bat.
Clearly Document Tasks
I have seen Jira boards, Asana lists and spreadsheets littered with abbreviated or nicknamed projects that make no sense whatsoever. Don't make your project inventory a list of inside jokes. The best project descriptions are the ones that allow a new teammate to come in and pick up right where you left off.
Clearly documented tasks are more likely to get done during open Developer cycles since the Developer does not have to do any extra work to decipher exactly what the project needs are. A task could be very simple yet very valuable. Make every task easy to pick up and get completed.
Pro Tip: Be careful with creating nicknames for initiatives. Over time people forget what Sasquatchy 4000 was intended to do to in the first place.
Learn and Practice Debugging
My favorite teammates are the ones that try to figure out what it is that is going on before coming to me with an issue. These teammates ask great questions that build their skills like:
How can I see what data is available on the webpage?
My answer to this question was a mini lesson on Chrome's Dev Tools. Later we explored the requests made by the page and another lesson on reading JSON. From that day forward that teammate asked fewer questions and became much stronger in conversations with Developers. They wrote better tickets and were able to clearly explain issues and save Dev hours. By investing time into learning more about the different functions of how your team operates you find ways to help each other and improve communication.
Make Sure Issue Reports are Clear
Many issues that are reported suffer from vague meaningless descriptions like:
I clicked on the button and a flash occurred... I wasn't sure what happened but I ended up on a search web page. Now for some reason I cannot open Powerpoint? This is so ugly we need to take it down immediately. Can you fix please?
Where would you start? In this example a Developer would have to reach out to whomever originally reported the issue and interview the reporter before they could even begin to think about what could be causing the issue.
When there is a bug somewhere in a product a Developer has to become a detective. Since there could be so many different things going wrong with any part of a system it is important to be as specific as possible. Take the time up front to be as clear as you can. When articulating an issue or a feature explain it as you would explain it to someone who has never seen or heard of what you found.
Here is a clearer example:
I clicked our logo at the top of our home page ( www.jjmasse.com ) and received a 404 error.
Notice how fewer words there are. When constructing requests try to think of them as tweets. Keep it to 140 character maximum and that should force you to focus on only the important details.
Also notice how we kept emotion and subjective matter out of the request. Stick to the facts and only the facts. It will really help with focusing in on what is important. Personal feelings are not what matters but instead think of the users. Don't waste time speculating either. Users will always prove us wrong.
Focus on the solution, not the problem.
Refactor bug reports
To save Developer hours pitch in on deciphering issues and feature requests. Before a Developer even sees the request take some time to dig in yourself. Look at it subjectively, is it clear to you what is being asked? Do your best, everything takes practice including the breaking down of messy and misleading requests. But your Developers will really appreciate you taking the time to make sure what is asked of them is asked clearly.
Why is This All About Dev's?
Communication between teammates is important. It is just as important for a Developer to be able to explain a technical issue to non-technical professionals as it is for non-technical professionals to explain their needs to a Developer. Find ways to break down the walls of communication and save each other time by lending a hand in the work that you feel comfortable with.
Your projects and Developers will appreciate you for it.
Taking it Further
This post was inspired by an introductory class I am developing in collaboration with my colleagues and made available on ClassMate.io.
Your feedback will only help make this content better.