Most Managers Have No Clue What Programmers Actually Do

I've been thinking a lot lately about 1.) the avalanche of layoffs happening across the tech industry, 2.) the current push to drive remote workers back into offices, and 3.) the latest hysteria around AI. While these issues have many different factors, I believe there's one common thread among them: Too many "dev managers" have little-to-no-clue what software engineers actually do.

Before I dive into the details, I'm gonna make one thing clear. For the sake of this article, when I say "dev manager", I'm gonna use the term in a very broad sense. Specifically, I'm using "dev manager" to refer to any corporate employee who's responsible for managing the output of a software developer - or an entire team of developers.

There are many different models for managing software development. Sometimes, your "dev manager" may be a technical coder like yourself. But it could also be an executive (e.g., CTO), project manager, product manager, business analyst - or... nearly any other title. But the longer I survive in this career field, the more I'm convinced that very few of them - regardless of title - ever understand the true nature of our work.

Counter-Intuitive

On the surface, this may sound like an odd premise. The question, "What does a software engineer do?" may seem like it has a simple (and obvious) answer: We write software! (Duhh...) But if you've been slinging code for more than a few years, you've probably noticed that a significant portion of every day is not spent in your IDE.

Meetings

First, there are usually many meetings that plague software engineers. Meetings within your team (e.g., standups, demos, code reviews). Meetings with management. Meetings with clients/stakeholders. Even meetings that have nothing to do with your core job function. (Like, "all-hands" meetings.)

I once had a job as an "IT Manager" for a large bank. I had a small team that handled the systems that managed the bank's public internet presence. My role was "hands on", and I was expected to contribute directly to development projects, while still handling the duties of a frontline manager.

One day I had meetings scheduled from 9AM-10AM, 11AM-Noon, 1PM-2PM, and 3PM-4PM. The next day, my director asked for an account of the team's progress from the previous day. After I brought him up to speed on what had been completed (and not completed), he asked me, "But what did you program yesterday??" I bluntly told him that I didn't get any programming done in the previous day, because I had four meetings scheduled. He then asked me, "But those meetings only took four hours. Why didn't you get any coding done in the other four hours?"

My director had no understanding of the fact that, with four meetings throughout the day, occurring every-other-hour, I had virtually no time to sit down and actually write code. Each meeting on my schedule required at least some degree of "prep work". And each meeting spawned a series of "take-aways" and follow-on communications that I needed to handle directly afterward. This meant that, at most, I had maybe 30 minutes to do any real coding between meetings - and for any kinda serious mental work, I just wasn't able to parachute into the middle of a task for 30 minutes and get anything meaningful accomplished.

Teamwork

Beyond the endless series of meetings present in most software jobs, there's usually some degree of "teamwork" that goes with the job. Maybe you need to help someone else troubleshoot an issue. Or maybe you need to help the new guy get up-to-speed. Or maybe you need to spend some time tweaking the deployment pipeline. Or maybe you need to review the pull requests of others. Or maybe you need to spend some time sifting through logs. Or... well, the list goes on and on.

Most of these "teamwork" tasks rarely result in a nice clean deliverable. They don't often satisfy a sprint task. They don't yield a new feature to make the client happy. They're usually best defined as grunt work. But that doesn't mean these tasks are unnecessary. In fact, if no one does them at all, the efficient operation of your team may grind to a halt.

Reading/Research/Grokking

Even when you're lucky enough to have your nose stuck in code, that doesn't necessarily mean that you're writing new code. There are many estimates floating around out there about the amount of time that a dev spends reading code versus writing code. And those estimates always conclude that reading code is a far bigger part of the job than actually writing code. Nevertheless, when you're reading code, you're rarely delivering anything tangible that a manager would quantify as progress.

Blind Management

The problem with all these "soft" tasks is that management is often blind to them. If you sit down and explain these tasks to them, they'll offer lip service as to their importance. They'll claim that they understand that there are many tasks in a developer's job that don't lead directly to deliverables - and then... they'll turn around in the same breath and ask, "But... you're gonna have those deliverables completed today, right???"

To be fair, this isn't necessarily an act of wanton, willful ignorance on their part. Of course they have deliverables that they need to ensure are completed on time. And of course they're gonna be heavily focused on those deliverables and their associated timelines. But sometimes it can be infuriating to witness the disconnect when you tell them that you had to unexpectedly burn a day standing up a new server - but they assume that the due dates will remain unaffected.

You see, here's a central problem of software development:

Those who are not directly involved in the writing of software find it extremely difficult to conceptualize the non-coding aspects of the job - or to account for them when managing expectations.

In theory, they know that there are many non-coding tasks involved in almost any software engineering milestone. However, in practice, they struggle to grasp what those tasks are, or how long they'll take.

Even when you go out of your way to brief them on all the non-coding tasks - even as the work is underway - they're still thinking in the very basic language of deliverables. Anything you must do that cannot be directly tied to a deliverable runs the risk of frustrating those who are managing software development efforts.

Beware the "Technical Manager"

