Software Developer Productivity Tips Follow-Up - 5 Examples
Last week I provided 10 tips for how software developers can be more productive. This week I want to provide 5 specific examples of senior developer actions that demonstrate a focus on productivity.
Last week I provided 10 tips for how software developers can be more productive. I received some good feedback on social media and got general head nods in agreement. This week I want to provide 5 specific examples of senior developer actions that demonstrate a focus on productivity and that positively impact their project and ultimately their career.
These are real-world examples from developers who have worked for me in the past. As a director or senior director at the time, I was in a position to see not only the impact of these examples on the specific situation but on the people around them and on the project as a whole. And, these are the kind of actions that absolutely get discussed during performance reviews.
#1 Be Present In The Moment
When it’s time for stand-up, be there and actively contribute to the stand-up. When helping another developer who has asked for help, focus on helping them right then and there. When solving a production issue, attending a project meeting, or attending a lunch-and-learn session to talk about some new technology, be there and be focused.
When you are not present in the moment, whatever is happening in that moment is happening without you, and that's a waste of your time and likely those around you.
Meeting Hell
Don’t get me wrong - none of us like back-to-back meetings all day long. It’s hard to get actual software development done when we’re in meetings - right?! But by being present and active in meetings, you can actually reduce the number of necessary meetings because you are making the time more impactful! You can actually ensure that your time is better spent on the right things.
An example
I once had a senior engineer who, everyone thought, didn’t like stand-ups. It was an agile shop, and the team for a new project started the daily stand-up ritual. The goal was to accomplish the usual with each member:
- What have you completed since the last stand-up
- What is your goal for today
- What are your impediments that need to be resolved
At each daily stand-up (this is back before Covid put us all remote), everyone would gather for the meeting and sit around the table. But the senior engineer would come in and stand. Everyone thought he didn’t want to be there. But in fact, this senior developer was making a great point that quickly became a great lesson and changed the stand-up altogether. This senior engineer was there to be present in the moment - the stand-up moment - specifically focused on stand-up.
He participated each day, providing his information and offering to assist in resolving impediments once the stand-up was complete. But he also demonstrated in his own way that he, and everyone, are there to be present for stand-up. Get stand-up accomplished, bring any necessary takeaways from stand-up to other necessary activities, and move on to the next thing.
Within a week, the 45-minute stand-up that was stand-up and social time and problem-solving time, became a 15-minute stand-up truly focused on the core activities. He helped accomplish the goal of the daily meeting and also saved himself and everyone else up to 30 minutes each day thereafter.
#2 It’s Not Their Job To Test Your Code
Some organizations have dedicated quality assurance testers and some do not. Some use business resources to help test code. Some even use external vendors and focus groups to help profile and even test their code. But good productive developers don’t rely on other resources to test their code.
Productive developers close the loop from code design to code deployed as quickly as possible.
The software industry in general seems to have gotten better at this over the years. Historically, there was more of a sense of “get it coded and throw it over the wall” for someone else to test and find bugs. This seems to have improved greatly in more recent years. I think this is due both to technology improvements and to general organization expectation improvements.
Delegate - but do it well
Whether you are doing TDD (test-driven design), BDD (behavior-driven design), or neither, you know your code better than anyone else. You are most productive when you write the appropriate unit, system, and integration tests during the development process. When you do this, more of the testing becomes an integral part of code development. Testing happens quicker, more consistently, and catches issues much faster.
When you don’t do this, your test code coverage is low and you are in fact throwing your code over the wall for someone else to test - this is very unproductive.
An example
Let’s compare two organizations I’ve seen. One organization had a “throw code over the wall” problem and one organization did not.
In the “throw code over the wall” organization, the process required dedicated qa resources to test code at multiple levels. This included smoke testing, edge case testing, system testing, integration testing, and even some of what should have been unit testing.
I remember a particular qa resource often had a large stack of printouts on their desk representing all the tests they needed to work through.
This stack represented wasted productivity - it represented many hours of other people’s time being held up waiting on these tests to complete. At least 90% of these tests should have been automated tests created by the developers at the time they were writing their code. Needless to say, it took much longer to deploy quality code to production than it should have.
Compare that to a much more productive organization I’ve been a part of. In this organization, writing tests was an integral part of the development process. As a result of this much stronger developer-driven testing mentality:
- Fewer bugs ever made it past the development process, much less to production
- Code was being pushed to production literally half a dozen times a day or more with no downtime
- The organization had no dedicated qa resources - at all
Now that’s productivity.
#3 A Helpful Smile Down Every Aisle
Developers often have reputations for being non-social introverts who will get more done if left alone. While that’s definitely true of some, the pattern among productive software engineers is different. Productive software engineers spend time helping others. They see this as an investment in future productivity.
Everyone has a role on the team. Whether doing agile, scrum, hybrid, waterfall, or any other team approach, the team is comprised of multiple roles that all have a job to do. And when it comes to building technical solutions, these teams must work very well together to produce quality results.
These team roles are also very interdependent. Software developers depend on each other for help. But also, product owners depend on the software developers and vice versa to synchronize what is being built and why. Scrum masters depend on everyone for status and impediment call-outs to keep things moving efficiently.
So, everything a developer can do to help anyone on the team be productive, whether that other role is a developer or not, helps everyone’s productivity in the end.
An example
I’ve seen these specific examples so many times I’ll just list a few of them. But rest assured these are from real-world situations:
- A developer takes the time to help another developer understand and implement a few important design patterns, and those best practices become part of that code base for literally years to come
- A developer prepares ahead of time and does a good honest code review with another developer. This feedback, based on quality review time, leads to better code immediately and into the future
- A product owner spends time with a developer to walk through some intricacies of a specific feature to make sure they understand some edge case implications, and the result is much stronger unit tests that don’t have to be manually tested
Don’t do someone else’s job. Look for ways to provide them with information from your perspective that can help them do it as well as they can so that the team interdependencies are as efficient and productive as possible.
#4 Just Say No
I know I said some developers have a reputation for being non-social introverts. Well even if that is sometimes true, I have personally worked with quite a few of those same developers who are willing to walk through fire to get something done when asked. Even when they shouldn’t.
Productive software engineers use a solid prioritization process to work on the right things at the right time and know when to say no.
Prioritization is key on this one. If you have a solid prioritization process, it’s easy to know when you should say no and it’s also easier to actually say it because you have objective information on which to base your answer.
Let’s take the Eisenhower Decision Matrix as an example. It helps you categorize your work into 4 quadrants of urgent and important. So, something can be urgent and important. It can be urgent but not important. It can be not urgent but important. And it might be not urgent and not important but is being asked of you anyway.
By working with your team, and with your manager as necessary, to align everything on its urgency and its importance, it’s easier to take any request and apply it to the same categories as all the other requests. You can more easily say no you cannot do something because look at the list of urgent and important tasks already queued up to be done.
An example
The classic example is “death by a thousand paper cuts.” As a developer, you’re at the office in your cube. Or, you’re working from home and you have slack or Teams chat up. Someone comes by your desk, or pings you, asking if you can look into an issue. It sounds quick and you want to be helpful so you look into it. Another quick ping comes through and you take a quick look at that too. Then another. Suddenly, the end of the day is near, and you realize you didn’t get anything done that was planned for the sprint.
I’ve had many conversations with many different developers about this exact issue. They don’t want to say no. They want to be helpful. It will only take a little bit of time. But those little things add up. All of a sudden, they have given more priority to unimportant non-urgent tasks than to urgent and important ones whose delivery will bring significant value to the business.
They just gave more priority to Sue’s file export question in accounting than to the multi-million dollar project currently in progress. They should have said no.
#5 You Spend All Your Time There - Use It
This last one is short but a huge productivity that I think a lot of developers miss. Software engineers spend a lot of time in their IDE (integrated development environment). And nowadays these IDEs are amazing pieces of software. Visual Studio, Eclipse, IntelliJ, Webstorm, Atom, there are many different IDEs and many of them are very good. With the breadth of languages and platforms and frameworks these IDEs support, they seem to be getting larger and more complex by the day.
Don’t let the size and complexity of your IDE rob you of important productivity gains they can be giving you every day.
Some examples
Here are some small productivity tips for Visual Studio. When you apply these and add up the potential time savings, these could give you back significant time in your day:
- Writing constructors - quit typing out your constructors - just type ctor then double-tab and it will boilerplate a constructor for you
- Writing properties - same for properties - just type prop then double-tab and get the same. VS has lots of different quick key snippets to save you lots of typing time
- Cycle Clipboard Ring - use this feature to enable cycling through the last 15 cut or copied content you have made so that you can choose from any of them to paste rather than just the most recent
- Conditional debugging - instead of stepping through all 20 iterations of a loop to get to the record you need to debug, use conditional debugging to set the condition at which the breakpoint is to stop
- Extensions - be aware of the many awesome extensions that are available and which ones can boost productivity in your specific situation
What Will Your Developer Productivity Examples Be?
These are great examples that show focus, commitment, prioritization, and a desire for results. It doesn’t matter what software engineer level you are. If you can demonstrate these kinds of actions in your daily work, then you are well on your way to a productive career.
Click Here for more info and how to watch a free video preview.
Kevin
Kevin