3,771 karma · joined April 2, 2007
https://bsky.app/profile/mcfunley.com
His report for a client that turned out to have been rife with SQL injection at the time was largely movie plot physical security stuff. Not wrong exactly, but not the center mass of the threat model they needed either.
He seemed to lack systems thinking, producing a report that focused on calling out specific employees as dumb or incompetent. Counterproductive at best. It seemed like his PR exceeded his utility by a great deal.
That trend continues beyond the grave, maybe.
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.
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.
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.
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.
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.
During the period between Rob's CEO tenures he and Sid #1 built a Google Analytics alternative together, which was in fact written in C. We very narrowly avoided acquiring this company.
(I made the tweets)
Etsy grew rapidly and organically for a decade, and never figured out how to grow intentionally in an ROI-positive way. As a private company it was not particularly concerned with revenue per employee, and headcount expanded like a gas to fill available revenue. After going public it was way too slow to realize that this wasn't going to fool the public market.
I feel deranged pointing this out, but hiring triple the headcount you need to run your business is not a progressive social value. I don't know what it is.
n.b. I worked for Etsy from 2007-2014. My own values force me to own this.
Example output: http://pushtrain.club
I just grabbed an example at random there. It's not really an excessive example of nesting, but, at the time I didn't grok threading.
I think the data being manipulated is a cloudformation response or something, so, the structure isn't something I'm in control of.
I actually changed it from `(:status (:status ...` in the original, which is even dumber naming, so that it wouldn't look like a typo. Real life programming is thoroughly unglamorous I guess.
The market for stock in a private company tends to be very small. Existing investors and prospective investors in the company can comprise most or all of it. Those folks care more about relationships with the company than getting their hands on a handful of employee shares. What this means practically is that if the company doesn't want you to sell for any reason, the buyers won't cooperate with you either.
If you're planning on selling, you should feel comfortable communicating this to the company. And they should agree to it. And that assent should be very recent and in writing.
You can find startups out there willing to buy derivatives on your exercised shares, which is functionally similar to selling shares. But this is a mixed bag, and you should read those terms carefully.
Read your option agreement. You'll note that among other things, it says that the agreement can be amended by the company at any time to say anything at all. Good luck!