Software developer work day productivity: Is there an ideal code editor usage percentage? [closed]

Question

Due to the COVID-19 pandemic, most IT firms have started a work-from-home practice. To track their employees' work, they are using various time tracking software.

Our company (which provides services on wide range of software technologies) has issued new outrageous guidelines for software developers. Among various points, one of the major points states that the amount of time they spend in code editors shows the level of productivity. It is expected that they spend not more than 1-2 hours of their 9 hour shift in Skype, emails and browsers. The rest of the time should be in code editors with another line specifically saying that more usage of Skype shows lack of planning and documentation.

So, I want to know if the above assumptions and understanding of the company are correct at any level.

Do productive software developers/coders spend around 70-80% of their work time in code editors?

Is it a correct basis to calculate the work-time or mark their attendance on the basis of above mentioned factors?

(My opinion: As a web developer myself, I find these guidelines completely incorrect and insane. Having a common expectation from everyone irrespective of the type of project and the client they are handling is unjustifiable. It shows the lack of understanding of the organization's upper management of their own services and work flow. But, I would like to know the opinion of expert developers from around the globe present on this platform.)

To be clear: the guidelines states: this application usage tracking won't be the basis to cut our hours/attendance "as of yet".

Answer 1

It's like the old joke about the mathematician and the engineer. What's the difference? A mathematician works with pencil and paper. The engineer works with pencil, paper, and a trash bin.

It's conceivably possible for developers to spend 80% of their time cutting code, if they have clear specifications that they understand completely, and if they are developing new "greenfield" software. In other words, if they believe they never make mistakes.

It seems unlikely those conditions would always hold. If they don't, there are plenty of reasons for developers to use other programs than Visual Studio, Eclipse, or even Notepad.

• Email / chat: obtaining clarifications on specifications, asking questions of one another.
• Web browsers: for web developers, testing their applications.
• Web browsers: for all developers, working with ticketing systems and GitHub-style code repositories.
• Web browsers: for all developers, consulting documentation.
• The system being developed: non-web developers

Your managers are being forced to change their thinking about supervision because people have to work remotely. They come from a mindset where people aren't working unless they are at their desk with heads down. Hence, they want some kind of metric for that, and they've chosen time-in-editor.

Do you want them to adopt better metrics? If so, you and your co-workers will have to make the case for the change. You have a good opportunity to do that: They have said they won't yet punish you (by paying for less work) for not following the 80%-editor metric.

Your best case can be made by showing you're just as productive -- you finish just as much work -- at home as you do in the office. Then maybe they will just trust you. (Yeah, right.) Failing that, they can look at your actual activity and learn something about how you do your work.

Obviously, if some of your co-workers slack off it will undermine your effort to make the case.

Be patient: changing attitudes is hard work (harder than development).

Good luck. And thanks for keeping at work during this horrible epidemic.

Get your boss a copy of Fred Brooks' old but still relevant book The Mythical Man-Month. And, maybe, read it yourself.

Answer 2

Is it a correct basis to calculate the work-time or mark their attendance on the basis of above mentioned factors?

No, it isn't. But you're not in charge.

Answer 3

They aren’t correct, but this is fairly easy to game

I don’t think you will find anyone on here who agrees with how they are measuring productivity. However, if management were consistently intelligent in evaluating people, we wouldn’t have many questions on here, would we?

I would be inclined to game the system. I would never leave my IDE during the workday and find various workarounds for doing the same thing, just in an untrackable way. My experience with time tracking software is that it mostly cares about the active window on a machine, and/or whether there is periodic input into that active window, as it can’t tell whether you are achieving anything in that window. Others also have video tracking, but “I was thinking” is a very valid excuse and if they actually insist you churn out code every minute of every day, here is a link that can help:

https://ca.indeed.com/m/jobs?sameQ=1&radius=25&q=Software+Developer&l=&from=searchOnSerp

1. You will want a full featured IDE. An IDE can prevent lots of Googling for little things. Instead of searching documentation for something, you can read through the names of functions when autocomplete gives you some options. You will lose out on a lot of best practice, but management evidently doesn’t value that. This metric is also going to punish any dev who prefers a text editor or uses a command-line git client, as I suspect using other tools is going to be under "other" rather than under "editor." A full-featured IDE also allows viewing images, so instead of reading a requirement in your bug tracker, you could take a screenshot, open it in your IDE as an image, and comply with the rules that way. You have a PDF of documentation to read? Run it through a PDF to jpg converter and read it in your IDE.

2. You will want a 2nd computer. Time tracking software rests on the assumption that you can’t go and do another thing after clicking your button every 10 or so minutes. Having another computer allows you to go on Stack Overflow without seemingly ever leaving your IDE. If my management did this, I would set up one of my monitors to run on my Mac full time and use the Mac for Google and use my main laptop for the actual work.

Doing this, you could probably achieve 90% IDE time without really changing how you do development.

I wouldn’t be happy with this setup, but it’s the kind of stupid management initiative where the solution isn’t overly onerous, just somewhat irritating.

the guidelines states: this application usage tracking won't be the basis to cut our hours/attendance "as of yet".

This line makes me think layoffs are coming, so that is why I would roll over so easily and focus on meeting the metric.

Answer 4

Think about the things that need to happen as part of software development. Analyzing and understanding user needs and expectations. Decomposing requirements into units of work. Coming up with or making modifications to an architecture or design to support user needs. Documenting the architecture and design of the software. Writing code, including test code. Manual testing. Collaborative working. Peer review. Learning - reading existing system documentation, tool or technology documentation, prototyping.

Of these, only a few are going to be done inside of a code editor. Writing code and automated tests and creating prototypes will definitely be in an editor of some kind. Reading existing code for the system you are developing may be done inside of your editor, but it could also be done through a web interface to your source code repository. Code reviews, depending on your process and tooling, may be performed in your editor but will likely be done through a different tool.

I don't write (much) code at work anymore, but when I did, the vast majority of my time was not in my code editor. And even if my code editor was open, I may have been multitasking with other things open - an issue tracker, a wiki, a web browser for accessing documentation. Since I worked on a web application, I would also use a web browser to access my local development or one of the dev or test servers running a version of the application. With remote sessions, the use of tools like Skype and Slack to pair program via screen sharing is also going to increase.

Another thing to consider is that there are some numbers floating around (I wish I could cite a single, reputable source) about productive time being around 60%. That means in a 9-hour workday, you would expect to have a productive work time of around 5-5.5 hours. Highly optimized organizations may do better than 60%. Even if the assumption that a developer is only productive when in an editor holds true, 7 or 8 hours of a 9-hour shift would be a productivity time of over 78%.

Given the nature of software development, I can't see how it can be reasonable to make assumptions around productivity. Few, if any, people or organizations reach productivity of 78% or better during a workday. Even if you were, the use of an editor is not a good measure of software developer productivity as there are a large number of tasks that aren't done within the editor.

Answer 5

Whenever management wants to do something like this, they should always ask themselves: what am I incentivizing the employees out of?

In this case... you might have a developer that has a problem which they could probably solve in 20 minutes by some googling... but why? They're going to get dinged on performance. Better to spend 4 hours bashing a head into a wall and trying random stuff until it works. Or maybe you might have a developer that's not quite sure what they need to be doing with some facet of their current project. They could schedule a skype meeting and figure do a quick sit-down... except that's going to count against their performance metric. Better just bang something out and hope it's what's wanted - sure, it might result in a lot of wasted work... but that's wasted work in an IDE that doesn't count against me. Etc, etc.

Management actually put me in a similar position years back:

"Kevin, for your performance review, I had to dock you for the excessive web usage you had over the last 6 months."

"Wait, what?"

"Yeah, you were browsing the web an hour more per day than the department average."

"Yeah - that's because I was deep in the weeds trying to figure out how to write the extension button for the Thunderbird email client. It's a mix of Java - a language I don't really know - and a proprietary set of commands that don't have a good reference page. There were weeks where I was literally putzing around code sample sites for most of the day trying to cobble together commands and getting that thing working."

"You're saying that all of your web browsing was work related?"

"The vast majority. I mean, I may have visited a non-work site occasionally - but bring up the list of sites I was on. I bet google, stackoverflow, and the Thunderbird Chrome Language board are the three biggest sites."

"... well, given that you're acknowledging that some of this excessive browsing is personal, I'm letting the 'Needs Improvement' stand."

Now... care to guess how eager I was to do that sort of programming in the future? I mean, before I jumped at the chance to develop a key program in a new and exciting environment/language. Wanna guess how many projects like that I volunteered myself for in the future? Wanna guess how many times I'd volunteer for the difficult/impossible problems that I didn't already have a very good idea how to solve?

When in any position of authority, always ask yourself: what behaviors is this going to incentivize/drive?

Answer 6

I don't want to repeat what has been said in all the other answers, so I will leave it at that: that metric is ridiculous.

You are a software developer, not a typist. As a software developer, you are what is called a knowledge worker, you are being paid to think, you are being paid for your creativity, you are being paid for your knowledge, you are being paid for your experience, you are being paid for your expertise. You are not being paid for typing.

The time you spend typing into your editor is precisely the time that you are not doing any of the things you are being paid for. Your job is to spend a lot of time thinking so that you can solve the problem with the simplest, shortest code possible.

If you spend 70%-80% of your time coding, that means you only spend at a maximum 20%-30% of your time problem solving. Actually, it is much less than that, because you also have things like meetings, scheduling, team communications, reports, and … yes … time tracking to do during your work hours, plus all the project-related stuff that is not coding or problem-solving (trying to get a hold of the customer to clarify a requirement, for example).

If you spend most of your time coding, and no time thinking, it means that you are solving trivial problems. Statistically, it is highly likely that this same trivial problem has already been encountered by someone else, and that there is a ready-made solution for it. So, you should not be solving this trivial problem but instead use the existing solution.

You should be solving the hard problems, but those require a lot more time thinking than coding.

Answer 7

Is there an ideal code editor usage percentage?

No, there is not.

Do productive software developers/coders spend around 70-80% of their work time in code editors?

Not in general, but some likely will match that number at least sometimes.

Is it a correct basis to calculate the work-time or mark their attendance on the basis of above mentioned factors?

Nope.

Why is there no ideal code editor usage percentage?

Because

1. everyone is different
2. everyone's work pile is different
3. everyone's work pile contains different items from day to day
4. everyone's environment is different

For 1) I sometimes love to work with a black board to come up with algorithms. That works for me nicely. Some other colleagues rather try out coding prototypes until one works. One coder looks at the DB via the code editor the other uses a command line db client. -> Differences in average code editor usage.

