Hacker News Reader

Lots of things happened fast during WWII.

One of the big reasons, was that regulatory hurdles were removed.

The result:

Long Island is one big Superfund site, and our cancer rates are through the roof. I know of at least six women, in my immediate orbit, that are currently being, or have recently been, treated for breast cancer.

Before I moved here, thirty-two years ago, I had never met anyone that had cancer. Since moving here, I have known at least one person per year (often more), that had/have cancer.

Part of that is probably age, as I've gotten older, so too, has my peer group, but I wasn't that old, in 1990, when I moved here.

The difference is that they died a lot more frequently, back then.

Not to knock the success of git, or the amazing effort under pressure, but the cohesiveness / understandability could be better.

That's a good point.

But Git was initially written by one cranky Finn, in ten days.

It totally changed the way we all work.

JavaScript was also famously built in 10 days.

I'd say that internally git is more consistent %)

JS on the list is quite interesting, since it being rushed and a prototype ending up getting shipped often gets cited as an explanation for why JS has issues. Given how widespread it is, this is a project I wish had gotten a lot more time. An argument could be made that it succeeded, so it must be good, but given it's the only built-in, full language in the browser just says that it was good enough and now we are kinda stuck with it.

Indeed, there was no choice.

Good thing we ended up with a small language that has easy objects, first-class functions, and compact syntax. We could have got something like ABAP were we really unlucky.

As much as I couldn't live without complaining about Javascript's shortcomings, I have to agree with this. At the time, many of the features you mention were hardly necessary - no one was considering using it to build giant web apps, let alone servers! The fact that people decided they could do those things and the language was sufficiently flexible to grow along those lines would probably be very surprising to the original developer. For having such a chaotic evolution, it's becoming a much better language than anyone would have a right to expect.

Kind of like English, which is also a terrible choice for a global language, it's shown a fairly powerful ability to incorporate new idioms.

I don't believe this. Someone who knows how to design and implement a language with real closures, prototype-based inheritance, a garbage collector, etc. also knows the value and power of those things, used them before extensively and knows how far they can go. Also, the shortcomings that everybody loves to talk about are mostly misunderstood features (yes, even == which everybody loves to hate), and mostly by programmers who wouldn't even know where to start designing a language.

True, as much as JS sucks, some of its fundamentals are really good

Deity helps us if it was really Javascript with complete disregard for first order functions and verbosity through the roof

> JavaScript was also famously built in 10 days

And boy does it show!

> But Git was initially written by one cranky Finn, in ten days. It totally changed the way we all work.

To be fair, Linus was trying to replace Bitkeeper, a proprietary DVCS which he'd been using to maintain the kernel for several years at that point. Mercurial, which runs on similar principles, was around at the time too. He didn't just make a quantum conceptual leap straight from SVM to git on his own in 10 days; he had a pretty good idea what he wanted to build (probably even ideas about the architecture) before he started.

It's still darned impressive; just not supernaturally impressive. :-)

I see this as kinda the flipside of "how to draw an owl" [1]. A smarter programmer than me once described software as "do 90%, then do the other 90%" - the mvp, first functional prototype, heck, even the first deliverable is great and all, but then it's time for the thing to live and breathe and go out in the real world and learn all about what it'll become someday. Thus was born semantic versioning.

On the other end of that, like what you're talking about, you have the artist who answers "how long did it take you to paint that?" with: "my whole life". I think this holds true in most disciplines and especially in software. The actual code that makes a thing work is trivial - but you have to know which of the 9 gazillion ways of doing it is the one you want, which only comes from experience.

1 - https://imgur.com/RadSf

https://xkcd.com/2730/

I've also read that Linus was pretty influential in BitKeeper design too. As in Larry McVoy would sit down with Linus to talk about the design of it. Git's core data structures had probably been bouncing around in Linus's head for months before first line of code was written.

If you know both BitKeeper and Git internals, you can think of their data models as near identical, with BitKeeper implementation using text files and SCCS, and Git using from-scratch data structures.

Just want to mention this because this parable gets thrown around a lot.

The delta between what git is now and what it was when first released is massive. Junio Hamano has been a absolute force of a maintainer and steward over the interim 18 years (!!) since 2005.

This story often gets tossed around, as if to imply all of what git is today was put out by Linus in 2 weeks, but I think it suffers from a bit of a hero worship problem. It was no doubt impressive and should be recognized, but I just want to make it clear: Git was made by many people over many years.

I think that’s mostly understood. It’s up there with “JS was implemented in a week.” Yet in both cases, the skeleton defined the rest of the animal; git and JS are still recognizable from that initial version, even if the diff is massive.

