Hacker News new | past | comments | ask | show | jobs | submit login

they have innate understanding that being observed working is more valuable than the results of their work.

I've seen coders who knew this by heart forget this less than 5 years after entering management and become champions of forcing everybody into the office for 8:30 stand-ups and time tracking systems that enforce minute by minute "project accountability".

I don't know exactly how this happens, all I know is its like a damn force of nature. The only thing I've ever seen kill morale and tank projects faster is random periodic layoffs.

I know exactly how it happens. Engineering projects take a long time. 90% of the effort lives in the basement where nobody can see it; getting data from some other system, optimizing queries, spinning up the servers... nothing at all user-facing. So to the untrained eye, 90% of the time, programmers are doing nothing. And that 90% can be weeks, months, even years.

I don't think any of this is unique to software engineering, either. You don't just one day decide to build a bridge and show up at the bank of the river with a cement mixer tomorrow. To someone that wants to drive over the river, it looks like no progress is being made on the project. Hence, lots of meetings (delaying the project further) to make sure everyone is working hard enough. (Because there is always "that one guy" who actually isn't doing anything. And it looks the same as someone who is working hard to an outsider.)

As for why we spend money hiring people that don't actually do anything, tracking the progress of other people's work... I think it's just loss aversion in action. If you spend 10% of the day working on timesheets and pay an additional employee to check up on them... you know where your money's going. But if someone just shows up to work and does nothing, then they're stealing from you and must be punished! It is human nature.

I don't know what we did in the past that's different from today. Somehow we got to the moon. But now companies are so bloated that even doing nothing seems like it requires 30,000 employees. I don't have much hope for the future generation of megaprojects. And, you know, we're not really doing them anymore. I wonder what changed. Or maybe looking back at the all the achievements of the entire human race at once makes it difficult to put the present day into perspective.

Well for one, this whole "agile" concept of changing things midstream can't be helping. No one says once a bridge is 20% built. Hmm... You know what, more height to avoid noise and smog problems in fact seems to be a better focus than high vehicular weight. Let's start making those adjustments and expect to stick to our time, cost, and quality estimates.

Outside of a few niche areas, calling what's going on in software "engineering" seems laughable to me, and I never refer to myself with that term.

I feel like other engineering disciplines would function closer to the software world if it was easier to iterate. It is very difficult to nearly impossible to change the design of a bridge once construction has started.

If it was super easy, we'd very likely change things once they were in use. Perhaps we didn't account for pedestrians using the bridge and they're walking across it all the time or tractor trailers are having trouble making a right off the bridge. Software is inherently "soft". It's malleable. When done well, it can create better fit to purpose solutions than almost any other discipline. I agree that most "software engineering" is more like plumbing, but I do feel like "real" engineering disciplines would likely follow a similar paradigm if they had the same luxury to rework things.

The development of the road system as a whole is very much iterative.

Well, look at tooling... and in the bridge analogy; material selection.

Look at the bay bridge, we built it using steel from china which, after it was already being used to construct the span was later found to be inferior.

So in SW dev -- you might choose a tool for a massive project only to find its the wrong/not best tool you could have selected based on the budget at the time the project started.

This can also be said of the team. Employee A was the right eemployee at the start of the project, but they later prove to not be the best resource, but youre already X% down the project timeline... what do? Esp at what cost.

I'm not arguing that that other forms of engineering are completely inflexible or that software doesn't have some constraints. I'm just saying that in general it is far, far easier to change lines of code than it is physical objects. That's why when there is a hardware issue that can be addressed in software, they send you a patch not a new CPU.

We are in agreement.

Or a surveying team missed some problems early on - and a bridge fell of its supports.

One Job I had (at a top 5 consulting engineer) was to reverse engineer the code from an onsite survey computer and build a GUI to analyse the data allow one of our Senior Engineers to look at what happened.

Agile is primarily geared for software. I believe it's in the first sentence of the manifesto.

So while your bridge scenario is correct, no one would do that midstream, software solutions often (but not always) can be flexible enough for change.

No, like all management fads, it just needed time to percolate. Now that software is so big, people who grew up in the agile domain have been promoted through the stacks to general engineering managers and have taken Agile with them. This means that folks in the hardware domain are now having to explain that you can't just keep iterating on ASIC's because it is really freakin expensive to make iterations.

It's the exact same trajectory that happened with Lean Six Sigma. It starts out as a good idea in a specific area. People start making money on managerial self help selling based on the idea. Market saturates. Product is pushed into other areas to keep growth. Engineering management idea becomes cult-like. New method comes onto scene and starts to displace the old.

Yes, but that isn't my point. The OP was griping about the difficulty business people have in seeing where the effort happens in software to produce something customer facing, and the dysfunction that happens from that inability to see it. He then wonders in a coda how big infrastructure projects ever succeeded with that kind of disconnect. I'm saying that a big factor at play is that agile subjugated the tech to the business in a way that large nuts and bolts engineering projects simply aren't allowed to do: requirements - down a fine level of detail - have to be provided up front. Once engineers in those domains have their requirements, they are really free to use their expertise as engineers. I don't mean to imply I'm a proponent of "waterfall", but it bugs me that agile evangelists think they've found The One True Way to do software, and don't acknowledge what I think are serious impediments to calling the act of writing software "engineering".

I see your gripe, and customers being promised demo's after every sprint is a bit over the top in many cases. Especially large projects.

But to assume no real engineering goes on discounts the fact that aside from stories there are "detailed" requirements, modeling, and designing that still occurs. If your team is skipping this, that's a problem.

A manager must be able to answer the question "Are we on time? Do we need additional resources?". This happens to help a project, not to delay it. If a good team of developers estimates the effort needed for anyone task with a 20% accuracy (which would be very good indeed), that can make a 9 month project being 2 months late, which might or might not be acceptable.

If developer teams would be treated like the blackbox they apparently want to be treated as would mean that whoever is managing procuesses would fly blind just hoping for the best - but the organization as a whole needs to be understanding what is going on right now.

Time tracking can be a surveilling tool, but it can also be a tool to improve things - someone could find out that a team is running over capacity, and consequently assign more resources to the task at hand or redefine the task.

And, well, for morning standups: when done right they are a valuable tool for efficient communication, and probably better than having people chasing each other for hours on end. IMHO an organisation should agree on a communication strategy that is the most efficient and helpful for it. It is not a religious belief that a standup meeting must be done first thing in the morning, I think that tends to conflict w/the teams personal schedules the least.

>A manager must be able to answer the question "Are we on time? Do we need additional resources?" This happens to help a project, not to delay it.

If we know anything in IT, it's Brook's law: "Adding manpower to a late software project makes it later".

So if the manager asks that for a late project, they are probably incompetent.

>If a good team of developers estimates the effort needed for anyone task with a 20% accuracy (which would be very good indeed), that can make a 9 month project being 2 months late, which might or might not be acceptable.

For a small (a few days) project, 20% accuracy doesn't make any difference. For a large one, 20% accuracy is science fiction stuff compared to the actual accuracy rates of big projects, especially the kind with changing requirements, new issues discovered en route, etc (which is most of them).

>If developer teams would be treated like the blackbox they apparently want to be treated as would mean that whoever is managing procuesses would fly blind just hoping for the best - but the organization as a whole needs to be understanding what is going on right now.

If the manager is not part of the team / actively involved (and thus he is inside the "black box") then any numbers they get is bogus, time tracking or not. Software is a qualitative process, not a quantitative. "5 hours spent on X" mean nothing at all without knowing what was done for X.

Brooks' law is not actually a law of physics though.

There is a lot of wisdom to it. But there are good ways to add resources and bad ways. Perhaps a team isn't getting help from another group. Perhaps there are some tasks that others could offload in a way that doesn't distract the team on the critical path, etc.

It's a good adage but it doesn't mean that you can never take steps to accelerate project delivery.

> Perhaps a team isn't getting help from another group

Then the team should communicate that to the other team themselves.

> Perhaps there are some tasks that others could offload in a way that doesn't distract the team on the critical path

That should be the decision of the team. If they need to cut down in order to stay on the critical path, then they should do so.

You seem to have a rather negative view of managers.

In my experience, good managers can be quite valuable negotiating with other organizations in the company and with getting needed resources. In fact, I'd say that's a pretty significant part of their job.

Brooks law applies to a late project. However if the project isn't late yet - recognizing it will be and adding the right people now can make a difference in preventing it from becoming late. This is hard: first you need to add the architectures and senior engineers (both are badly needed on some other project that will be late without them) spending a few years getting the right frameworks in place, only then can a bunch of new teams join - you take a hit while they learn the new architecture and framework, but a few months latter they are all getting their part done in near isolation. (note isolation - this implies you have figured out the modules correctly to avoid communication problems - a hard problem in itself)

> So if the manager asks that for a late project, they are probably incompetent.

Not necessarily. I've seen/heard engineers who take great glee in pointing this out, but they don't understand the real dynamic. The managers have probably read the mythical man month too.

If as a manager you report a problem to your boss, you're likely to get "help", even if you already have a plan. Sometimes the least costly "help" is to accept additional "resources" and fence them off someplace they don't do damage so that the rest of your team can execute its real plan. Turning down help can damage your credibility/relationships which is what you depend on to be "allowed to be successful". It's emotions, not logic.

Or, if you really really want to, you can tell your boss they're an idiot and need to learn about Brook's law.

>The managers have probably read the mythical man month too.

Some sure, but not the one's violating all of its conclusions...

>Sometimes the least costly "help" is to accept additional "resources" and fence them off someplace they don't do damage so that the rest of your team can execute its real plan. Turning down help can damage your credibility/relationships which is what you depend on to be "allowed to be successful". It's emotions, not logic. Or, if you really really want to, you can tell your boss they're an idiot and need to learn about Brook's law.

Well, this doesn't contradict what I wrote above though. Just finds for a more polite way to handle the situation and not let the extra "help" make a mess of things! But it's not like I suggested telling anyone directly they're an idiot!

Brook's Law always reminds me of one of my favorite Dilbert cartoons:


"Adding manpower to a late software project makes it later" is not hat I even want to argue about. Discovering that a project might run late, and then doing the right thing about that is.. but how is one doing "the right thing" if developers don't want to communicate estimates vs. reality?

"For a large one, 20% accuracy is science fiction stuff compared to the actual accuracy rates of big projects.." (exactly, I made that point as well) "..especially the kind with changing requirements, new issues discovered en route, etc (which is most of them)." If you are working in an environment where shipping something at some random point in the future is fine, well, good for you. The rest of us doesn't work in that world, which means that if you start a large project, lets say over the scale of 1 year, you cannot not talk about progress during that year. This is the point that I want to make.

In that sense: "5 hours spent on X" means, dishonesty aside, that 5 hours have been spent. This has some meaning, namely:

- a) if the estimate has been 1 hour, and this doesn't cancel out over time there is a systemic problem which puts the entire estimate to question. So someone should do something about that, and, whatever that something is - adding new or different resources, changing the goal, changing the timeline, whatever), it is usually not something that developers could do. (Not that I think 5 hours is a useful estimate size for any feature; 1 week, on the other hand, for a set of features would probably be useful)