It would seem that an easy solution to this problem is to ensure that those who are managing software engineers have an inherent understanding of the software engineering process itself. In other words, we can avoid these misunderstandings as long as the "dev managers" are people who used to be coders themselves... right???

Ummm...

While I've certainly had some bad experiences with non-technical managers, I have to say that I've also had some horrific encounters with managers who used to be coders themselves. This may sound bizarre. After all, if someone used to be writing code not-that-long-ago, then they should have an inherent understanding of all the "soft tasks" that go into a developer's typical day... right???

Ummm...

The problem is that, in many organizations, the "dev manager" is thrown into so many meetings, and spends so much time communicating with people outside the dev team, that they can scarcely keep eyes on the actual work taking place. They can get overwhelmed trying to keep tabs on the daily efforts of a half-dozen (or more) programmers. They rarely get time to peruse code on their own - or interface one-on-one with the developers. This means that, far too often, the dev manager ends up looking at the same basic "metrics" (deliverables & timelines) that would be used by any other manager with no direct programming knowledge.

Sometimes, the dev manager's technical knowledge can actually be a liability. Because they might remember what it took to do a particular task in the codebase when they were working on the code (often, years in the past). And it can be difficult for them to grok how the current state of the codebase has evolved (or... devolved).

[FUN SIDE NOTE: If you're ever in standup and you're tempted to say something like, "This task is taking a bit longer than expected because this particular section of code is a royal mess," you may wanna do a quick git blame on the code first and see who originally wrote it. It's entirely possible that it was written, years ago, by your dev manager. And some dev managers don't have the emotional maturity to handle comments like this very well.]

The Illusion of Accountability

It took me a long time to grasp these potential disconnects between me and my dev manager. Because modern processes of software engineering often feel as though they're inherently (even... copiously) documented. When I'm working on a task, the audit/accountability trail typically looks like this:

1. A task is assigned to me from some ticket management system (e.g., Jira). The task has all sorts of meta data about the task itself. Ideally, it has estimates and solid notes for exactly what's expected.
   

2. The coding aspects of the task are all encompassed in one-or-more commits. I place notes on each one of those commits (e.g., commit messages).
   

3. Throughout the coding process, I give daily verbal updates (usually, during standup) explaining my progress, and expected completion times.
   

4. The completed code also contains unit tests that go a long way toward describing exactly what the code is expected to do.
   

5. When I'm satisfied that the commits fulfill the requirements of the task, I submit a pull request. I usually add more notes on the pull request to aid other developers who are reviewing the code. If other devs have questions about anything I've done, they add their own notes to the pull request, sometimes leading to discussion that's recorded directly on the PR itself.
   

6. Once the code has been merged, I then add more notes in the task management system, in addition to updating the status of the ticket itself.
   

So by the time that I'm truly done with a task, I've added my own documentation to 1.) each individual commit, 2.) the PR that encompasses the changes, and 3.) the ticket that tracks the status of the changes. This is in addition to numerous daily verbal updates.

That feels like a lot of documentation for every single task, right? And with that level of documentation, there really shouldn't be any mystery on the part of my dev manager (or anyone else on the team) as to what I'm doing or why it took as long as it did... right???

Ummm...

Unfortunately, I've found that, far-too-often, my dev manager isn't taking the time to monitor any of these communication channels. They typically don't have the bandwidth to review commits or PRs. They often haven't read any documentation that I've added in the task management system. Hell... sometimes they weren't even listening when I gave my verbal updates during daily standups.

In other words, despite all of this status-tracking, I've run into situations, on multiple occasions, where my own dev manager wasn't aware of any of it. All they "hear" is 1.) Is the task done? and, 2.) If it's not done, when will it be done? Beyond those basic data points, the dev manager often has little-or-no-clue about what I (or anyone else on the team) is actually doing on a day-to-day basis.

Last year when I was working for Amazon, I had a dev manager who used to code. After I'd worked there for several months, he somehow got the impression that I was "falling behind". This was despite the fact that, by numerous metrics (e.g., commits, PRs, completed tasks, LoC), I was actually doing several times more work than anyone else on the team.

I was documenting the ever-loving hell outta everything I was doing. In commit messages, and PR messages, and in the ticket management system. But none of that mattered. Because my dev manager couldn't be bothered to actually read any of it. Even worse, I came to realize over time that, when I gave verbal updates on my work during standups, he wasn't even listening to those updates.

