Always been curious how “workload” is assigned and estimated for software engineers.
In: 92
There’s no good way to do it, that people have figured out yet.
You can try to measure output in terms of some countable metrics, but these all have problems:
1. **Lines of Code** seems like something you could measure, but software *quality* isn’t the same thing as software *quantity.* In fact, there’s research to say that the number of bugs in code is directly proportional to the amount of lines of code, so if you use an unnecessarily large amount of code to solve a problem, you’re probably making things worse. As a general rule **Complexity must be justified*****.*** Writing more code than you need to, because you get punished if you don’t, is bad management and technical malfeasance.
2. **Number of Commits/Number of Completed Tickets**. Some work items are very complicated and require a lot more time. A person who only takes small, easy tickets and completes a lot of them is probably not as valuable to an organization as a person who takes the large, complicated tickets and completes those. In fact you might expect that the more experienced and higher-paid programmers probably focus on the later exclusively.
3. **Defects/Regressions.** In other words, is the person breaking things along the way? Are they creating more problems than they solve. A person who seems to get a large volume of work done (see #1 or #2) but they work they produce has lots of problems that require fixes/redeployments/rewriting/hotfixes/etc is probably more hinderance than help. But then again, as systems get larger and more complicated, it gets a lot harder and harder to change one thing without inadvertently causing changes somewhere else. Especially when there is time pressure.
A lot of it is unfortunately subjective. Does it feel to you like the programmer is dependable, reliable, efficient, proficient and competent? Does the work they produce meet the needs of the organization? My suggestion is that you sort of keep yourself aware of what’s going on (without watching over the shoulder, or micro-managing, of course) so that you can make these kinds of subjective judgement calls.
they aren’t, especially if you aren’t a man or white. bias in software engineering is a well-known issue, and many women end up doing a lot of the “glue work” to keep the team running (see https://noidea.dog/glue), get penalized for not being “technical enough”, and get undervalued as a result. many times people who are underrepresented in tech get worse/less visible responsibilities and then penalized for not doing challenging enough work. technical interviewing is also subject to bias; many interviewing techniques assume tons of free time (not good if you have a family or chronic illness) and a traditional college CS education. they’re also shown to induce stereotype threat in underrepresented groups and misjudge their performance anyway. of course, since people in this field pride themselves on being objective, they insist that they are being rational and selecting the best talent in ways that couldn’t possibly be biased. this is a lie.
tl;dr they aren’t unless you’re a white man lol
Generally the person assigning work is a senior developer of some description – that’s not necessarily their job title, but they’ll be an experienced developer themselves
Since they’re relatively experienced they have a rough idea of how long things take. They’ll also have a reasonably good idea which tasks are most at risk of delays and will endeavor to spread them around the team so that one person doesn’t get hit with them all and end up way behind schedule.
A good project manager will then add some slack to this timeline, and then the developers start the work
Then if it takes longer, the developer informs the project manager as soon it becomes likely and they adjust timescales, manage stakeholder expectations etc. if it’s faster, the developer just starts the next task early.
With experienced team members doing the assignments, managing expectations etc, it’s usually pretty smooth unless unrealistic expectations are being dictated from further up the tree
Either by asking you questions about coding that are hard to answer without several years experience or through a dumb test:
The industry picked a few small, easily memorised tasks that have nothing to do with the job you have to do and ask you to do one of them at an interview. It’s like doing 2 questions from a high school geography exam before being accepted as the civil engineer in charge of a huge bridge. Sure geography is slightly related, and if you studied it 8 years ago then the question will probably still be in your head, but it is a laughable proxy for the skills you will actually need.
Tasks include: implementation of an algorithm for shortest path, sorting a list of numbers, solving a logic puzzle or manipulating a data structure in a pointless way.
All of these are about high school level maths difficulty, have been done before and can easily be found online, but are impossible to complete in 8 minutes while the interviewer looks over your shoulder at every line you write unless you already know how. They will gladly fail you if you don’t finish the task even if you have a credible CV that marks you as a senior developer with a ton of experience building much more complicated systems.
In summary, they don’t, but if they do, they do it badly.
Largely engineers are measured on results, few people care if we are lazy or working 80 hours, results are that count.
This is an old school answer – I retired before so many of the methodologies mentioned here were in place. On large projects I worked on, people were assigned larger pieces and asked to estimate what it would take to do the work ( as opposed to current methods where small pieces are assigned and a team does a collaborative effort). Some people’s estimates were just awful, either because they wanted to look good at the start, wanted to fit in to what they thought others expected, or were just bad programmers. Some were spot on, within days on a year long project. Eventually, assuming a stable team, it became pretty clear how to weigh estimates. This was all product development, not time sensitive customer or contract work. [Warning: bitching ahead] Eventually, the whole industry changed, and specifically my company’s management changed and schedules became more important than quality. At that point, lots of those scheduling methodologies like “Agile” came in and just made the job harder. The bean counters, collaboration weenies, and micromanagers won and quality suffered. Glad I’m out.
It’s mostly based on our own estimates and how well we meet those estimates. But it’s also measured against our peers’ and leads’ estimates. If we consistently estimate higher than other coders (and we take longer than other coders) then we’re probably not being as productive. It’s tough though – one of the hardest things to learn as a software developer is how to give time estimates for something which you don’t know much about. Like – I’ll be asked to estimate how long it will take to add a feature to a program when it’s not a program I’ve ever worked with, it’s not a business process i’m familiar with, and it’s not a customer I’ve worked with before. This kind of thing, to some degree, happens frequently.
As a young coder you often start out making bad estimates, because you know what it’s like to do something from scratch so you use that as your basis. Maybe you need to add a field to a webpage – nothing complicated. So you say it’ll take half a day, figuring it should only take an hour so you’ve padded a full 3 extra hours in. But then you look and you find that the page is being automatically generated from some other code. And that code references a database view. And that view is a complex reference that filters out based on a myriad of factors. Plus the layout of the page is standardized using some templating, and changing the template to accommodate the new field will break other pages. And none of this is documented, in fact it took you two hours just to figure out what tables in what databases were involved, and whether or not you had the permissions. You’re also unsure which environment is right, the code points to (local) and the dev environment points to dev, but the test environment seems to point to both dev *and* test in different connections and the layout is entirely different. The code that’s in production doesn’t seem to match anything in the test environment or the dev environment. Now you’re 3 hours in and you haven’t even started adding the field.
Then you end up over-correcting. Suddenly your boss is worried why you think every minor change is going to take at least a week. You keep talking about “unknown unknowns” as though they’re the boogeyman. You question whether time is real.
Eventually you end up where I am now (I’m about 12-15 years in, depending on the measure) where you have a good sense of what the factors are that will go into the estimate – you can give me that same “add a field” scenario and I can tell you it’ll take me somewhere between 2 hours and 2 days, depending on what the code is like and whether there are unknown problems that need to be fixed first. Particularly cases where (and it happens more than it should) the code that’s deployed on production doesn’t match anything we have in source control and we’re going to need to reverse engineer it with a decompiler.
So as I get more experienced, my estimates get more realistic in both directions and they also are able to come with contingencies – I can tell you not only how long it’ll take but I can tell you why it could take longer, and when I’ll know how long it will take.
Very vaguely. Big problems are broken down into small pieces that one can hopefully get done in a few hours or days. But sometimes there is a big problem, and more time is needed.
In an Agile system coders are constantly estimating how long tasks will take and updating them with how long they actually took. From this you can make better estimates in theory. Managers can use those estimates to get a general idea of when bigger projects will be done.
Problem is, few people can plan ahead for the problem they did not think of. Development is one long string of problems.
I manage software engineers. The truth is that there is no way to fairly judge engineers with “objective” data. Comparing individuals or stack ranking is a toxic fools errand.
There are far too many variables. For example how to you judge a generalist v.s. a specialist? There are 100 other dimensions and each one is fuzzy and requires bias checking at every stage.
Good companies try hard to do fair and wholistic evaluations to ensure pay equity but only in fairly wide bands.
It’s far better to support growth than get hung up on evaluations.
As an agile product pwner, I won’t answer your question but rsther ask you: why?
You can try to measure your software engineers but what’s the point. More likely then not if you think your SE are underperforming there is a problem, usually not laziness. It’s very likely that you don’t want to fire anyone (because that’s paperwork, painful and you’ll need to hire someone else which gives no guarantee to be a lot better) so your second best option is to understand what is wrong and then help your team skillup.
Happy devs who have time to learn eventually end up being good devs. Pressure is almost always useless
Latest Answers