I don't mind if you do the right thing for the wrong reason, but please don't do anything only for the sake of productivity.
I have seen so many posts coaching about productivity, and it often reminds me of this sign: "Coffee - do stupid things faster with more energy".
What is productivity anyway? What does being productive even mean and how would you measure success and performance based on productivity?
Being Busy === Business ?
Working in an office and getting paid either by the time you are present and sit in front of your keyboard, or by any quantitative measure - lines of code, number of commits, number of tickets solved, scrum sprint velocity - tends people do appear busy all of the time.
So we're good and valuable employees (or freelancers) if we manage to deliver the required features in time.
Efficiency !== Effectiveness
If our boss or customers orders features than don't deliver any useful business value, no matter how effective our work, the result still won't help their business perform.
Cartoon showing a business meeting in front of a burning flipchart. Manager says: I said I'd like to see the Burndown Chart, not burn down the chart!!! (Source: Modern Analyst Media)
As developers, we are usually no experts when it comes to their business, so working effectively according to the requirements is the best that we can do.
Being a Professional Web Developer
But especially when it comes to web development, often we do have expertise, and we know that some of their fancy wishes might not make it easier or more fun for their customers to use their products. Maybe we should speak up because we care, but often our customers and managers have reasons to stick to their requirements, and sometimes it even helps them make money while deceiving their end users.
Will AI ever replace Human Intelligence?
If we only strive to get more effective in doing what we do, then we might indeed get replaced by machines in the future. But not as long "teigtaschen" (dumplings) get lost in translation:
If you think a machine will ever take your job, have a look at the current state of "artificial intelligence". Sometimes even Google translate doesn't have a clue, as we can see in the screenshot above. You can pick some helpful tools like code completion suggestions, error checking etc. but how would a machine ever understand human requirements when even most humans fail to understand human requirements, and many don't even know what they want.
Dare to ask what they really need
After many years of watching software trends come and go, at least we have learned to think, learned to learn, and learned to discuss our work. So, unlike machines, we can talk to our customers and coworkers to understand what they actually want. And maybe, as senior developers, we might even dare to tell (or ask) that what we think they might actually need.
In the film Soul Kitchen, a chef loses their job after refusing to serve the guest a hot Guacamole, insisting that Guacamole is an Andalusian specialty that must be served cold. Finding himself without employment turns out to be the starting point for opening his own business which then then becomes the most innovative place to go.
I like to keep learning, and I even believe that there are some real best practices in web development. But yesterday's best practice might be obsolete and deprecated tomorrow, and the right solution for my project could be the wrong solution for yours.
A best practice can be something that many developers agree upon, and as a professional I should know those best practices and follow them unless I have a good reason not to do so. Besides some agreements about coding styles (like PSR for PHP, eslint-config-recommended for ECMAScript / JavaScript, and stylelint-config-recommended for CSS) that can help to avoid certain tricky pitfalls causing errors, there are other agreements that even became laws or industry standards.
Best Practices that made it into Law
Accessibility, a specific aspect of usability, has been specified and made it into law at least in several parts of the world. WCAG 2.0 is the current official best practice to make sure that a website is accessible to users with certain kinds of impairments like not being able to see.
Rant Time
Why would I mention accessibility legislation in a post about misunderstood productivity? Well, I often heard project managers tell me that accessibility is no priority for the stakeholders and that developers should rather focus on providing new features quickly without questioning the requirements. And without bothering to write automated tests or "waste" their time checking if there is a tool to compare feature branch screenshots to the Figma designs or how to automate testing cross device in different browsers including old iPhones that don't ever get the latest Safari browser.
Back to the subject: what is productivity and what the heck do I mean when I talk about "productive procrastination"?
Inside the Mind of a Master Procrastinator
Tim Urban: Inside the mind of a master procrastinator | TED
In his inspiring TED talk "Inside the mind of a master procrastinator", Tim Urban tells about his own procrastination problems as a student in a stand-up comedy style, showing strategies against procrastination and starts questioning the myth of productivity.
Nap Working
Another, even more inspiring talk, that I saw at beyond tellerrand conference, dorobot talked about how "nap working" has made her more productive, and how hard it can be to admit taking a nap in the afternoon.
Productive Procrastination
Let me conclude what productive procrastination means to me.
Stop wasting time for apparent productivity that might make us do stupid things effectively without providing actual value to anyone.
Productive, positive procrastination in practice: ideas, inspiration, contacts, networking, valuable side projects like my Cute Pink Light Theme for IntelliJ, and, last but not least, my DEV blog series. Don't mind "wasting" time, don't mind getting bored, be patient, stay curious, keep an open mind.
Originally posted at Open Mind Culture blog, also available in German: Produktive Prokrastination.
Top comments (2)
Very well written and important article, thank you for this!
I also think that neglecting the "why" can be very harmful to the product. We as devs need to be active, but it can often generate frustrations for people working on the conception and the design. I imagine a well thought-through (albeit, for the sake of the argument, unnecessary) feature people spent werks on refining. When it comes to implementation, probably the last thing you want as a UX or business expert is a technician, who only learned about the feature moments ago, questioning all of your work.
I also remember reading an article ages ago that quoted a atudy about how different levels of detailing in prototypes made people question different things. If the design is already pixel-perfect, people might question if a button should be primary or secondary, whereas a lo-fi wireframe made people question the existence of the button. And that effect also very much takes place when it comes to implementation: an early idea is questioned on a more fundamental level than a very detailed ticket that covers every single edge case.
I think for people uncomfortable with asking "why" for whatever reason, both of these points further inhibit progress towards building the right thing. A more sustainable approach would be to advocate for early involvement in the process.
Further reading about how incentivizing based on quantity might have undesirable effects: "stop rewarding quantity"
Stop rewarding quantity!
Ingo Steinke ・ Jan 17 ・ 5 min read