iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Small habits can make development work feel smoother, but no study establishes five universal actions that instantly make developers faster. The most defensible place to start is reducing avoidable friction while protecting code quality: clarify why a change exists, limit needless task switching, and keep relevant code changes visible. The five practices below are practical options, not a ranked or scientifically proven formula; choose the ones that address friction in your own workflow.
What does “faster” mean for a developer?
Speed is not just how quickly code is typed or how busy a workday feels. Software development is complex and creative, so productivity is difficult to capture in a single measure. A useful assessment separates perceived speed from correctness, maintainability, and completed work. Google’s human-centered productivity research argues for treating developer productivity as a broader, multidimensional subject rather than reducing it to one metric: Google Research’s human-centered approach.
Code quality is one worthwhile focus. Google’s 2022 study summary says increases in perceived code quality tended to be followed by increases in perceived developer productivity; this is an observed relationship, not proof that any particular habit causes faster work. The summary describes an initial analysis of 39 productivity factors using panel data: What Improves Developer Productivity at Google? Code Quality.
Five micro-habits to try
These habits respond to common workflow frictions. They are practical suggestions informed by those frictions, not habits tested or ranked by the studies below. Start with the one that fits a recurring problem on your team, then evaluate its effect on work as well as on how fast you feel.
1. Record the reason for a change
When you touch code, leave a concise note explaining why the change is needed and what constraint or behavior matters. Depending on your team’s conventions, that might belong in a pull-request description, issue, commit message, or a comment where the rationale would otherwise be hard to recover. Keep it specific: describe the problem and intent, not a restatement of what the code visibly does.
This can make later debugging or review less dependent on rediscovering context. Microsoft Research’s October 2005 survey reported that 66% of surveyed developers identified understanding the rationale behind code as a problem. That figure is historical and should not be read as a current estimate for developers generally: Software Development at Microsoft Observed.
2. Make the next task explicit before switching
When an interruption requires you to leave a task, write down the next concrete action and any essential state you will need to resume: the failing test, relevant file, open question, or command you were about to run. A short handoff to your future self is often more useful than a long activity log.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Microsoft’s 2005 survey reported that 62% of respondents identified frequent task switching prompted by teammate or manager requests as a problem. It is a dated finding about that survey, not a current population statistic. A separate observational study summarized in a 2014 paper followed 11 developers at three companies for four hours each and recorded 2,650 log entries. Its findings show that substantial switching can coexist with developers’ perception that they are productive; they do not establish that switching has the same effect on every developer or that this habit causes a productivity gain: The Work Life of Developers: Activities, Switches and Perceived Productivity.
Rank #3
3. Check for relevant changes before building on code
Before you rely on a shared module, interface, or branch, check the team’s normal source-control and communication channels for changes that could affect your work. For example, inspect the current branch or recent relevant commits before debugging behavior that may already have changed. Use the team’s established process rather than adding extra notifications or checks that create noise.
In Microsoft Research’s October 2005 survey, 61% of respondents identified awareness of changes to code elsewhere that affected their own code as a problem. The figure describes respondents in that study, not today’s developers as a whole.
4. Keep a small, repeatable quality check near the change
After a focused code change, run the narrowest relevant automated test or check your project supports, then broaden the check when the risk or team convention calls for it. A repeatable check can expose regressions sooner than relying only on a sense that the code looks right. Keep the scope proportionate: a small local check should not replace the project’s required test suite, review, or release process.
This habit is a practical way to pay attention to code quality, not a guarantee of correctness or speed. Google’s reported relationship between perceived code quality and perceived productivity supports taking quality seriously, but does not identify this specific practice as a cause.
Best Value
5. End a work session with a one-line restart cue
Before you stop or move to another task, write one sentence naming what is done and the next action. Include a link or identifier for the relevant issue or change when that is useful and appropriate. The goal is to make re-entry easier, not to create administrative paperwork; skip it when there is no meaningful context to preserve.
This overlaps with the task-switching note above, but serves a different moment: the first habit captures why code changed, while this one captures where to resume. Keep the cue brief enough that writing it does not become a task of its own.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to tell whether a habit is helping
Try one practice against a recurring friction before adopting a collection of new rituals. A reasonable check combines your own experience with outcomes that matter to the work. For example, note whether the habit reduced repeated investigation or made a handoff clearer, and look for signs such as reliable tests, less rework, or a completed change that meets its requirements.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →- Match the habit to the friction: use rationale notes for missing context, a restart cue for interruptions, and change checks for coordination gaps.
- Fit the team’s workflow: put information where teammates already look for it and follow existing review, source-control, and testing conventions.
- Check more than perceived speed: a task may feel quicker while creating defects or maintenance work; consider quality and completion too.
These comparison factors are a practical framework, not a tested ranking of habits. Google’s broader work on measuring developer productivity explains why outcomes and human experience both matter: What Predicts Software Developers’ Productivity?.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
