Productivity tips for software developers
Remember the saying about the chain being only as strong as its weakest link? When it comes to software projects, you can make the right choices most of the time, but the one thing you do wrong will still cost you an order of magnitude loss of efficiency. And people usually err more than once...
It came to me as a surprise, but I usually end up on the high end of productivity benchmarks. This observation holds across many different metrics and several past jobs. Clearly I must be doing something right. I have a lifelong process of removing all obstacles that slow me down, but you will likely find it easier to just skim through this checklist of optimizations I have already discovered. I am listing only optimizations with an order-of-magnitude local effect as those are likely to improve overall productivity.
Priorities:
- Product value trumps development practices trumps personal skill.
- UX is untouchable. Never sacrifice UX just to improve developer productivity.
- Kill all bugs and misdesigns on the spot without warning. Backlog is insanely expensive.
- Ignore bugtracker and task lists. Work on stuff that moves needles on metrics.
- Userbase never grows quickly. You can safely ignore scalability at the beginning (and often forever).
- Plan ahead. Plans can be minimized and optimized. No excuses. Partially observable or changing world just means partial or flexible planning. Proceeding without any plan at all will result in wasted effort.
- Apply big transformative macro-optimizations before resorting to micro-optimization tuning. It is more efficient that way. This rule applies to the whole stack from high-level UX to low-level algorithms.
- Prefer tasks you are interested in at the moment. You will do them faster and better.
People:
- Block hires of C's (slackers, bros). Demand B's (hard-working pros) everywhere and pull in A's (high-performing naturals) opportunistically. A's are more plentiful and more useful that commonly assumed. Some projects require A's.
- Break out of the sandbox. Hoard business information, access permissions, and your share in decision making. Approach people directly, bypassing organizational structure. Edit other people's code.
- Ignore all paperwork and bureaucracy people try to throw at you. You can safely disregard coding guidelines, status meetings, hourly reporting, processes and protocols, and all the management nonsense as far as you still deliver valuable results.
- Unblocking other people is more important than proceeding with your own work. Don't become the new bureaucracy. Give people independence and seek the same for yourself.
- Minimize no man's land code shared by multiple developers. Everyone has different approach, style, and unspoken invariants. It is better to let people do whatever works for them.
Office:
- Beware of toxic buildings. Poor air quality can render you incapable of doing any cognitive work and even permanently damage your brain. If you suspect something, measure air quality. Another problem is light. Natural light usually doesn't come from the right direction in the right intensity.
- Beware of computers compromised by your employer. If you are not able to secure you work computer, you might end up compensating for it with security measures that severely constrain your workflow.
- Protect your privacy. Budding creative ideas must be shielded from disapproving words and looks.
- Replace as much keyboard navigation as possible with visual navigation. Use multiple big monitors. Write concise and somewhat horizontal code. The more you see at once, the better.
- After considering all these issues, home turns out to be a surprisingly good place for work.
Quality:
- Aim for reasonable quality, i.e. quality that can be achieved at small cost using existing tools.
- Learn to do things right the first time. Quality comes for free when it is embedded in everyday routine.
- Use tools to pinpoint issues instead of using exhaustive or binary search through code. For example, use stack traces for crashes, analytics for usability, profilers for performance, and high-efficiency security measures. Develop internal visibility & pinpointing tools for application-specific issues.
- Publish everything ASAP. Potentially deliverable code doesn't count as published, because it wasn't tested in production. Insist on full cycle testing all the way down to analytics and application metrics.
Coding:
- Mess slows people down and damages products, so keep the kitchen clean. Write clean code against proper abstractions representing domain vocabulary. Don't let complexity grow out of control.
- Automate everything. Software is pure capital that can be accumulated while operations are an ongoing cost that adds up. Automation also improves quality, increases flexibility, and speeds up work.
- Prefer opensource libraries over internal code. Handle poor fit by patching or supplementing opensource code instead of trying to compete with it. Avoid commercial libraries.
- Upgrade everything often, at least once per year. Seek new tools and learn about new features.
- Take a look at my recommended toolchain.
The list is far from exhaustive. There's an endless array of other things I might be doing wrong. I never know until the light bulb moment comes. There are tons of fast-cooking experts promoting their books and seminars who pretend to know what's killing you. At the very least, you are going to ask them for evidence, not plausible arguments, that proves their stuff works. But more importantly, you are going to check relevance to your case, because programmer productivity is a lot like software performance: there's bound to be some stupid performance bug that eats 99% of all resources.
Did you run yourself under profiler recently?