I've developed software professionally for the past 10 years. Here's a list of 100 things I've learned about software developer productivity.
At the beginning of your career, learning to "code fast" significantly impacts your productivity. Once you're "good enough," the impact substantially diminishes. Pay attention to when this happens.
Don't be too proud to try and" hack your mind." Many productivity tips that sound patronizing actually work.
Write your tasks down and use a to-do list.
Having a tangible goal will make you move faster.
Procastination is normal. Start by writing a single line.
What works for someone else might not work for you.
Try Pomodoro. It might work for you.
Learn what makes you productive.
Set boundaries that enable you to work in a way that makes you productive.
Strong intrinsic motivation and curiosity trumps all productivity hacks.
Learn how to tap into your intrinsic motivation.
Pair program and watch other people code. You might pick up a skill or two that help you work faster.
Your intuition affects your productivity more than you know. Pay attention to cultivating a good intuition.
Learning out of a bad habit takes work. Invest in learning good habits.
Saying "yes" to everything will destroy your productivity. You need a personal WIP limit.
Being obsessed about your work will make you temporarily more productive but burn you out if stretched for too long.
Physical exercise, eating healthy, and sleeping well do not take away, but contribute to your productivity.
Take regular breaks (e.g., 10 minutes every 50 minutes).
Trying to work in too long stretches will teach your brain to start wandering off to memes and hot takes on Twitter.
Make sure you have enough focus time for deep work and "flow."
Disable all the notifications you can.
Being in "flow" makes you feel productive but does not always mean you're making progress.
You can spend hours polishing an abstraction but deliver zero customer and business value.
Being productive does not mean you're making an impact. Work hard on things that matter.
The more experience I get, the more I'm interested in improving how my team or organization works together vs. optimizing my individual productivity.
When solving technical problems that require collaboration, the bottleneck for individual developer productivity is not your ability to write code but the team's ability to create viable solutions.
Most problems in building great software products require collaboration. Your ability to collaborate will become a bottleneck.
You will be more productive in some teams/companies than others.
Eventually, the bottleneck for your productivity will be the team and organization surrounding you.
Developer productivity and compensation don't often go hand in hand.
Some companies will compensate you more for the same work than others.
The best "10x engineers" are the ones who 10x the team and people working around them.
Delegate and help other people. Learn to celebrate their success.
Learn to use automation. Removing errors and reducing cognitive load has a more significant impact on your productivity than "working faster."
Developer experience and ergonomics matter.
Automatically format your code with a deterministic code formatter like Prettier or Black.
Use a linter. Learn how to write custom rules to match the way your team works.
Write automated tests. Life is too short for constantly fixing trivial bugs.
Setting up a Continuous Integration (CI) pipeline is likely easier than you think. Learning how to do it will save you time in every future software project.
Keep feedback loops fast.
Automatically deploy to production.
Keep your build times low.
Make sure developers can run the test suite on their computers.
Enable automatically running related tests on file changes.
Use feature flags to allow shipping work faster to production.
You might not need a staging environment.
You might benefit from a staging environment.
It depends.
Developers using Vim look like they're much more productive than the rest.
Don't always pick the tasks that make you feel most productive. It will stagnate your learning and make you feel that you're not moving forward.
Prioritize reviewing code. It will help your team stay productive.
Every time a developer prioritizes reviewing code, a new star is born in the Torvalds & Carmack galaxy.
Being "agile" has very little practical meaning.
Calculating velocity and story points rarely help teams improve their productivity.
Small, practical change based on data trump "agile transformation."
The goal of planning is to split the elephant into bite-sized pieces.
Developers often prefer working alone on large tasks for long periods.
Developers working alone on large tasks for long periods rarely result in the smallest possible increment being shipped fast.
Working together on a task is often less productive in the short run.
Working together on a task improves learning and is often more productive in the long run.
With large codebases, developer productivity largely depends on their knowledge of the system.
Splitting large codebases into modules helps new developers become productive faster.
Modular architecture only works if the API contracts are clear and modules are truly decoupled from each other.
Sometimes, a developer is more productive than others only because they have more knowledge and power.
A single developer owning a disproportionate amount of knowledge and power in a team will lead to some developers underperforming.
A "10x engineer" born out of owning a disproportionate amount of knowledge and power is an anti-pattern and will lead to capable developers leaving your company. Avoid it at all costs.
Measuring developer productivity only through activity (e.g. # of commits or PR reviews) does not work.
Trying to condense developer productivity into a single metric will fail and make developers lose their trust in the company's management.
Measuring individual developer productivity is hard. If you try to do that, you will likely lose more than gain.
When trying to measure developer productivity, data quality is crucial. Bad decisions made based on poor data are costly.
There is much more reliable research on software developer productivity than most developers realize.
Focusing on team and organizational level developer productivity will yield the best results.
Reading the book "Accelerate" and understanding the SPACE framework will give you a good start to understanding development team productivity.
When measuring developer productivity, you should have multiple metrics that complement and challenge each other.
The subjective experience of developers is valuable data.
Only relying on the subjective experience of developers is not enough. Especially when trying to improve development productivity across the organization.
Improving software team productivity is largely about trying to improve the flow of work while keeping quality high and working at a sustainable pace.
Measuring your team's cycle time and deployment frequency will help you improve your flow of work.
Knowing how much time your team spends fixing bugs vs. feature work will help you prioritize writing tests, fix technical debt, and keep your quality high.
Developing software is a marathon, not a sprint. Optimize accordingly.
Teams should be in charge of improving their own productivity and have access to the necessary metrics and tools.
Individual developers benefit from understanding what affects their teams' overall productivity.
Most teams try to do too many things at the same time. You need a WIP limit.
WIP limits improve collaboration and help you ship the most important stuff.
WIP limits reduce procrastination on hard tasks.
WIP limits combined with good prioritization help individual developers work on things they're not familiar with and encourage learning.
Encouraging learning makes software developers more productive in the long run.
Consistently good work is better than heroics.
Organizations that put heroism above consistently good work perform worse in the long run.
Developers love to measure everything else but their own productivity.
Early attempts at measuring software developer productivity ruined the whole thing for most developers.
It is hard to recover from industry trauma.
Don't focus on measuring individual developers if you're trying to improve your company's software development speed.
Learning about Lean and Queuing theory is valuable when improving software team productivity.
Consultants have done a great job ruining Lean for the rest of us.
Measuring software team productivity can make engineering teams happier.
Measuring software team productivity only makes teams happier and more productive if they're on board.
If developers are not on board, your metrics will be gamed.
Not giving your developers proper autonomy and control over their work will make them unhappy. Do not micromanage.
Happy engineers are more productive.
See and share on Twitter
You can see these tips in Twitter thread here:
Top comments (4)
I enjoyed reading this post and now link to it from github.com/shlomif/Freenode-progra... . Thanks for sharing!
Great to hear!
Item #3: when it says write...write, get it out of your head, and out of the computer as well. There is nothing more satisfying than to have a journal of all your accomplished tasks to use as source material during an annual review or when pitching yourself for a raise/promotion. Additionally the act of writing helps with memory and understanding of the tasks at hand.
Item #49: Just because they look productive doesn't mean that they are. Spending more time on tweaking overly simple tools to make them effective in a complex environment is busywork, and not helping the customer. Conversely a developer using an IDE like WebStorm/PhpStorm/IntelliJ may not appear as productive but are more likely to be focused on the customer's problem than their development tools.
Came across this post, great to see big list of insights, thanks for putting this together !
I have a tool to share which can boost developer productivity while working with design diagrams : blockdiagram.onrender.com/ , try it out and it will be great to get your feedback on the same.
Thanks