Maintainers should get more credit, but the hero worship isn’t entirely misplaced. It’s not often that someone gets to change the world.

Twice.

That's par for the course, these days.

I was the original author of multiple systems that have lasted decades, but I'll bet that you'd be hard-pressed to find much of my original code, in the current iterations.

Most of the inconsistencies, like "checkout" having three different functions, were added much later, in attempts to make UX niftier locally, without thinking about the product as a whole.

Checkout can move your head to different commit and it can copy files to your working tree from a non-checked-out commit. What's it's third function?

It can create a branch with -b, based on a branch of your choice (not necessarily current).

I constantly use this, having created an alias:

  [some other branch]$ git cob feature/foo123 main

Eh, I can squint and see that as a special-case of moving your head to another ref - the `-b` merely flagging "if this branch doesn't exist, create it instead of erroring".

It's a bit like building a train station is a special case of arriving to it :)

maybe like mkdir + chdir

It's arriving at it with trucks and bulldozers and other equipment repeatedly, but essentially yes.

For what it’s worth, this is now being separated out a bit to be clearer. You can use `git switch <branch>` to switch to an existing branch, `git switch --create <branch>` to create a new branch and switch to it, and `git restore <file>` or `git restore --source <ref> file` to restore a version of a file to your working directory.

I can't comment on the bus line example, but the New York Times had a great write-up (https://www.nytimes.com/2017/12/28/nyregion/new-york-subway-...) about subway building in New York. At least in New York there's a lot more going on than the reasons you point out. Particularly damning is the fact that Paris is successfully building subways at a 10th of the cost in far less time despite having even more constraints around digging.

Yeah, this is a much better example and reflection of how weakened institutions and process can drive up costs.

The recent additions to the Rome Metro were also built faster and cheaper compared to, say, the Central Subway in San Francisco, despite all the archaeological artifacts in Rome slowing down the digging.

Thats the story, but everyone who transited Van Ness during that time saw the same thing - very little work actually being done. The equipment just sat there idle most of the time. A more efficient process could have come in and finished the work, block by block in far less time if they actually, y'know, worked on it. People in construction tell me that it's because they're always waiting on the other guy to finish their job before they can do theirs. Where's the Gantt chart for Van Ness? Where's the accountability?

What are you going have consequences in the project management office of a gov contractor that probably has no real competition, besides maybe multiple years later when it's politically convenient? Fire the lower level union workers slacking off?

The fact every single major infrastructure project is a decade late and 3x over budget is just normal and tolerated by the people running the show across the US/Canada. The gov workers picking who wins these gov contracts (usually the same small set of companies) doesn't seem to care, despite extensive track records of the same behaviour. They probably have jobs lined up at these companies there afterwards.

It's only natural human behaviour to not put effort in if there's no consequences or risk in doing so. This is Public/private partnerships 101.

> It's only natural human behaviour to not put effort in if there's no consequences or risk in doing so.

That’s nonsense. That’s like saying that it’s only natural human behavior to abuse and be abused. If I put myself in the shoes of an underpaid sewage worker, that has a family to maintain, that sees the owner and investors of said private companies getting obscenely rich just by closings contracts under their AC… yeah, I’d slack the s* out of it too.

> ...That’s like saying that it’s only natural human behavior to abuse and be abused...

I think that's exactly what experiments have shown the world. There are many follow-up experiments that prove exactly that.

The Stanford Prison Experiment has become one of psychology's most dramatic illustrations of how good people can be transformed into perpetrators of evil, and healthy people can begin to experience pathological reactions - traceable to situational forces.

Those traceable situational forces can be minor and subtle things, and yet.

> The Stanford Prison Experiment

Thoroughly debunked[1][2][3], no?

[1] https://themindlab.co.uk/academy/epic-fails-what-can-we-lear...

[2] https://www.vox.com/2018/6/13/17449118/stanford-prison-exper...

[3] https://gwern.net/doc/psychology/2019-letexier.pdf

No. The SPE was unethical and its methodology was garbage, but the observations were valid enough. When someone refuses to commit an atrocity for you, all you have to do is ask the next person in line. You won't have to go too far down the line before you find someone who is not only willing to follow an illegal order from an authority figure, but happy to. See also Milgram.

The conclusion was self-evident before they ran the experiment, so another criticism that could be leveled at the experiment was that it was redundant.

> The conclusion was self-evident before they ran the experiment, so another criticism that could be leveled at the experiment was that it was redundant.

"It's just common sense" is not a solid scientific proof. Testing something that we _think_ we know (but have no proven) is not a bad thing.

