We are in an era where people are able to contribute value to a geographical location (on a daily basis) without being physically present in that location, I don't think we get how massive this is so I'll put this into context.
Imagine if the wait staff that attend to you whenever you visit your favourite restaurant, the pub, or Starbucks isn't physically in the building with you but is somehow able to magically hand you your order every single time π².
A Relatable Explanation
Programming, along with some other jobs has been separated from an office building in the sense that one is able to do these jobs remotely. While debate rages on whether or not working remotely is truly efficient, the fact is people are able to contribute value to a geographical location without having to physically be there.
A lot of the solutions we use are built by people who have probably never been to our locality, nor will they ever visit, yet here we are, leveraging these tools on a daily basis without a care in the world π .
It's not all rainbows and sunshine with remote work, as some information has come to light that maybe remote work isn't for everyone. Some organizations that implement remote work, however, have some tools in place to ensure everyone is productive.
Measuring Productivity
Some of the tools measure the productivity of professionals and score productivity on a number of parameters (that I won't get into today π€§). The crux of this article is aimed at assessing if these tools aren't a problem-solution mismatch. As always, I'll focus more on software engineering in driving this article home.
The short story is that these tools can result in a cobra effect as it has been documented that some employees simply play to the metrics of the tracking tool(s) rather than create actual value through the work they're paid to do.
There are many tools that promise employers the ability to properly track and monitor the productivity of software engineers, and frankly, they either drastically underreport the productivity of software engineers, are easy to deceive, or they absolutely don't work.
The Stereotype That Compromises Measurement Accuracy
There seems to be a bit of misconception about what programmers do, movies have helped create the stereotype that software engineers are typically typing at lightning speed on keyboards while instantly solving problems and hacking systems π. The truth is that most of our time (while working) is spent reading and not writing code.
If you have a challenging enough task as a software engineer, you'll spend quite some time researching solutions, reading documentation, or reading about how other developers solved that problem.
The time taken to write a solution to a problem may be 30 minutes, but the research that goes into knowing what to write in the first place can take 30 hours (and I'm not exaggerating π). The truth is we software engineers don't always have it all figured out and that's ok.
A personal case study will be the fact that I spent over 28 hours between Saturday and Sunday on a challenge, and a tool I used to track my code productivity reported that I spent 8 hours and 54 minutes coding π.
Now you may ask where the other 19 hours and 6 minutes went to π, well they were spent reading other people's code, reading documentation, and researching ways to solve the personal problem (PS the problem isn't solved yet π£, but I will figure it out eventually... I think π€§).
A lot of solutions that track productivity look at key logs, keystroke, and possibly mouse activity (within an application like an IDE or VPC) to determine how active a developer is, others (that are easier to deceive than the former methodπ) monitor screentime as a measure of productivity.
I think we can both tell by now that none of these methods will actually work in the event that a developer wants to sabotage the accuracy of these monitoring tools.
Finally...
There is no alternative to hiring professionals that you can trust to be fair and passionate about doing their jobs regardless of whether they're working remotely or from the office.
It is important to note that the most obvious way to assess the productivity of software engineers is based on the completion of the task handed to them (as long as the timeline is reasonable).
Software engineers aren't security personnel, whose physical presence alone is a form of value addition, as their mere presence provides deterrence and fuels a sense of safety. Those who choose to remain inflexible are and will continue to suffer from the effect of quiet quitting and high staff turnover which for me is a double jeopardy π .