- and b) if you figure out that team members are frequently spending more than 8 hours per day for whatever features (adjust 8 hours to whatever the team agrees upon) then the team is overloaded, the workload is not sustainable, and, again someone should do something about that...

Really, it shouldn't come as a surprise that - opposite to developers' lore - managers really do add value, especially when they are good managers.

What you get from Brooks Law is really that one should never put more people on a project? (Late or whatever?)

That's an insane idea (it does lead to the conclusion that the optimal team is zero sized), and not an answer to the GP's claim that a good manager must know when more people will/won't help.

The point of Brook's law isn't that extra people won't aid conclusion but that the overhead isn't free and unless the date is grossly overambitious (like 10% done) adding more people will add more tasks in "creating infastructure".

Lets take say Civilizations for example and say you need to build a spearman in 7 turns to not lose - but it would take 9 right now you already have production maximized without adding new buildings. Technically building a forge could speed it up to 6 turns but it takes 20 to build it. Even if it would help adding it right now would only make an intolerable delay even worse.

To get away from the geeky metaphor bottleneck and chokepoint management are a crucial part of making projects parallelizible across many developers and even then there are expenses to making them interoperate.

Unless you are grossly behind it is unlikely adding more people will help unless you are vastly overambitious and try to do something with one person that requires a team of thousands. In which case you have probably already failed too massively to help.

That's the pithy aphorism. Brook's actual claim is a lot more nuanced.

The output of n programmers working on a single task is O(n), but each one of those programmers must coordinate with O(n^2) colleagues. As more people are added, the coordination costs begin to to take over, and the project slips further and further behind. Thus, going from 2 to 4 programmers might be a great idea, while 20 to 40 or 200 to 400 may doom the project.

This is reason humans naturally form hierarchies. It changes the system from O(n^2) to like O(n log n).

Nice observation :-)

It's potentially a bit better than O(n log n).

If a hierarchy settles into a strong tree structure, it approaches O(n) connections people have to handle - one bidirectional connection between each person and their immediate superior.

To put it a different way, a hierarchy has potential to scale without limit, or to put it differently again, the larger a system of people, the more they will be forced by necessity into a strict tree structure for the majority of 1:1 communications.

Except the people you need to interact with are very rarely the same people.

It's much more advantageous to form cliques. Small highly connected groups that work on the same thing, possibly with some lose connections to other cliques. That's the model that most closely resembles towns, cities, and even tribes.

Yes, but software project hardly ever tree-ize so neatly.

Talking to your team boss is good for high level guidance, but wont do anything when what you really need is the details on the workings of X a colleague knows.

Yup, and that was his solution. Small teams that don't need to coordinate much, and well-defined roles for the people on each team.

>What you get from Brooks Law is really that one should never put more people on a project? (Late or whatever?)