For 2) A senior developer might do more high level design and a junior more small tasks that are straightforward. One developer might do some DevOps task and write scripts in a text editor or coordinate software rollouts with another department. → differences in editor usage.

For 3) Monday everyone might be coding at the next release version, when suddenly during the night, servers with the old version crash due to a memory bug. Next day everyone jumps onto the log files, looks through database entries, hooks up debuggers or drives to the data centre to take a look at the cabling (or calls them). → Huge variation in code editor usage.

For 4) One colleague might work in a home office, and the others in the real office. The real office people can talk without switching the context on their PC, and the home office colleague needs to spin up a messenger. Or one colleague might have two monitors while another has one in his home office. The two-monitor person can leave the requirements open on his second screen, and the one monitor person needs to constantly switch. -> different code editor usage.

Bottom line: Unless you have a very strict assembly line development process, where every coder is supposed to work the same way, has the same kind of tasks every day and has the same setup and tools (without choice) as everyone else, there is no such universal truth. And no development process I've encountered so far was that "industrialized" - if it were, I'd not call it software engineering but software assembly - and it probably should be automated by then.

Now, on the other hand. If you want to code, at some point you need to edit the code in some way. So if you make the measure broad enough and count any editor in that could be used and pick the number low enough, then you can determine a minimal number like 10% a week that securely covers all successful coders (that are paid to develop software rather than do some other tasks). At that point it obviously gets quite meaningless - i.e. someone who slacks off so much they would be detected by that measure, should in any functioning company be detected much earlier by other means (e.g. by not having anything meaningful to say in a daily standup meeting for days).

