You've only added two lines – why did that take two days?

> Don't let perfect be the enemy of the good!

We're going 'fairly functional' versus 'broken'.

> Thankfully I have never worked with someone like that

Please tell me how to find a place like this?

I did work in a place like that, and it turns out that hastily writing lots of code to do something yesterday whilst under stress just resulted in a constant turnover of staff, with nobody knowing how any of the millions (literal millions) of lines of code worked, plus duplicate objects and structures and functionality littered throughout the codebase, with the main "technical manager" (a coder himself) just far too busy fire-fighting and frantically hammering into his keyboard to ever inform anyone else in the known Universe how anything he'd ever written actually worked, and berating other developers for bugs resulting from them not knowing how it worked, leading to an introduction of thousands of policies regarding coding and check-in, build and style, all of which were out of date and irrelevant and maintained on an unnavigable website that you were expected to somehow just "know", and then "disciplined" when you fell foul of these many policies. No documented design, specs or anything. Just tonnes of code.

I think the company is going through a slow-motion death spiral as they try to combat this ("let's do design! DOCUMENT! That's the key!") but it just results in deadlock in the stages prior to coding since the "designers" don't know how any of it works, so push garbage onto the coders to "implement", which just gets pushed back as it's nonsense, and nothing gets written. And permanent complaints over how long everything is taking to write and document. So just bullying of the developers with shouting and swearing - that'll get things written, right??

You were also expected to estimate how long things would take to write (eg expand an existing structure) without an understanding of how anything worked, and then held to it. I was literally asked by a "manager" once: "Why do you need to know how it works? Can't you just write it if you've been told what to do?". That sealed the "let's get the hell out of here" at that point.

Meanwhile "management" couldn't work out what was "wrong with the developers". "And why are they all leaving? Why do they not know what these millions of lines of code do without any explanation or time to look at it? They must be RUBBISH developers. We need better developers. Employ more GOOD DEVELOPERS. What? Isn't any of this documented????! It needs documenting right away! Do documentation! Who knows how to document this? Ahhh the developers. Developers - DOCUMENT THINGS.", then "Why is there no code being written? What? Why are you documenting??? It's taking too long! Write code! And document! At the same time even though it's impossible! WE NEED MORE DEVELOPERS! Where are the GOOD DEVELOPERS???! We need to write a new policy that the developers should adhere to."

Always the developers' fault apparently. Absolute stupidity.

You can start using Git now right? Just wait for them to catch up.

I probably can't tell this story correctly because it is 2nd hand but ...

I was on a browser team. A fellow co-worker decided to add the Fullscreen API to it which means not just add the API but first discuss it in the relevant standards committees.

I'm pretty sure he thought, and so did management, this would be a 2-3 month project at most. IIRC though it was like 18 months, maybe longer.

Some problems that aren't obvious at first

* What is fullscreen mode? Is it a mode for the page, a mode for an individual element? What?

They eventually decided it was for an individual element

* What happens to the CSS above that element when none of its parents are being rendered?

I'm sure that took a while to argue over. Like if it was position: relative or absolute and suddenly it's parent is no longer displayed. What if the parent has CSS transforms? Okay, you say we ignore those and consider it the root element. Okay so does that mean none of the other styles from the parents apply like color or font-family? If some do and some don't we now have to go through every CSS property and decide if it does or does not continue to inherit. I don't actually know the answer to this.

* You have a DOM A->B->C->D->E. C asked to go fullscreen. While there E asks to go fullscreen. User presses ESC or whatever to exit fullscreen. Should it pop back to C or A? Does it matter if E is a video element and they clicked fullscreen? What if C is an iframe does it matter?

* Testing across all devices that support it requires all new testing infrastructure because going fullscreen is effectively something that happens outside the page not inside so testing that it actually happened, that a user can actually exit it correctly, requires entirely new test systems that were not there for previous APIs. Then multiply by 5 at least (Windows, MacOS, Linux, Android, ChromeOS, ...)

And so even though I'm sure everyone ended up understanding that, it turned out to be way more work than anyone expected. Yet, in the back of their minds it was arguably always "this is taking way longer than it should, goals not met" or at least that's how it seemed to be perceived.