Where should your focus be when working professionally as a software developer? What tasks really matter? What areas of your job matter the most?
Some time Ago
This twitter tweet sparked a discussion around how to measure the productivity of a software development team. I'll highlight some of the most common answers:
- # of opened/resolved tickets
- Site up-time
- Site error percentage
- Regular release cadence
- Perceived improved productivity (by survey/poll)
- Raw increased revenue
- Meeting business outcomes
- Positive user feedback
- Sum of sprint story points / time
- Meeting expected estimates
- Amount of working software
- Customer satisfaction
- Time to get PRs merged
It's A Tricky Business
Most of these are what I would call symptoms of a productive team. They are, therefore, valuable to measure to some degree.
Some of them do raise more questions, however.
"Regular release cadence"
OK. Once a year is a regular cadence, technically ðĪ·ââïļ.
"Raw increased revenue"
OK. How do you know this was caused by a productive dev team and not a marketing effort, etc. ðĪ·ââïļ?
"Positive user feedback"
OK. But, customers who test your product and find that it is really poor or doesn't meet their needs typically do not leave any feedback. So how do you know about the 80% of customers you are not onboarding due to missing certain features or options ðĪ·ââïļ?
I hope you can see that you need to be careful about choosing what metrics matter.
Productive Businesses
I think it's true that productive dev teams do contribute a large portion to the success of a company!
Recently, the book "Accelerate: The Science of Lean Software and DevOps" has been getting rave reviews.
It tackles this topic in a more holistic way by asking how certain software development practices can cause a business to become more productive and successful.
Things like having a short time between "commit to deploy", continuous integration/deployment, working in small batches, allowing experimentation, etc.
While many of these might sound obvious to us, the real feat of the book is that it uses legit research and data to prove these.
P.S. This article is originally from YourDevCareer.com where you can check out more articles and resources to help accelerate your career growth!
What Can I Do To Help?
That's great. But you might not have the ability to simply tell your organization to start doing all these things! Most of us don't.
We have projects that are currently planned for the year that need to get done ASAP.
There might be politics in your organization that are preventing you from implementing or even suggesting these changes?
Your business might be undergoing some sort of overall re-structuring that prevents these kinds of discussions at the moment?
Many of the items mentioned above (CI, CD, etc.) are practices that will require your dev team as a whole to adopt.
One of the things you can do as a starting point is to become an advocate of these practices. Whenever there are issues which are due to a lack of, for example, automated tests (or not having any tests in the first place!) - raise that fact. Point out how important this practice is.
If you have resources like the book mentioned above - use real data and real stories. Find out about other companies who have gone through similar struggles and share that with your team/org.
The first step is to simply point out the pain points that these kinds of improvements will solve.
Pro Tip
Here's a great tip that's worked really well for me. If you are able to prototype, implement a process or establish a practice that you know will improve things for your team/org, and it won't take that long, then just do it.
When I started working for the company I'm at right now, all software deployments were 100% manual and very prone to human error. There were multiple steps to the process (which weren't documented anywhere either...) which, when not followed, would cause issues on the production application ðĪŠ.
One of the first things I began to bring up was this issue. Nobody was actually doing anything about it though. There was a past history of certain politics/expectations in play. I just did it anyway.
This is the status quo: we like to talk and complain about things - but not fix them.
Once I saw that nothing was getting fixed, I wrote a script that automated the entire build/deploy process for our development environments. This vastly simplified the process.
But, some people used it. Some didn't ðĪĶââïļ.
Next step, I rigged up a continuous build process using a popular CI service. Over the course of a few weeks, I slowly added more to it, showed everyone on the team how it would help (especially the project manager!). Eventually, step-by-step, we adopted this as the full build/deployment mechanism.
It's possible!
It just takes real work. Someone needs to just do it and literally demonstrate how it can save time or money.
What Can You Change?
Ask yourself: "What business process or improvement can I start tackling?"
Make sure you have research sources to rely on. Start with something smaller than bigger.
In my case, I started with a script. That grew into something bigger. I also had a short list of research and studies on how automation can dramatically reduce bugs in software, etc.
If you can implement new processes, introduce new technologies, teach new ways to write software, etc. that make life easier for your direct manager - then you'll be positioning yourself as someone who:
- a. Gets work done
- b. Is improving the business - not just slinging code.
Anyone can sling code. Those who improve businesses are worth promoting and treasuring!
Keep In Touch
Don't forget to connect with me on:
Navigating Your Software Development Career Newsletter
An e-mail newsletter that will help you level-up in your career as a software developer! Ever wonder:
â What are the general stages of a software developer?
â How do I know which stage I'm at? How do I get to the next stage?
â What is a tech leader and how do I become one?
â Is there someone willing to walk with me and answer my questions?
Sound interesting? Join the community!
Top comments (3)
This should be the biggest takeaway here.
Often people fear change. Don't give them an excuse to tell you "no" until you've already proven to them that your idea works.
great! thanks james
You're welcome ð