After Covid-19, are programmers entitled to work from home?

Michael C. Daconta
5 min readJul 18, 2021

I know several young developers who have demanded a work-from-home arrangement from their company or else they will quit! According to numerous articles on the internet, they are not alone. Let’s examine the good and bad sides of this trend in relation to software engineering.

First, let’s consider the root cause: Covid-19 forced shutdowns moved many jobs to remote work. Millions of workers used the internet for online video conferencing, message groups, instant messaging, and other forms of online, cloud-based collaboration.

The Internet enabled remote work

As predicted in my last technical book, The Great Cloud migration, many companies accelerated their move to the cloud. The fact that billions of workers across the globe could successfully work from home is a striking technological achievement for the Internet and cloud-based computing. The technical industry should see this as a feather in their proverbial cap! Given that that such remote work was possible and companies continued to run (though some in diminished capacity), workers naturally believed that there was no difference between on-site and remote work. Thus, a feeling of entitlement emerged.

Is entitlement a form of laziness? Is this a poor work attitude that is the result of a “pampered class” or “snowflake” class of individuals? Is it a coincidence that the people I know that are demanding work-from-home are young? Or is this just capitalism at work in a surging economic environment where the workers are in the driver’s seat?

Specifically, entitlement is the expectation of the employee to control their work-life balance. This can be in the form of flex hours, working less than 40 hours a week, and recently in some amount of work-from-home. Given a taste of “more freedom” due to Covid, workers do not want to give that up. This is also a testament to how many people truly hate commuting. As a manager of employees in a congested area, I have witnessed many people change jobs simply to improve their morning commute.

Crowded commute

Programmers are even more prone to this feeling of entitlement since they spend all of their most productive time interacting with a computer in the “development cycle”. In my latest book, Lazy Programmers, I depicted my typical day in the figure below:

My development cycle

All of these steps in the cycle are performed on a computer, so I spend the super-majority of my day on the computer. Again, given that, it is natural to think that I can be extremely productive anywhere on the globe! Furthermore, there are numerous videos and stories of programmers working in remote places, even on boats! Thus, the entitlement of remote work is even stronger for technical workers.

Now, we are ready to get to the crux of the matter: is such entitlement a form of laziness and thus a detriment to employee productivity? To make such a judgment we must examine the negative side of remote work. Again, I will make this specific to the development process as that is what I manage and participate in on a daily basis. So, what do you miss when employees work remotely:

  • Serendipitous collaboration: many times in our office (which did zero remote work), collaboration is not planned. You are chatting with people, off-the-cuff, in the break room, in the hallway, and at the proverbial water cooler (or coffee pot).
  • Esprit de corps: the feeling of being “us” against the world, or “us” against failure, or “us” against all obstacles cannot be achieved over a video-chat. It just cannot. There is a human element to it of shared sacrifice — in the trenches, back-to-back, and in the fight. Remote work will never get us those things.
  • Close coordination: sometimes the actions of multiple teams must be coordinated in real time. For example, when solving an emergency bug discovered in a production release requires fast coordination among numerous groups. I need the A-team assembled immediately and I can’t wait to schedule things on people’s calendars. Do you want to be on the A-team or not? Do you know if you are on “the A-team”? Here is how you know — if the stuff hits the fan, are you on the team called in to fix it?
  • Constant mentoring: pre-covid I would routinely take walks with employees through the building corridors to discuss how things were going with their work, their career and even their life in general. Being a former military officer, counseling is part and parcel of a high-functioning team. Again, there is an element of face-to-face conversation or (management by walking around) that you lose with remote work.
  • A strong sense of mission: being a former military officer, I am always keenly focused on the mission that our software supports. I understand that software is often not the direct mission of the organization but software plays a “mission multiplier” role for the organization it supports. In other words, while a software engineer develops software it is not that direct activity that gives us purpose — purpose comes from how well we support the end-user’s mission. Sometimes this requires sacrifice on our part to deliver a high-quality product because we are keenly aware of how quality in our work product affects the ability of the end-user to get their job done. If a developer is focused on their work-life balance to the exclusion of the mission, I consider that person a “paycheck programmer”. In my book lazy programmers, I represented that type of person with the diagram below:
A paycheck programmer

It is the last bullet (a strong sense of mission) that I believe is the most serious. Additionally, I believe that so strongly, that I see it as the key reason a programmer (and actually any employee) should be willing to work on-site instead of working from home. If you have a strong sense of mission, you are more concerned with supporting that mission than the additional flexibility. For me, this is the tie-breaker and dictates what I would choose.

For programmers that are interested in being on the “A-Team”, interested in better team cohesion, and interested in the highest level of mission support — there is only one answer.

--

--

Michael C. Daconta

Software Engineering Professional and Well-known Author