Now there is a gray area in-between where you can use such a metric as an indicator, with other metrics to see whether someone needs support. But that is another ball park entirely of aiming for a perfect usage percentage. And again, there would be other metrics that cover the same cases without giving employees the feeling to be monitored and not trusted.

Therefore, your real question should not be "is there such a number?". Your real question should be "How do I get management to back the fuck off trying to manage me like a line worker that only works when being strictly monitored?" *

Or more nicely, how to get management to see that this measure is not helping anyone, but destroying self-determined work and thus personal work investment along with any good will and trust.

_{* Note that these are two separated parts: 1) being treated as a line worker 2) that is lazy when not monitored → i.e. I'm not saying every line worker needs monitoring either.}

Answer 8

So, I want to know if the above assumptions and understanding of the company are correct at any level.

Do productive software developers/coders spend around 70-80% of their work time in code editors?

Is it a correct basis to calculate the work-time or mark their attendance on the basis of above mentioned factors?

Every company gets to make their own assumptions and judge developers on any basis they choose... no matter how ridiculous they are.

As I'm sure you already know, there's no factual basis behind any of their assumptions.

Answer 9

Whoever came up with that metric does not know the work you do to the level of such micromanagement.

These measurements may be useful if you have a baseline to work from. If when working at the office, time at the editor was between 75-85%, it makes sense to expect that same ratio, and take notice if there was a drop for a single employee.