Where did you got this idea from what I wrote (in fact, from my direct quote of Brooks' law)?

>That's an insane idea (it does lead to the conclusion that the optimal team is zero sized)

That adding people to a late project makes it later doesn't "lead to the conclusion" that "optimal team size is zero".

That's what's actually insane (one common form of insanity is following a logic to extremes without caring for nuance and limits).

Just that more people is more overhead (e.g. managerial and communication and agreement overhead), more people later equals more time to bring them up to speed and hand-hold them until they're ready plus the added overhead (related with more people) even when they're ready.

Brook's law doesn't say you should never put more people on a late project. It does say that you should not realistically expect the project to finish at (or sooner) than the initial estimate because of you adding more people.

In other words, for a late project with X persons working and M estimated months to completion. The real completion with X persons might be MR months, and with more persons X' it could get to MP. Adding extra programmers won't (per Brook's law and based on typical observations) ever help it reach M.

Sometimes adding more persons will make things worse, where MP > MR, other times they can help finish faster than the "actual" (not the initially estimated) finish date, so that MP < MR.

So it might still be advisable to add extra people -- it just wont (per Brooks law) get you to finish in M, and in some cases might even get you further from MR.

I've always interpreted this "law" to mean just throwing resources at a problem without understanding the root cause will make things worse.

Like the idea of throwing good money after bad, if the problem isn't rooted in lack of resources (e.g., if the problem is actually rooted in bad communication, bad training, bad requirements, etc.) it's not going to help.

It's more that there is an amount of people that will minimize costs, any more or less than that and costs will increase, and another amount of people that will minimize time, again, any more or less and time increases; also, adding people in the middle of a project imposes a nearly proportional loss on time and costs.

He didn't even get deeply into differences between people in that chapter. It's just very basic stuff that is on project management 101 since forever. Yet he had to write it down, and most people still don't seem to understand it.

>I've always interpreted this "law" to mean just throwing resources at a problem without understanding the root cause will make things worse.

It's more about communication and coordination overhead as teams get larger (and new additions need to be brought up to speed etc).

> "Are we on time? Do we need additional resources?". This happens to help a project, not to delay it.

If, by “resources”, you mean people, then Fred Brooks might have something else to say about that.

You bring good points to the table. I’ve seen time tracking used extensively, but never to (intentionally)gut morale, more for metrics, ie project x took 10,000 man hours, and project y is sorta like that if you squint a bit and tilt your head to the left, so it should probably take us 11000 hours. It’s helps large organizations project staffing needs and keep everybody gainfully employed. Managers don’t like laying off people and usually do want everyone to be productive.

I'm not convinced that managers want everyone to be productive, because so many managers act to undermine and disincentivise their subordinates. When the drag is unintentional, I think many managers would rather not think about how to compensate for it. And sometimes it's intentional.

I think the biggest risk introduced by time tracking is well illustrated by a sibling comment:

> My boss knew how long particular task took and asked if I need some help afterwards. It was great support and mentoring. But I now experience exact the opposite. My managers come to me if it took me longer second time than first time to complain about me being to slow.

It produces a misalignment of incentives: If you do a great job one week getting visible things out the door, then you're punished for the rest of your time in that job, rather than rewarded for doing great. So you know in advance, it's better to deliver slower all the time.

I think a lot of people have in the back of their mind an instinctive trepidation for detailed time reporting, because of fears it will invite that sort of paradoxical push, preventing them from doing the best work they know they could be doing. "To speed you up we need you to attend more meetings."

I've also witnessed a different kind of time-tracking problem. Someone logs into a reporting system that, say, they worked 200 hours on a project so far, since the last 3 month report.

Some people don't take the person's word for it. I've seen bosses, peers, coworkers say "I don't believe you, no way that took 200 hours! You've done maybe 10 hours at best. I could do it in a weekend, if only I had the free time. Anyone competent could! If only I had the time to organise someone to replace you. You're lucky to work here, your job should be given to someone else who doesn't lie about what they've been doing. (etc.)"

What's really happening is the person has put in 250 hours (350 if you count that unpaid overtime they did on their holiday and weekends), but reduced it to 200 in the report because they know what their boss/peer/coworker is likely to say.

If freelancing, they only bill for 200 hours, feeling like in a just world they would bill 350, but it's not a just world, and if their client is unhappy, maybe their work doesn't deserve full rate.

Often, boss/peer/coworker is quite incompetent, and wouldn't be able to implement the thing in 200 hours, let alone 10 - their lack of ability or familiarity with the job is what's making them estimate such a low figure. And no surprise to anyone, they can't find a replacement who will do the same thing in less time - although they sometimes find replacements who say they will, and then don't. The cycle continues, rinse and repeat.

So unlucky time-reporting worker is forced to do things to "prove" they are telling the truth about the time they've put in at least, while feeling a heavy dose of imposter syndrome.

Things like ass-on-seat, make sure screen is visible to others at work (to prove not using social media), timing of repo commits designed around reputation rather than problem solving, participate in social chats/IMs just the right amount (too much = slacker, too little = slacker), same with meetings.

And weirdly, it works. Because visibility matters a lot more than results.

If the above sounds a bit like I might be talking about myself... not really. I've had those sorts of accusations a few times, but it's outweighed by the rather pleasant discovery that I've worked for people who are surprised that the hours I bill for (I often freelance) are lower than they expected.

However, the few times it's happened, I took from that the importance of not doing it to other people, even if I'm unhappy with their work. Because it's so undermining at a rather fundemantal level.

>I don't have much hope for the future generation of megaprojects. And, you know, we're not really doing them anymore. I wonder what changed.

We are still doing megaprojects just fine. And less people die doing them.

The First Transcontinental Railroad, 1868 mi in length, was built between 1863 and 1869. Six years - completing a route from the Atlantic to the Pacific.

California High-Speed Rail, 520 mi in length, began construction in 2015, cost 90x as much per mile, even after accounting for inflation, and.... was indefinitely postponed in 2019. For a rail line in a single state.

Admittedly, with much higher speed, and much more humane construction. But nonetheless, even with a much higher per-mile price they still couldn't deliver it? I can see how someone someone might get the impression we aren't able to successfully deliver large projects any more.

Why not compare a functioning project with a functioning project? e.g. the Beijing-Shenzhen line (2230km (1390 miles to compare to the FTR)) that takes 8h34m and can hit 300km/h: https://en.wikipedia.org/wiki/Beijing%E2%80%93Guangzhou_high...

Or we could compare successful project of today (A380) vs failed project (Spruce Goose).

Or, I know it's not as romantic as a real living person on the Moon who then comes back home, but we have robots on Mars. And on comets.

>I can see how someone someone might get the impression we aren't able to successfully deliver large projects any more.

We're all clever people and can convince ourselves of anything if we really try. Why not be positive? :)

I blame the Freemasons. /s

Seriously, though-- whether true or not, there's undoubtedly an impression of extensive graft throughout the U.S. construction industry. Perhaps there are just so many people involved in such work that the inevitable few bad actors stand out more (a dishonest one is more likely to have stories told about them than one who simply does proper work for a fair price), but there is almost a tradition about it. If you talk to almost anyone directly involved in the industry - at least where I've been - they seem to act like these 'shady' types are a noticeable and constant presence.

We also live in an era where the government (federal, state, whatever) is seemingly viewed by many as less a benevolent force to be co-opted, and increasingly as a necessary evil to be thwarted and disempowered. Sure, the time period you mention is right around the heart of the civil war, with all the anti- and pro-establsihment sentiment that came along with it, but these feelings were rather new at the time. Most people were still farmers who valued "getting shit done" more highly than divorced-from-reality ideological barriers. The country was still needing to be connected and filled up.

Read the US Constitution and the Declaration of Independence if you thing this view is new.

I'm of course aware of the basis of these documents as an American. However, a lot of the core ideas behind the US' founding were that it was possible to form "a more perfect union". I.e. one where government was done 'right', I.e. democracy. There were certainly anarchists at the time too, but the form of anti-government sentiment we have now seems to be almost pathological; memetic rather than considered.

Wasn't a lot of the "payment" to the railtoads for the transcontinental railroad giving away land to the railroads to later sell to people (who'd take their trains out there to claim it)? You'd need to factor that in to the payment as well.

I should try to find some hard data, but it always feels like construction costs outpace inflation. I don't know if if it's regulation, labour costs, or what.

Transit advocates have done a lot of work figuring out why costs are so high. Turns out they don't have to be: Barcelona has significantly lower costs than anyone else doing similar scope projects. However Barcelona is in Spain where they speak Spanish so it is hard to learn from them.

I've seen many analysis of the situation pointing to all kinds of different "reasons". Many of those reasons have been rebutted by someone else. I cannot figure out who is right or what factors cause things, but the bottom line is some places transit costs a lot more than others after you factor in cost of labor and land which seem like the only things that should be different.

>However Barcelona is in Spain where they speak Spanish so it is hard to learn from them.

Federal infrastructure projects are in Spanish.

But here is a report in English anyway:


> However Barcelona is in Spain where they speak Spanish so it is hard to learn from them.

I believe it's about 50/50 Spanish/Catalan in Barcelona.

It is complex. I haven't been there is years, but in general Barcelona everybody speaks Spanish and is learning Catalan. It might be 50/50 now, but Spanish is likely to be the language they speak better. As you leave the city Catalan is more common.

Either way though, they don't speak the same language as the people who want to know what they are doing different.

Yes, their wisdom can only be accessed by 500 million Spanish speakers, including around 50 million in the USA.

It isn't just the USA: India has mass transit construction cost problems and could learn - if only they shared a language. Not to mention France (France is better at controlling costs than the US, but still not cheap)

In the US Spanish speakers tend to be poor and thus not in position to do anything about costs if they did look into it.

I'm sure Indians who wanted to go over to Barcelona to learn about the transit system would have difficulty finding a common language, or paying for a couple of translators.

I assume you are making a sly joke, because even if the USA didn't have plenty of Spanish speakers, Barcelona has plentyof English speakers.

I wouldn't expect the people in their transit department are hired for their English ability. Since Spanish and Catalan are important languages there I would expect that I need to learn at least one of them to learn from there. Of course if Spain wanted to teach the world how they do it English would make more sense as it is the dominate trade language today - but I can't think of any reason why Spain would care to teach others. It thus is on the rest of the world to learn Spanish to learn from them.

We might be able to learn from the Chinese or Russians. I'm not sure what their cost structures are like. Learning best practices from high cost areas won't help you control costs, which rules out all English speaking countries.


I forgot about this joke yesterday, but it is a better reply than my previous ones.

> However Barcelona is in Spain where they speak Spanish so it is hard to learn from them.

I'm confused by this sentence.

Yes, and the highly-valuable rights of way which were later monetized by telecom,etc: SPRint (Southern Pacific Railroad), QWest, etc.

Land: Basically free.

Labor: Basically slavery.

Regulation (safety and environment): Basically none.

This goes back to my original point about visibility of engineering work. Clearly, one of the biggest problems that California high speed rail has to solve is buying land for the track. But nobody sees a few land purchases as "building high speed rail". Until there is a concrete pylon with some train tracks on top, people think nothing is being done. But of course, without that pre-work, nothing can be done.

Yep. And it's a hard, hard problem. Buying land or right-of-way in high-value, dense urban environments is considerably more expensive then buying it in unused wilderness. And dealing with each municipality's politics along the way is far more difficult and expensive than dealing with unincorporated, unpopulated land.

I live in Minneapolis, and remember when the 35W bridge fell. Republicans tried to prevent adding lanes for future light rail to the new bridge (particularly then-governor Coleman, who was eyeing a presidential run), and our mayor basically held the bridge hostage - he told the state and federal governments that if there weren't provisions for future light rail, that the city wouldn't be issuing the necessary construction permits for the new bridge. (A call I fully supported, btw.)

This is why it's more expensive than the 1870s.

Now factor in the cost paid by laborers and their families in the form of low wages and hgh risk of detah and dismemberment, and see how cheap FTR was.

You can always get something cheap if someone else pays

Compare feeding and clothing the world now to 200 years ago. We get much more done at a much lower consumer price tag.

And of course CHSR is far more complicated -- travelling through dense, developed urban areas at much higher speeds.

Is it really any surprise that after the easier projects are all done, the remaining projects are harder?

Having access to a train was much more desirable in 1886. It meant you could ship your stuff to markets across the nation.

Today no one wants a train in the backyard.

Plus 1000s of people died constructing these railroads. That's not acceptable today.

Isn't that mostly OSHA? We are still doing megaprojects, but we've traded schedules for safety, which means we can do fewer of them.

I think that's the correct tradeoff, but it would be nice if we didn't lie to ourselves (and our constituents) about the precision of our estimates. I can't recall a megaproject completed this century which was less than 3 years late.

To be honest I still can't understand how those big megaprojects got out of the ground with people coordinating by face to face meetings, circulating memos and phone calls

Maybe that's part of the secret, communication was more expensive so you wasted less time with noise

But how do you put a switch on the panel of the 747, make the wire go all the way to the tail of the aircraft and make it do what you need it to do?

You have a lot of formal processes, a lot of time/effort/money goes into coordination. Having been involved, not with megaprojects but with fairly large design projects (offshore drilling rigs, computer systems) mostly pre- modern communication systems, there were plenty of phone calls, memos, and meetings.

My suspect is distraction. People used to be able to deep work regularly.

That's a pretty optimistic view. My recollection is more along the lines of lots of phone calls and people stopping by your office on a regular basis.

Revolutionary Road was released at the tail end of 1962 and has some stuff to say about office work. If it's accurate (I suspect it's pretty close) then it was largely about passing papers around trying to avoid having to actually do anything with them, without it looking like you're trying to avoid doing anything.