Ish. It’s usually more useful to test hypotheses about why something is. If that something isn’t then you can’t get an answer & will often demonstrate the counter-factual.

Simple “we confirmed water is wet” tests are not very good science. Whereas “what is wetness & why does it happen” is.

Milgram experiment debunked too

https://www.theatlantic.com/health/archive/2015/01/rethinkin...

https://www.psypost.org/2019/11/unpublished-data-from-stanle...

https://www.bps.org.uk/psychologist/why-almost-everything-yo...

The word "debunk" is doing some heavy lifting in those articles. "....Overall 58 per cent of people actually disobeyed the pushy experimenter [which means that 42 percent didn't.] How can we understand this variability, Reicher asked, if the agentic state is true?" What else would explain it -- and more important, what difference does it make?

Milgram found that 42% of people will administer electric shocks to someone who appears to be screaming in pain, as long as the order is given by an apparent authority figure. What is there to debunk, exactly?

Keep in mind what motivated these experiments: a desire to understand more about how the Nazis were able to accomplish what they did. It's not as if the findings of Milgram and Zimbardo were novel or controversial; they were merely trying to reproduce and understand something that the entire world had just observed.

I believe the debunking is that there's good evidence many of the participants realized they were in an experiment and the other person was an actor, but Milgram hid this in order to get a famous paper.

Does it matter? If someone may or may not be an actor by your judgment is going to cause you to possibly commit an atrocity then you should play it safe and refuse. Just in case...

It matters for the validity of the experiment, yes. Bear in mind, the chances of the experiment being real were astronomically small, as university professors are not normally in the business of torturing members of the public. As there were (iirc) small rewards given for taking part, the rational thing to do is follow the instructions. This seems like an inherent problem for attempting to study order-following in a lab.

And of course if you were a participant in the original experiment, you'd tell people, "Of course, I knew it was just an experiment, and it wasn't really happening."

You'd start by telling yourself that, so it would be easy enough to convince people looking to "debunk" the experiment later.

They told Milgram himself and he hid the interviews. From the second link above,

The new research builds upon findings from a previous study, which analyzed recordings of 91 conversations conducted immediately after the termination of the experiments. The recordings showed that most of the obedient subjects justified continuing the experiment because they believed the learner was not really being harmed.

There was a Grand Jury report analyzing the causes of the delay in the Van Ness project. While the unexpected conditions of the underground utilities is cited as the primary cause, it does touch on some project management aspects that you mention as opportunities for improvement:

https://civilgrandjury.sfgov.org/2020_2021/2021%20CGJ%20Repo...

