Category error to think there's a strategy. Trump doesn't even know what a tariff is. People try to project a strategy because it's probably too discomfiting to believe that the greatest superpower the world has ever known elected a complete nimrod king.
Yeah you are right about this, psychological safety is a key ingredient in what “good” looks like. Blameless culture stuff is a bit of another ball of wax, so I didn’t get into it too much.
In an extended chapter of Mythical Man Month, Fred Brooks described his practice of screening candidates for number-form synesthesia by asking “where is November?”
I have number form so when I was young and originally read this I thought it was pretty neat. But as evidenced in the rest of this thread, it’s an absolutely crazy practice since the majority of great programmers don’t have it. And I assume it’d be illegal these days anyway.
When I read your question of "where is November" I immediately had a floating number line in my head and November was "somewhere on the right side" and I instinctively wanted to point to my right and say "over there!".
I don't really see things in a very clear way though. I can't specifically examine things. When I try the "image" tends to slip. I can't get details. It's more a general idea in my mind. So I'm really not good at visualizing a UI and whether it would look good to place a button in a specific place for example. But if I think of our app for example I do immediately have a "picture" of what it looks like in my head.
Great to see this course material public. It's a real missed opportunity though to not mention that Galois wrote a lot of it down staying up all night before being shot.
That's a common myth. See this paper referenced in the wikipedia article:
Rothman, Tony (1982). "Genius and Biographers: The Fictionalization of Evariste Galois". The American Mathematical Monthly. 89 (2): 84–106. doi:10.2307/2320923. JSTOR 2320923
Quite the clickbait. You can only access it from the pay site, or unless you can get a school library to access it, which I will do. Only the first page is available free.
Author here. The main thing that inspired this happened a few years before I wrote it down. Etsy had gotten a new CEO, and they spent one of their first few weeks in long hours at my desk, iterating on the homepage design in what could only be described as a radically fast iteration loop. We'd ship a tweak, look at statsd for ten minutes, then change something else. This would have been a bad idea for all of the reasons of statistical validity listed, even if we hadn't built statsd to use UDP.
Emphasizing working on the homepage was also analytically dumb in a more meta way, since item/shop/search were really nearly all of traffic and sales back then. Anyway, I felt motivated to get that person to think first and fire the code missiles second.
At the end of the day, I think back on it fondly even though it was ludicrous. Shipping that much stuff to production that quickly and that safely was a real high water mark in my engineering career and I've been chasing the high ever since.
Isn’t that last sentence sort of a reason to prefer real-time analytics? If you can make development a fast paced game, no doubt you’ll keep your team more productive and engaged. Granted, it needs to be engineered in a way to ensure that productivity is aimed correctly (“how we decide which things we do”) as you point out in your great article.
There is a good chance the OP shipped changes that would have positively impacted the bottom line, but after 10 minutes of real time analytics it was replaced with something else because it performed poorly in a single 10 minute period.
You can ship A/B tests quickly and many websites do, but decisions are made after a statistically relevant time period.
Good question, though what you have in mind might be real time metrics, not analytics. Even then you might not need real time metrics to know whether your rapid changes are breaking things. An already established dev culture built on CI/CD, actionable health checks, feature flags/toggles, easy release rollbacks in emergencies are what you’d want. This way, your deploys are boring and you can focus on introducing new regressions, uh I mean features, fearlessly. :)
I worked on a feed reader back in 2006. The worst feed discovery kluge I can recall needing to special case was that certainly the most popular blog at the time (Cute Overload) was a frameset around blogger. That was typical though, people’s sites are a mess.
The war was over after the Marianas were taken, if not at Midway. It doesn’t seem right to discount the industrial might like you do when the US produced dozens and dozens of carriers and escort carriers while the Japanese produced four or five more.
But beyond that lots of reasons,
- Intelligence and damage control (mentioned elsewhere)
- The air war of attrition started early, with the Japanese sending flights 600 miles from Rabaul to the Coral Sea. They didn’t rotate their pilots out to recuperate as the Americans did. The average Japanese pilot was a novice compared to his more numerous American adversaries by 44, and flying a very inferior plane compared to the newer F6F’s. And he could expect to fly sorties until he was killed, which by the end of the war was not much longer than one flight.
- Despite starting the war with Pearl Harbor, Japanese doctrine at the top never really moved on beyond Mahan and their plans tended to obsess with engineering a repeat of Tsushima. Yamamoto’s Midway disaster was an attempt to do just this. Compare to the American carrier raid tactics from Doolittle onwards.
- The Japanese were successfully starved of fuel, and for that reason couldn’t even get their big ships out of port before Leyte, which was a doomed banzai charge at sea.
It doesn’t answer the question on USN motivations but does a great job explaining why the Japanese were stuck in a rut and rapidly surpassed in terms of tactics, morale, and skill.
Japan's bigger problem was that for all that area they conquered in the Pacific, they obtained no industrial capacity. It was just space they had to garrison and supply.
There was something deeply irrational about their decision to go to war. The same irrationality led to subsequent errors, including Midway.
I don't know if it was that deeply irrational, I mean beyond the decision to initiate a war with the United States in the first place.
At the start of the war it wasn't clear that carrier-based air power would be able to effectively suppress ground-based air power. The prevailing theory was that carriers were too fragile to do this. The US Army and elements of the Navy with surface warship backgrounds believed this, too.
That turned out to be super wrong, and the Americans won much faster than expected by cutting off and bypassing Japanese strongholds (Rabaul, Formosa) and keeping their airfields impotent with regular carrier raids.
If those hadn't been the case, the Japanese strategy of seizing "unsinkable aircraft carriers" would appear to make more sense in retrospect. The thinking was that an initial crippling blow to the fleet plus the cost of clawing these back would be too much for the US.
Wrong, and in fact many of the Japanese brass thought it was wrong. But irrational would imply that there wasn't a theory, and there was a theory.
The big mistakes were: starting a war with your largest trading partner, allying with countries that could not make up the trade difference, and assuming the country attacked would just give up rather than exploit its factor of ~6 advantage in production capability.
Attacking Pearl Harbor, in particular, was a lethal mistake. The "sneak attack" guaranteed the US would be filled with a thirst for vengeance. Japan might have done better by simply bypassing US possessions (including the Philippines) and going after European colonial areas to the south.
The US only won much faster than expected if one didn't understand how quickly war production ramped up. All that really mattered was that the US was going to do that.
And, having done that, the US would just swamp anything Japan could do.
That was a mistake, but not such a spectacularly fatal one.
However, it does illustrate the underlying irrational process by which Japan drifted into the wider war. The decision to go to war in China wasn't the product of deliberate reasoning at the top, but was the result of actions of lower ranked hotheads in the Army.
> Right, because it wasn't actually the middle layer that was causing the problems
That's generally true about the overall stability, the DB popped constantly.
One reason Emid got grief was because it started barfing every time sprocs, table schemas, views, etc were changed and nobody ever really managed to resolve this. The DBA's would update the text of a sproc without telling anyone and Emid would start throwing exceptions. Certainly a set of fixable problems, but nobody ever really got a good mental model of when it needed to be HUP'd.
"Emid uses psycopg, ergo we have to rewrite the whole thing" was one of the insane justifications tossed around for the rewrite project. Never made any sense.
The business issue motivating removing the middle layer altogether was just that to do anything you needed to change three things in three different programming languages (maybe four if it involved JS or Flash), and this was foolish.
Haim (DB) and Chris (Front-end) were sitting next to each other hammering out the API together, I was mostly working remote.
They would tell me the API updates/changes over IRC, I'd update the Emid code, and we'd kick the servers to restart.
> Never made any sense.
Nope. :)
(In hindsight, given what I know now, rewriting the whole thing in Erlang would maybe have been a good idea!)