[NOTE: I'm fully aware that many metrics of programming "velocity" - like # of commits, # of PRs, etc. - are very poor measurements of productivity. I only bring them up here because, when your metrics are several times greater than anyone else on the team, it's borderline ludicrous to imply that you're somehow "falling behind".]

The Danger For Remote Workers

Remember, at the top of this article, how I mentioned this in relation to remote work? Well, here's where this gets really sticky for those who aren't in a traditional office space.

When you're sitting in someone's office, your dev manager may have little understanding of exactly what you're doing at any point in time. But there's an incredibly basic (and... ignorant) "metric" that many in-person managers use to "gauge" your efforts: They simple see you working.

As ridiculous as that sounds, the sad truth is that, for many managers, their primary "metric" for gauging your productivity is simply that they can walk by your desk and see that you're... umm, working? They may not be tied into the actual work you're doing. But at an extremely basic level, they can look up from their own desk and see that you're... typing? Coding?? Doing something???

You may be staring mindlessly at the code for hours. In fact, if they're not looking over your shoulder, they may not even know if you're even looking at the code at all. But they still get a warm-fuzzy just by knowing that you're sitting at your desk and ostensibly... working.

Sadly, remote workers do not enjoy this (extremely basic) "benefit of the doubt". If you're working remotely, and you're doing something that's not directly tied to a "hard" deliverable, it can be extremely difficult to keep your manager "in the know" about the fact that you're working hard and performing critical tasks. This can be true even when you're going out of your way to add all those little bits of documentation (on commits, and PRs, and tickets...) that are customary in almost all software teams.

So when the corporate big-wigs start fretting about last quarter's less-than-stellar results, and they begin reaching for solutions (any solutions), it's easy to target the remote workers. Because your dev manager may have little idea of what you're actually doing. (Or, in the most extreme cases, if you're actually doing anything at all.)

Joe, who sits in the corporate office all day and can be seen clacking away on his keyboard, is generally "safe" during these evaluations. It matters little that Joe may be a crappy developer. It matters little that he spawns tsunamis of bugs and reworks. All that does matter is that your dev manager, oblivious to the real work that goes into software engineering, can see that Joe is constantly working. Even though he's... not sure exactly what Joe's working on.

Layoff Liability

This same bias against remote workers plays out when it comes time to lower the axe. Management is almost always prone to jettison the remote workers first. (Or... they do a cowardly "soft layoff" by issuing a return-to-office mandate - knowing damn well that many of the remote workers will leave of their own accord.)

This happens because soooo many organizations have no clue how to monitor/measure what software engineers are actually doing. Granted, if you singlehandedly rewrote your team's core application, and you did it swiftly and free of bugs, then maybe your chain-of-command understands your worth to the organization. But if your recent tasks were more along the lines of those "soft" tasks - things like setting up servers or diving into error logs - then you may find that they're oblivious to your true value.

In those scenarios, they almost always give the benefit of the doubt to the guy who's actually sitting in their office. It doesn't matter if that guy sucks. They can see that he's working - and that's usually good enough for them.

It should also be noted that there's been many stories lately about remote workers who basically had nothing to do. (I'm casting a nasty glance at you, Meta.) And in those scenarios, that may sound like a damning statement on remote workers. But if a company hired a bunch of remote engineers, and then couldn't be bothered to keep them busy with critical tasks, whose fault is that exactly?

And why were these Big Tech companies needlessly hoarding programming talent that they couldn't even put to work? Because many of the managers in those companies never properly understood what software engineers do in the first place.

The AI Boogeyman

Finally, I'll mention that this inability (or unwillingness) to actually understand what software engineers do represents a short-term threat to developers. (And this is especially true of remote developers.)

No, I'm not claiming that AI is going to make your job obsolete. But I am claiming that, if your management doesn't fully appreciate what you do, it's far easier for them to imagine that you can be replaced (in part, or entirely) by AI tools.

Let me first put this in a historical perspective. I'm old enough to remember when outsourcing/offshoring was perceived as the biggest "threat" to software engineers. (At least, for those developers who were not living in a prime offshoring locale.) We now know how that played out.

Offshoring is definitely still "a thing". And it won't be going away any time soon. But many large development projects that were offshored decades ago ended up getting pulled back to their home bases. Why?? Because the executives who thought they could game the system by offshoring everything found that the results were often... appallingly underwhelming.

And why were those results so disappointing??? Because those executives didn't properly understand what software engineers actually DO in the first place. They saw development as some kind of assembly-line process that could be farmed out to the cheapest bidder. But those projects ended up taking far longer than expected. And even when they were delivered, the results were often suboptimal.

This occurred because quality in-house software engineers perform a whole range of critical tasks that go beyond simply receiving specs and cranking out the desired algorithms. They interview stakeholders. They architect robust solutions. They anticipate short-and-long-term hurdles. They don't just type out code in their IDEs. They solve problems.

Of course, there's absolutely a time-and-place for offshoring. And offshoring has settled into a valuable role for many corporations. But there are few organizations that can successfully manage an ongoing software development operation that is entirely offshored.

Unfortunately, I believe many of these same misguided strategies will play out with regard to AI. Yes, AI is a fabulous (and rapidly evolving) tool to enhance the productivity of savvy developers. Yes, AI's role in software engineering will almost-undoubtedly increase over time.

But before AI settles into an accepted role in corporate life, there will certainly be those who foolishly think that they can replace their engineering resources with ChatGPT. (Or any of the other evolving tools.) And this will probably play out this way because, to this day, there are still so many people who manage development projects, but fail to understand what their developers are actually doing.

In The Next Installment...

This article may be a bit, umm... depressing. But I don't mean it as such. In the next article, I'll propose some strategies that you can employ, as an individual developer, to try to mitigate these hurdles.

Stay tuned...