Assuming everything else to stay the same: the employees are not asked to take more responsibilities, the specifications are not less defined now since the client is now providing them differently, etc.

Heh, I would probably not know the right percentage either. I would estimate that on my coding work, I spend more time at a console or web browser than at an editor (albeit recently I'm not developing large features). Specially, when you are chasing one of those hard-to-find bugs you could spend hours on a single defect! (but you may do the other 80% in the 20% left). And this not even taking into account the time spent on building the system, something you should do very often. Programmers don't work in a vacuum, and write a program from begin to end, and with no errors. Just like a writer won't write your novel straight ahead from begin to end. (It may be done by bright people if the novel/code is short enough. The point stands, though.)

Another point would be the amount of that is being required by your bosses. How are they keeping updated with the team members? Just that may already burn that hour that the employee may use for "not using a code editor". And that's not even considering that you were using an agile method like scrum! (hint: if tying people to their code editors was the best way to have employees produce value for the company, these methodologies wouldn't be successful)

It's also interesting how they would expect you to test the code or document its use. Is it the role of your QA team? Great. This guideline means you can pass them completely untested code, that may not even run. Please ask them to return the backtrace in a .c file, so you can read it on your code editor. Hardly a gain for your company, though.

In addition to all of these, an interesting point is that

specifically saying that more usage of Skype shows lack of planning and documentation.

I would expect the planning to be done by the management, and that the documentation to be the client specification. So, if you need to use Skype a lot, are they going to punish your boss for bad planning? Even if the product delivery is on time? What if the client can't make up his mind and is changing his requisites constantly? How are they going to account for problematic clients when assessing their developers' productivity?

Answer 10

As all the other Posts mention, the proposed metrics do not hold any water.

I won´t repeat what the other have said but elaborate on a few points not covered.

1. I don´t think its entirely unreasonable for someone who pays you to do something if they want to have some metric for the quality and quantity with which you deliver.
2. With any new metric introduced, the process should be:
   • First: measure where you are at over a representative amount of time
   • Second: try to understand the numbers you get. How do they fluctuate. What do they really tell and what do they hide. Is there a sensible and realistic goal to be set here?
   • Discuss the numbers and agree to goals with your employees.
   • Regularly give feedback and control if the goals still serve the purpose

Otherwise, if you rush it, you just risk to steer you employees in the wrong direction. Instead of aligning them more with the business goals, you get them to cheat metric or deliver less optimal performance to rest the metric.

Even if this is just a ploy to get some paper trail for cutting your hours later, chance are if this happens on the wrong/ill understood metrics it harms to the organisation because the wrong people will get hours cut.

3. There is actually a lot of material out there on how to mange and keep track of developers productivity. One way I found particularly sensible is "velocity". Note that this is not intended to measure individual performance but get an estimate of the teams rate of progress. In times like these you could easily see, after a few weeks of home office, if the teams velocity has dropped significantly. Then would be the time to talk to them and see what you can do to enable them to become as productive as before, again.

So what could you actually do, other than buckle down and/or fake it?

You could write an e-mail to the manager in charge (and only him, you dont want him feeling exposed and get defensive). It should consist of 3 parts.

A. Express you understanding and support of their goal. Make it clear that you are on board with the general idea and you will support any initiatives that promise to make the business more successful.

B. Express the risks the current approaches will carry. Beware not to be dismissive of the idea, but be sure to highlight the cost this could carry for the organisation. The google something in 5 minutes vs figure it out yourself in the code-editor in 2 hours is a good example to highlight perceived metrics vs. productiveness.

C. Propose a different approach. Nobody likes nay-Sayers. If you have nothing better to offer you can just as well keep quiet.