Very similar to modern corporate email, sending crap around forever and bringing in more "eyes" trying to avoid making a decision or—god forbid—actually personally doing real work that produces an actual good.

[EDIT] tail end of 1961, actually, got that wrong.

My point was more that the people are also highly distracted by people around them who are also constantly distracted and thus buzzing, usually because of social media. The only solution is to go away, but then you're not seen in a good light.

I don't know if you are correct in a 'global productivity sense'. I do know that it's quite common for me to get more 'real work' done on the train on the 30 minute journey to work than in the rest of the day.

Peter Thiel asked himself the same question. If you subtract screens and style, how do know you‘re not living in 1973?

I think Yuval Harari was onto something when he said that what guides the vision of a society and thus science spending is ideology, religion and politics.

See medieval churches, the Manhattan Project, the moon landing. I could put a name on it, but better to leave politics out of HN.

As someone who kind of remembers 73 in England, the coffee is way better now. Also we had some epic strikes and power cuts back then and a splendid 73% market crash. After decades of relative economic decline we decided to join EEC, the predecessor to the EU after which things recovered economically from the 'sick man or Europe' to the fastest growing economy in Europe until we recently voted to go back to the good old days.

Only joining the EEC had little, if anything, to do with the recovery and change of coffee.

You remember a country still suffering from WWII and loss of world leader role (and colonies), in a much poorer global period. For starters, the '70s had a global recession and oil crisis, and many countries were affected, not just England. Have a look at pictures of New York of the same period -- it looks like a third world country [1].

In the 80s and 90s, countries that didn't join the EEC, as well as countries that joined EU much later, had the same economic uplift.

(And of course several countries that did join the ECC/EU had economic decline and crashes, e.g. the P.I.I.G.S).

[1] https://allthatsinteresting.com/1970s-new-york-photos#8

Yeah there were many factors. The UK used to be quite socialist in the 1945-1975 period which was OK for the NHS but many other things like British Leyland didn't work so well.

This was quite interesting on the economics https://voxeu.org/article/britain-s-eu-membership-new-insigh...

> If you subtract screens and style, how do know you‘re not living in 1973?

Depending on where you live I’d say access to resources you could not imagine back then for peanuts.

People complain that technology is expensive now, but prices in the 70s and 80s were out of reach for most.

Peter Thiel is a troll.

> how do know you‘re not living in 1973

