Minimal Effort != Laziness

“Minimal Effort” has become my catch-phrase in recent years, it is a bit of an oxymoron, but don’t think for a moment that I’m talking about being lazy.
For years I’ve heard developers (mostly students) saying that “A lazy developer is an efficient developer”, but I strongly disagree.

A lazy developer makes mistakes.
A lazy developer doesn’t clean up after them selves.
A lazy developer doesn’t keep tests up to date.
A lazy developer saves money in the short term, but will cost more in the long term.

So I updated this statement to “Minimal Effort”.

• Minimal Effort for the User:
  – They should be able to use your tools without ever needing to read documentation (Advanced/Edge-case workflows excluded)
  – They should be able to get from point A to point B without going through panel after panel, menu after menu.
  – In short, they shouldn’t even realize they are using their tool, they are only thinking about what they are working on.
• Minimal Effort for the Developer:
  – Don’t go building tools or workflows no-one asked for, it adds complexity and maintenance costs
  – Write tests that are concise and test actual data. No-one wants to wait hours for tests to run on fake datasets that no longer map to production datasets simply because you were too lazy to sanitize data.
  – Write refactorable code, while it’s important to leave room for discussed features needed at a later date, trying to account for unknown changes just makes clutter and you will probably have to rewrite it anyway to accommodate it. (Exception for intended plugin based workflows)
• Minimal Effort for your Team:
  – Your code must be well documented, not just each function but the workflows and data flow. This saves time not only explaining how it works over and over again, but ensures future developers are in the correct mindset when extending or refactoring your code.
  – Your code must be well tested, this is less about coverage and more about intentional workflow tests, this will ensure that future developers do not break existing workflows when making changes. Workflow tests also serve as a great reference point outside of documentation for how to use your code.
• Minimal Effort for your Manager:
  – Keep your tasks up to date!
  – Did you split it to subtasks?
  – Did you update time estimates when requirements change?
  – Did you Inform them when your task is blocked?
  Your managers time is limited, you know everything about your tasks and the easier you make it for them, the more time they can spend liaising with the clients and higher ups and the more time you can spend working instead of being stuck in lengthy update meetings.

So you see that Minimal Effort is about reducing the work for everyone in the process and streamlining the experience, not just yourself. Be a minimal effort team member.

Of course this is just an ideal, realistically timeline pressures and impatient clients often get in the way of this, but where possible it is good to stick to writing the best code you can for the minimal amount of effort.

Regards,
Mr MinimalEffort.