Ironically, more planning and analysis at the beginning of the project (e.g., by potholing and inspecting the condition of utilities underneath Van Ness may have avoided the construction delays.

I worked on that report! (Throwaway because, well, my real name is on the second page...)

The lack of meaningful technical planning was a big part of it, and so was the contract-awarding math, but I think the most striking - and generally applicable - behind-the-scenes stories were about what happens when trust breaks down at a human level. The city's internal back and forth on approving and then un-approving a subcontractor at the beginning meant that the GC was more likely to work to the letter of the contract when things went wrong later, instead of collaborating to solve problems. The one positive thing the city eventually did to get the project moving forward, according to all the information we got, was put someone with some amount of authority on the ground to talk to people.

Rereading the report now, all of these facts are in there, but I wish we'd found a way to stress this part more. You see the same thing in every industry, whether it's individuals or teams or companies working together - the best laid plans mean nothing unless the people involved are actually interested in tackling challenges as they come up. Culture eats strategy, and all that. A culture of writing a plan and then either strictly following it or throwing a fit when it can't be followed isn't a culture that can do great work.

Thank you for commenting! I didn't get those details in the first read of the report, but looking through now I can see what you mean.

It definitely does convey that once things were going wrong, the relationship broke down quickly, and it was hard to adapt once the trust was lost.

Can I just point out how awesome it is to be discussing a infrastructure failure and one of the postmortem report authors chimes in with their experiences. Sometimes the HN community truly is amazing!

A big part of “modern slowdowns” is everything being contracted and subcontracted - as opposed to one large company, government, or army doing the entire thing.

I was once told that Supply Chain and logistics are a people business. And it's true, for the very reasons you mentioned, the moment partners work according to the letter of the contract, and not the spirit, things become difficult. Trust is so easily lost...

> one reason there were major delays was because maps of underground sewer lines and plumbing were inaccurate, and needed to be relocated.

New York calls this "peek and shriek" [1]. No one really knows whats under the street until you start digging.

The Van Ness Bus line was particularly bad because it failed to adjust expectations and project management once this was discovered. In NY at least everyone expects it to happen, infrastructure there dates back hundreds of years.

[1] https://www.nytimes.com/interactive/2016/08/18/nyregion/new-...

It was also pretty predictable as literally ever major SF dog runs into similar problems or wacky underground issues (giant building sized slab of rock that no-one found? Happened. Run into multiple historic 150 year old sunken boats buried under your skyscraper? Happened…)

Are you arguing that we would have been just as slow in 1955 if "There were existing infrastructure or residents to deal with"?

The whole point of this article is that we should aspire to be better, faster, more relisilient to failures, less bureaucratic and efficient. My gut sense (subjective) is that we profoundly suck today at doing anything aspirational. But, nitpicking each of the examples as many comments here are doing, is IMO missing the point. I don't think Patrick is trying to be super objective here besides trying to be as accurate as possible with sources/number of days it took to build those projects. It is kind of silly to say "Oh, they didn't have X, Y and Z in 1955" because you cannot accurately judge what would have happened if X, Y and Z were actually the impediments in 1955. I used 1955 as an arbitrary year to illustrate the point.

The reality is more complicated than it appears but I've observed a bunch of construction projects near Millbrae CalTrain station and they finish the buildings extremely fast. A bunch of metal frames go up, then some pipes, then some wires, and then some concrete walls.

The project planning and construction is done by a single company, Truebeck Construction, and they seem to know what they're doing.

I don't know what Patrick's list is trying to illustrate but most construction projects in the US happen very fast.

This is not a widespread opinion or pattern as I see it. This is first time I am hearing from someone that we in America "build things fast".

I suggest reading Eli Dourado's blog: https://www.elidourado.com/

and his many blog posts on HN: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

Just speaking from personal experience. The methods that I observed are very modern and very efficient. The parts for the entire building are pre-fabricated and then assembled at the construction site. So the stagnation narrative is more than likely overblown and the folks that think things are slower now should visit some of those Truebeck construction sites and observe for themselves.

I don't think so at all and the evidence points to a profound stagnation in our ability to build. So, if we can't even admit that we're terrible at building fast, there is very little hope. Step No. 1 is admission and introspection:

https://www.fullstackeconomics.com/p/why-america-cant-build-...

https://www.nytimes.com/2019/02/25/us/california-high-speed-...

https://www.nytimes.com/2023/02/05/opinion/economy-construct...

https://www.nytimes.com/2021/01/04/opinion/manufacturing-uni...

https://www.palladiummag.com/2022/06/09/why-america-cant-bui...

https://www.wsj.com/articles/infrastructure-us-costly-explai...

https://techcrunch.com/2019/02/19/why-cant-we-build-anything...

Have you personally seen those construction sites? Just go and observe, the stagnation narrative is overblown.

For anyone looking for an in-depth post mortem of the Van Ness bus line, please read the report from the SF Civil Grand Jury here: https://civilgrandjury.sfgov.org/2020_2021/2021%20CGJ%20Repo...

Great report except it missed the most obvious recommendation: "decouple transit improvement from utilities projects"

The issue was that in this case they couldn’t — a lot of the BRT benefits came from creating a center lane, and that center lane was infeasible unless they did the utility project first.

I'm not an expert but have served on BRT CAC for Geary. They could have done side running and defer utilities to another agency at a later date, after which point move to center running. Or any other of the plethora of options that didn't involve a transit agency running a utility project.

Sure, complications happened. But how efficiently was each day, each hour, used to solve these problems.

Hey if there's some delay caused by your team you can always just go back to the gov with shaking the money tin and explaining some 'unexpected outcomes'. The fact it's the same outcome every project is a feature not a bug.

bait & switch strategy.

if project realistically costs $100M and should take 3 years - it won't be approved due to budgetary and other political reasons.

Much easier to announce a project as $30M that can be done in 1 year, and intentionally skip over planning, and contingencies+complications.

Plan for naively simple project, like a Wordpress website, even if it is for is amazon.com.

When the project SNAFUs, go back to customer and use sunken cost fallacy to get more budget & time, until customer runs out of either Money (budget) or Patience (time), then complete the project and move on to the next "Grande Project"

Wherever there's a complex chain of independent workers (a government plan checker, inspector, a planner, a surveyor, an engineer, machine operators, a landscaper, a drain layer, a lawyer, ....) then the reality is that unforeseen nuance and conflicting priorities are ever compounding.

It's ideal to have an uber-specialist, an experienced and respected senior overseer who knows the industry and the project inside-out in both theory and practice, dedicated to the project. That gets things going. It's also rare and expensive - there are a lot more development projects than there are such individuals. They are powerful cards coveted by successful owning developers.