I would glance at my local grocery store, shopping malls, cars, empty cemeteries, and inflight wifi.

First off, most manufactured things are incredibly cheaper now, due to real, complex behind-the-scenes advances.

We have a global supply chain that largely removes the constraints on geoghraphic locality for foods and manufactured goods.

That's paired with an almost-always-online wireless mobile internet, (that works up to 7 miles up in the sky!) that is absolutely amazing and darn inexpensive.

Our cars are much better at not killing us.

Many more diseases are treatalbe, and injuries curable.

Finally, why subtract screens? Modern screens are great.

> I could put a name on it, but better to leave politics out of HN.

Dunno about churches but the other two were prompted by active large-scale military conflicts. Bring back the Cold War, I guess?

it's hotter

Ooh, this heats close to home.

> But if someone just shows up to work and does nothing, then they're stealing from you and must be punished! It is human nature.

I do realize that far too many people put their faith in the healing power of judgement.

But that is partly because, as a component of that cognative circuit, is that most people have some sort of innate desire to see things as "fair". Certainly not to be the victim! (That's bigger, actually, by far).

People who work with people know who the slackers or the non-producers are. I try to separate those, because some high-output producers can appear to be slackers because they think for 8 days before they type that one magical line of code that saves the project. (It's hard to tell when you are in the trenches day-to-day which may be which).

In any case! (I almost got lost in my parenthetical there), Workers know which co-workers are getting paid to not produce, and know that this wage, applied to a producer would lower their own work load 10% (or whatever), and besides: it's NOT fair! He get's paid $100K/year to not work! And I work my ass off for the same wage! It's enough to make me stop working myself. That will certainly show "them".

At the end of the day, if we do not purge the slacker, morale-rot sets in on the rest of the team, and that's just "bad". Even without the needing to be punitive in our heart, those people must be culled for the continued positive morale of the herd.

Or, so, I thought once. Now - I'm not so sure. But it seemed reasonable at the time!

>> Somehow we got to the Moon. But now companies are so bloated that even doing nothing requires 30,000 employees.

The Apollo program had 400,000 people involved at it's peak.

Which is neither here, nor there.

The programmers for the Apollo software (which is what we're discussing), were at their peak, around 350 [1]. And most of those roles were secondary and only needed because of the primitive tooling and utmost reliability requirements that modern software doesn't suffer from...

[1] David G. Hoag, 1976 - http://klabs.org/history/history_docs/mit_docs/1711.pdf

Apollo software is pretty simple, relatively speaking. It was a hard, but small problem compared to what we expect from modern tech like a car or airplane. Modern software is far more reliable than Apollo. The difference is that 99.9% correct-uptime is terrible for modern vehicle software, but was great for Apollo.


I respectfully disagree. Manager's job here would be to:

- work with devs to make sure whatever gets into the work pipeline is well understood

- everybody agrees on the planned work scope

- prevent anyone from adding "just this tiny thing" into planned scope| - visualise all of this tough, tough dev work, especially the ad-hoc work (putting out fires, for example)

- keeping both management and devs accountable

- and more!

Also I disagree with the bridge metaphor; while true, you can't use the bridge when it's 50% done, you should ideally be able to to use 5% of the planned feature. If you can't, then maybe it was planned out badly and shouldn't go into planning in the first place?

If there's a person that's "working hard" in a team and a person that's "hardly working", then the team has a big issue and should do everything to fix that.

However, This takes a lots of guts on part of (both!) the manager and developers and always has an emotional toll.

This is exactly the problem free market capitalism attempts to solve. To put it oversimply, you have a choice:

* "command&control model" the risk is born by the client, paying cost+15% for everything where they oversee all the work. Low trust, lots of bureaucratic overhead, but if the are competent enough, they can get the project done.

* "free market" model: risk the is born by the vendor -- payment upon successful delivery -- very high profit margin if the project suceeds, but $0 pay if the project fails or is even just second best.

One trick is, even in the "free market" model, you have nested command&control inside vendors, with the same problems that the original client had. You can go "free market" all the way down, but you are still stuck with all the human risks -- people can cheat, be accidentally incompetent, or lose everything just for being second best at project A when they could have been the best at project B.

> Somehow we got to the moon.

The moon isn't hard to reach, it's just not worth the price. If you allocate another $250B like last time, and it will get done -- either publicly command&control NASA, or by paying SpaceX.

We spend collectively about $100B/yr on the Internet, and it's super complex and huge and works amazingly well (works well technically -- how people you hate choose to use it is a human social problem)

Problem with programming - a solution always looks easier when it is already done. Even when a programmer solves a problem, he/she looks at the problem and the solution and thinks: "I have no idea why it took me whole day, it should've taken maybe an hour.". Also, sometimes it's dangerous to leave a programmer alone with the problem - you don't know what they are doing until it's too late.

That is why even the best soloists should try pair/mob programming from time to time. And it is essential to increase visibility in the teams where people work solo/distributed teams. It's okay to shout out in a public chat, group email, etc. of what you're doing, what approach you're going to try, things that unclear to you, what's left, how you'd like to improve it, etc. Don't be afraid to look stupid. It's better than trying to come up with excuses later. Post diagrams drawn on the napkin. Ask your teammates what would they think if you add a library, or remove one. Delayed feature for unknown and speculative reasons never looks good, delayed feature backed-up with your publicly shared notes is always better. Better for you, better for the team.

The best teams operate that way and if a manager cannot create a culture of complete transparency, they'd loose the ability to trust their peers.

Because managers also have managers. If the managers at the highest level think developing software is pretty similar to packing widgets in a factory, they understand and want to see the Frederick Windsor Taylor school of management in the engineering department.

For the first couple of years, you fight against this, passionately arguing for genuinely good engineering practices.

But every time there’s a problem, you compromise and it creeps a bit more in the direction of ‘command and control’. And all those little changes add up to the results you observe.

This is why I'll never work for anything but smaller startups. That sound awful and counter to how software should be done.

I'd imagine the smart developers quickly get replaced by the obedient clock-punchers.

> I'd imagine the smart developers quickly get replaced by the obedient clock-punchers.

I have never understood why the clock-punching is so a big problem. It doesn't take much time to track your time spent with typical softare, in my experience. And apparently being clock-puncher now makes you dumb as well?

I have personally also tracked time on my personal projects. While not sure if it does bring much value, it is not a huge investment time-wise.

I think that's not the point OP is trying to make. There's nothing wrong with tracking time for yourself, or clocking in and out of work. Time however is a really really bad measure of productivity. If somebody constantly stays late at work because they never finish stuff on time, in our current culture they often get promoted for being hard workers. While some might do the same job in 2h that they do in a month.

So what the super productive guy learns after a while is that they just need to "work overtime" and delay presenting results to get ahead. If this attitude starts pervading your team the productivity might start tanking too.

> Time however is a really really bad measure of productivity.

Situationally. With programming there are loads of different tasks. For some tasks I think time can be quite a good metric. Still, metrics matter and I think having lousy metrics is better than not having metrics at all. Of course you have to realize what purpose the metric has in certain situation.

> I think having lousy metrics is better than not having metrics at all.

I fundamentally disagree. Metrics don't live in their own world. They affect the world around them and incentivize certain actions. Bad metrics can produce bad incentives. There are certainly many cases where simply not knowing something is better than knowing something that's only partially right. However, that requires a level of humility and acceptance of one's limitations that can be hard to defend to others looking for straight answers to all questions.

Well, very situational question. My question here is mostly, what are the bad incentives caused when people time track their days for example in with 1 hour or 0,5 hour granularity with software development tasks? I have been doing that kind of tracking both professionally and in personal projects, and I don't see the harm caused.

Fair enough. I mean I guess I wouldn't go so far as to claim that time-tracking is an obviously bad metric. However, I would definitely claim it can be poorly utilized. This metric is just a tool. Employed effectively it can increase performance. Employed ineffectively it can increase...time.

But generally I think my main point stands. We need to be humble enough to sometimes accept lack of control (i.e. not using certain metrics/processes) rather than deluding ourselves by through certain metrics that really aren't very good.

The problem is not the tracking. It is your boss coming over after 3 days asking why this 1 day task is suddenly taking 3 times as long, and how much longer do you think it will take?

Never mind that the task spec changed 5 times in those 3 days.

This 100%. "What gets measured gets managed" is a 70 year old quote by Peter Drucker and it is no less true today. It reminds me of a great anecdote by Mark Graham Brown about "chicken efficiency", which is a great term to describe these situations. https://corporater.com/en/the-chicken-kpi-be-careful-of-what...

Isn't it the most basic rule of any information-based analysis that having wrong information or unreliable one is worse than not having any?

Because: 1) you know what you are lacking 2) you won't take action on wrong information.

If you're a doctor deciding whether to recommend a risky surgical procedure, you certainly don't want to jump the gun when reliable information hasn't yet come in. It surely will do in due course, if you're patient.

But if you're a manager giving out raises to your team, taking no action (i.e. giving no raises) might seem a worse choice than using the unreliable data - and there's no expectation reliable data will arrive if you wait.

Tracking time spent on various tasks can be useful (if not required, eg. for claiming R&D grants). But I feel like tracking time in office/time at desk is a different beast.

Happy employees, at a certain level of knowledge work, have a degree of autonomy.

Unhappy employees who could otherwise be happy employees are a waste of potential and money.

Having a clock on/clock off and a 9-5 butts-in-seats management style and incentive structure reduces perceived autonomy.

>I have never understood why the clock-punching is so a big problem. It doesn't take much time to track your time spent with typical softare, in my experience. And apparently being clock-puncher now makes you dumb as well?

I don't agree with using it as a slur, but I do think it's an awful way to work in a creative field. Some of my most productive work happens as a direct result of my taking breaks - a walk here, a cup of tea there. All the while I'm thinking about the problem at hand. Time tracking discourages this of lateral approach in favor of brute forcing your way to the answer.

You like being micromanaged and told what time you need to be in and out of the office everyday?

> For the first couple of years, you fight against this, passionately arguing for genuinely good engineering practices.

I would like to understand why on earth time tracking is against "genuinely good engineering practices".

Would you do time tracking for someone writing a script for a movie? Or for a painter? Writing code not only requires skill, it's a creative process. You not only need to think about what you write, but also need to stop and relax. When your mind is tired, you're going to write shitty code. It's better to go home earlier and write good code tomorrow than write bad code that in the best case you'll have to delete and start from scratch tomorrow. Worst case scenario, everyone writes bad code, unnecessarily increasing complexity, making the code prone to failures and requiring more rewrites, more developers and more time to understand it.

I don't follow how that is related to time tracking.

I have used time tracking for personal projects and also professionally and I genuinely think that it can add value to my workflow, in a way that I can analyze how much I spend on certain tasks etc.

I would guess also painters and script writers track quite often track their time. I think some level of time tracking is good for almost any level of work. For example, if your goal is to produce paintings and sell them for living, you probably want to know how long does it take for you to produce something so you can see if you are approaching sustainability. Similarly if you write movie or tv scripts it is probably relevant whether it takes 2 months to write the script or 2 years. Some work is just structurally different so different approaches to time tracking make sense.

You're talking about two completely different levels of granularity. It's fine to discuss "what did we accomplish this month" and try to quantify it. It's not fine to ask a script writer why they didn't write any lines between 8:30 and 9:00 this morning.

Personally the software development tasks I have been doing are quite often separable in tasks that take several hours. Sometimes there are tasks that take days without clear separation.

I think asking whether it is discuss "whether you did line this amount of lines within X hours" is more like management and workplace culture than software development issue. It seems that people here are fed up with their managers and funnel that bad feeling against time tracking. In my opinion time tracking is valuable tool and should be used in principle almost everywhere. Bad managers of course make any type of work a pain.

I always found a strong disconnect between what the business side thinks is meaningful and what an engineer and his technical manager finds meaningful. Typically the detailed granularity just isn't there and the data is really noisy as well.

More of late I've thought it'd be better to look at the rate features are added and ignore 'hours' completely. As in Bob seems to be able to complete one hard feature a month, or three medium features. You got to ask, do you care how many hours bob worked? Not really.

Heh, presuming management knows what a hard feature looks like. Or understands the reason why it is hard. They sometimes conflate a patch, a hairy patch or writing correct code from start.

Bonus points if said manager does not understand that writing tests makes one go faster rather than plugging the code and trying to run scenarios manually...

One of the things I now always do is tell my boss both how much work work somethings going to be and how 'hard' something is going to be. Features/changes that are hard have very unreliable estimates. A lot of that has to do with how difficult it is to reason about and debug the feature. And how much other stuff needs to be changed.

When I know ahead of time exactly what the code I’m about to write will look like, I takes this as a warning sign and check in with myself.

Why do I know exactly what this code is going to be? Is it because I’m doing something repetitive? I’m a software developer. My job is to make the computer do the repetitive parts, not get paid for spending four hours doing something we’ve done ten times before.

Mastery isn’t doing more, it’s about being more effective. You develop intuition. And the way your intuitive brain surfaces warnings is as discomfort. If you cultivatea sensitivity to this discomfort it means you are adverse to powering through. On some level you “have to” address this issue instead of tolerating it. You have to scratch.

Now you’re not doing rote work. How long will it take? Who knows. But it’s less time than doing this thing eight more times this year. And it’s not just time. It’s energy and face. A repeated process that can introduce human errors makes you look like a clown to your customers, and your boss’s boss.

I also sometimes track time, so I know how long takes particular task. Good developers do this and can quickly estimate project’a complexity by breaking it into known length tasks. I saw this in a highly specialized consulting company. My boss knew how long particular task took and asked if I need some help afterwards. It was great support and mentoring. But I now experience exact the opposite. My managers come to me if it took me longer second time than first time to complain about me being to slow. This time tracking thing can become very ugly in micromanagement environment.

> known length tasks.

I think the only known-length task is a completed task.

Known exactly, maybe. But when I was a consultant we had a pretty good idea of how long it took to do a good job on a project.

We'd add in some padding because you don't know if something will need a bit more research or if the lead is going to come down with the flu or whatever. You write deadlines that are under the client's control, rather than yours, into the contract.

So you don't know exactly. But if you have a decent handle on the scope of work and aren't trying to solve wide-open problems, you can usually get pretty close.

Certainly, a lot of people don't have this level of experience in a domain. When I do similar work internally at a company now, people are often surprised that I can come up with time estimates (and meet them) pretty easily.

You know how long your budgeted for it. Which is fine up to a point, but when things go over budget then corners get cut. And that costs in time further down the road.

I suppose you can always spend more time but the type of work I did didn't create downstream dependencies. There was no maintenance. (It was reports, competitive analysis, and the like.) Although I can't ever recall a situation where we were like:"It's not good. But it's good enough. Ship it."

That’s the kind of work that can be automated. You’re arguing with people who are doing new feature development almost exclusively. These are apples and oranges.

And frankly if you get too smug about it in a work environment you’re going to antagonize someone into scripting your job out of existence. So I wouldn’t pull on this thread too hard if I were you.

When a task is of known length is the time to automate it.

> It's better to go home earlier and write good code tomorrow than write bad code that in the best case you'll have to delete and start from scratch tomorrow.

I'm on the fence regarding this statement. If you are accumulating increasing amounts of fatigue by being there and writing bad code, then yes, go home, rest, and recover. But, optimal is the enemy of good. Write some shit code in your own branch, learn from the mistakes you made, so that the code you write tomorrow might be "the good code".

Movie scriptwrites are not getting paid per hour though. What they get paid for a script is unrelated to the time they spent.

I realised years ago that getting paid per hour is anathema to my enjoyment of work. I'd much rather charge per project (even if that charge is based on an estimated number of hours) then spend whatever time it takes to complete the project than work at an hourly rate and find myself staring at the clock.

Opposite for me! In my experience, being payed a fixed sum for a project requires a very detailed spec up front and still may lead to bickering about whether any issue is a bug or a feature request. Being paid by hour makes it possible to continuously adjust the project without either party getting screwed.

Do you think software developers get paid for completing the features or for the hours spent hitting keys?

Typically employed developers get paid per time (i.e. hourly or monthly salary). Contractors may be either per hour or a fixed sum to deliver to an agreed-upon specification.

With scriptwriting (and often art in general) you first develop the "product" and then try to find a buyer. This is IMHO not a feasible model for individual software developers.

> Would you do time tracking for someone writing a script for a movie? Or for a painter

If change the flattering comparisons then why not? Instead of someone writing a script for a movie, imagine it is someone writing sales copy. Instead of a "painter" presumably working on some masterpiece, imagine instead it is someone in one of those Chinese factories churning out still life 3265.

Most programming tasks are well understood - most programmers in big corporations are working on CRUD apps. The correct comparison is not to some highly creative process but to some semi-creative process. Sure the details might be different but in the main it can be well understood how long it takes to add crud screen 26.

I guess pg himself popularised the flattering "programmers are just like painters" nonsense: https://idlewords.com/2005/04/dabblers_and_blowhards.htm

It's up to you to choose a more creative engineering job that almost requires you to be a painter (or a screenwriter). Sometimes it's the jobs that are product-level slash engineering, sometimes it's purely engineering ones that require a lot of innovation. If you are a creative type and if you want to make your life more interesting, you will be attracted to these jobs.

It's easier going the other direction: what is time tracking good for ?

Tailorism was good for simple, repetitive and immutable tasks, where the only planned improvement would be the worker. If the task was to be revised, it would be top down from an 'analyst' that designs a new task and test it on workers.

What changed this perception ? Toyota like factories, and the idea that tasks should progressively evolve, workers can change their environment in non top-down ways. The metrics was not how much time it took to do a single task, but how much the whole pipeline was efficient.

It's just an example, but I think time tracking should be a relic of the past, as an idea that was too simplistic and too seductive to micro-managers to be really valuable.

From a throughput management perspective for more office-like work:

It's easy for one person to increase in time-tracked productivity in ways that decrease the aggregate productivity of the group they are in.

Sometimes, the person is happy with their own work and unhappy with everyone else's, and they have a blind spot because it's so hard to understand how improving their own productivity can slow down other people so much to be net negative.

But I've seen it, I think it's real. I think it's sometimes a very strong effect, which can make or break a business.

Just like manufacturing pipelines, people affect each other's work in non-linear ways that clog up the system.

As with pipelines, performance improvement lies in working with those non-linear dynamics well enough to reconfigure the system, so each person can excel at their best.

Because making software is like oneoff or small batch production as opposed to a traditional production line.

Engineering practices vary wildly depending on what type of engineering you are doing.

That's one of the problems they had when developing BS5750 and ISO9000 , "where do you hang the defect ticket" was one of the areas where they had problems - that was what the head of the BSI software quality project told me back when he was auditing a project I worked on ack in the 80's.

It increases anxiety and stress, which probably decreases productivity to a much greater degree than whatever benefits you'd get from time tracking.

I suspect the number one factor to a successful project is a happy, healthy team. I'm pretty sure there's a section in Peopleware that backs that up. I'd be really careful with any approaches that risk losing that dynamic (or preventing it from forming).

It is easier to track people being at their desks than diving into the git repository and looking at what got done.

Also, for a programmer who did not code for 5 years because they got into management, it is a huge source of anxiety and forces them to contemplate the obsolescence of their skills. Having to ask a junior dev how to compile the project you are supposed to overwatch can be felt as humiliating.

When I had a team to manage, I tried to keep involved enough so that I could do the whole build process. Most of my work was complaining about broken master branch and regressions, praising the correct person when a feature gets implemented, shout with the higher management to stop adding irrelevant features every time they meet a client and have a weekly discussion on how things are going on.

We had one lay off during that period, on my recommendation. I was worried about the team morale, but got told we should have fired that person earlier.

Why would you feel humiliated for not knowing which button to press to build, on the current bullpoop, if you hadn't yet needed to use that particular bullpoop?

It's possible that a junior dev who showed you the button might then joke to other junior devs about you not knowing. But a smarter junior dev, wise beyond their years, will realize it's just bullpoop trivia, one of thousands of bullpoops one has to pick up and later discard in favor of a fresher bullpoop, and be happy to help.

In any case, you, as an experienced person, should know it's just a different flavor of bullpoop, and not the most valuable thing anyone knows.

Your decision to stay in the loop, with the bullpoop that your team is currently enjoying, sounds like it might come in handy. But I wouldn't want anyone to ever feel humiliated over bullpoop.

I totally agree, but many people feel that way, especially if they got into a higher position because they are supposedly more knowledgeable.

A build process is one thing, knowing C++17 or rust is another. Knowing if refactoring all these templates structures was really worth 2 weeks is something that is hard to ask to a junior dev.

Good point. On something like the refactoring question, sometimes that kind of question can be bounced off a senior developer, maybe as a bit of a mentoring role for them (official or unofficial)?

Being humiliated (humbled) is probably a good thing because status and responsibility often cause people to become callous, self-serving, and out of touch.

> It is easier to track people being at their desks than diving into the git repository and looking at what got done.

Why not both? Time tracking with tomsething like toggl doesn't take much effort, and you can combine that with reviewing git activity.

As I developer who accidentally climbed the ladder into management (and eventually bailed) I can say that from my own experience it is by sheer force of pressure from non-technical management above oneself.

I fought the management culture hard for a few years, eventually realising that I needed to either become one of them, or quit.

I quit.

Did you quit being a manager or the company? (Honest question). From my observations, it is rare to work for someone as a manager and not succumb to upper management pressure.

I quit being a manager but kinda sideways stepped into a different senior (non management) role in the same company/department. I was quite lucky because I didn't really want to leave the company at the time. I just didn't want to be on the trajectory I was on.

It was kinda awkward initially, mostly for the people I had hired and been manager of who I was now colleagues with, but not for long. Hands down it was one of the best life decisions I've ever made. I feel as though the experience I gained helps me to perform my current role even better than I would otherwise be able to as I have an appreciation of the politics above me that I'd not have had I not been up there and back down again the way I have.

I am glad you could make this transition in the same company.

I've recently had to step down from a senior non-management role (tech lead) that my company forced into management tasks into it, specially things that no one else wanted to do. It didn't work and I ended up leaving the company. It was hurtful because I left believing I had a lot to contribute and was motivated too.

I'm sorry your situation didn't work out as you'd have liked it to. It sounds a lot like the journey I took to be honest. I drifted from "Senior Developer" to "Lead Developer" into "Development Manager" as the company grew. Before I knew it I'd not written a line of code in over a year and all I did was attend lengthy meetings. I'd also have been very disappointed if I'd had to leave the company. I still had a lot to contribute to the business and the product we were working on, just not as a manager.

I've seen that, and the opposite as well, where you have a huge team of people constantly working and yet mysteriously nothing gets done and managers aren't sure what people are doing on a day to day basis.

The managers could walk over and ask them.

If you create a system to measure butt-time in a seat coding, you're going to get lots and lots of butts in seats coding. This may not necessarily result in a product.

"The best example of the danger of focusing on a single measure came when I first started my own consulting practice in California. My second client was in the fast food business and had a chain of fried chicken restaurants that was growing in both the U.S. and internationally. .... Roy went on: “The one metric that is really important to management is Chicken Efficiency. At the end of every day, I have to calculate my Chicken Efficiency score...this is the measure that all the managers talk about all the time.”

Looking at Roy’s chart it looked like he was achieving 99-100% Chicken Efficiency every day that month that must be good. However, I still didn’t know what the measure entailed. Roy explained: “Chicken Efficiency is basically a scrap measure. You take how much chicken you cook and divided it the number of pieces of chicken sold. If you sell all the chicken you get 100% chicken efficiency, which is the goal – no waste or scrap.“

When I asked Roy how he achieved near perfect Chicken Efficiency every day he answered: “I’m gonna let you in on a secret, but don’t put my name in the report saying you heard this from me. My secret is I stop cooking chicken around 7:30 and only cook to order after that. That way none of the chicken sits under the lights for too long, everyone gets hot and fresh chicken, and I don’t throw any of it away – 100% chicken efficiency.“

I asked, don’t you get people coming in here all evening until the restaurant closes? Roy replied: “Oh yeah we get tons of kids coming in here after baseball or soccer practices or games, families, and lots of people. I tell them I’m going to make their chicken to order and it will take 15-20 minutes.”

I asked, do most of them wait? Roy answered: “Heck no, they file right out the door and head off someplace else, but management doesn’t measure that. They do want to make sure I don’t throw any chicken away every day, however. My buddie Leon taught me this trick – he got promoted to run three restaurants by not cooking any chicken“. I went on to visit other restaurants and every one of them talked about the importance of Chicken Efficiency.

Source: https://corporater.com/en/the-chicken-kpi-be-careful-of-what...

"It is easier to justify project delays to upper management when everyone in the team comes in on time, otherwise it becomes my liability as a manager". One good friend of mine, who I respected as engineer, after becoming engineer manager in a small company (less than 10 engs).

I've seen this as well, in my experience much of it comes from other orgs that see the engineering team come in late, or walk around the office tossing a ball into the air.

They start putting pressure on engineering managers to make sure their team is "working". Their team clearly needs more discipline and those 'slackers' need to be cut.

What they don't see is that the engineer tossing the ball figured out that the solution they were about to spend 2 weeks coding can be achieved by leveraging an existing library requiring only a couple days effort.

> What they don't see is that the engineer tossing the ball figured out that the solution they were about to spend 2 weeks coding can be achieved by leveraging an existing library requiring only a couple days effort.

Maybe this is an unpopular opinion, but that wouldn't mean that the engineer shouldn't implement in a couple days and then work on something else. HN loves the trope of the super smart engineer who is smarter than _everyone_ and can look like they're doing nothing.

You don't have to be a "super smart engineer" for that situation to occur. It's completely normal for software features to shrink (or grow) by that much time in my experience.

The engineer probably isn't going to get paid any more for finishing it faster, so what incentive do they have?

Their leaders keep pressuring them and saying, "I don't see your team working!!! What are they doing? Why are they not in at 8am? I want to see some BUTTS IN THE SEATS!" After they get 1 or 2 bad reviews, they realize that one way to get a raise as a manager is to have the team look super busy.

No matter how much your team delivers, if they make it lose easy, folks think it's easy!

If they are running around, sweating, stomping out fires, looking seriously stressed, then my gosh they must be working really hard. :-(

I quit a prior gig because of this. A job I was working on for a few years brought in new management and they started nanomanaging every code commit. After 3 years of building trust, I felt the contract had been broken and quit with nothing else lined up but faith in my abilities. Turned out well.

I can understand requiring the team to be present/online during a certain chunk of the day, so that meetings can be had and people are around if others need help or need to coordinate, but, time tracking for FTEs!? I can only see the most unemployable of Engineers putting up with that shit.

Quite why people think morning stand-ups make sense - as most people are going to have long commutes it makes much more sense to do stand ups at the end of the day.

Actually this is how RAD /DSDM stand-ups are supposed to be done -at the end of the day so everyone knows what they are working on tomorrow.

I think that technology disruption is one of the roots of this. I'm talking about minor disruptions like a new GUI library or an improved query algorithm. Diffusion of these is somewhat uneven, and this results, occasionally, in senior management seeing projects that were impossible or very hard in the past suddenly delivering. This makes them believe that other similar projects should also deliver in that way and that if they aren't then something is wrong - leading to a desire to find out what's going on in minute detail.

Maybe the same way we don't stop for hitchhikers N years (N < 5) after obtaining a driving license.

Well, managers typically have their own managers and will be under pressure to demonstrate how they are "managing" - I think a lot of these things are done to "manage up" from one level of management to another.

"Seeing Like a State" discusses legibility vs illegibility, and how centralization incentivizes legibility. E.g. like how units of measurement were standardized in order to mitigate tax evasion.

Managing people without means that you have to keep track of your employees’ mindsets individually and communicate to each one accordingly which is exhausting.

Personally I don't really see why following some quite common work schedule like 8:30 - 16:30 and having daily stand-up meetings destroy morale. Of course depends on the details, but my life has always been quite nice following standard work styles. Time tracking is a chore that not many like, but still it takes in my experience only 15 minutes or so from the daily time and IMO produces pretty good value.

The issue that many developers have with time tracking is that it requires you to either translate your work into management speak in order to appease the management, or write what you're actually doing and have tons and tons of small blocks in your time tracker that make you look like you're being unproductive and trying to obscure something. Both options add unnecessary mental overhead and interrupt any possibility of having a "flow state".

Writing code and working on software is not a linear process, so writing "worked on feature X" for your entire morning may be accurate, but it's not fine grained enough for what the managers want to see and it doesn't really serve any purpose at that point when you already have daily stand-ups and sprint meetings every week.

This likely isn't the case at all companies and with all managers, but I suspect many have the same experience I've described.

"I can be trusted, but I can't really trust others"

unfortunately, quite common.

Optimizing numbers looks productive..

tl;dr Trust/anxiety

The dynamic goes like this:

1. The manager is responsible for team's output/metrics.

2. Metrics are driven by improvements to the product.

3. Software functionality is hard to estimate (not a widget factory as other comments mention).

4. Manager gets anxious as it will be judged by an outcome not entirely within control.

5. Knowing everyone is putting their best effort increases confidence that team will reach goals by which the manager will be measured.

The manager evaluates team members on longer intervals depending on past performance. This allows the manager to course-correct before the team is evaluated. The seniority/past-performance of a team member determines how much the manager trusts them to spend the team's resources (time; man-hours) to accomplish the team's goals.

The brute force approach to make sure people aren't slacking is watching them work/check-in/report on progress. You can quickly tell if someone isn't putting an effort after a couple of standups/reviews with less-than-expected output or 'yet another excuse'.

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact