My seatbelt rule for judgment
dannyguo.com
dannyguo.com
* Senior tradesman -> manager is not a natural transition;
* Senior tradesmen take business into account without needing to transition;
* Both technical and business understandings are attributed to management while business is subtracted from senior tradesmen. Hilarious.
I'm glad at one point in my life, I have the option to transition to this magical role where all of a sudden I will understand everything and even if the potential users of this potential idea might potentially touch the potential application.
I wish I could have written a clearer statement instead of this empty half-rant, but as it stands, I am but a senior engineer so am forced to come to grips with my own limitations. If only I would transition... and after, maybe I'll naturally transition to president of everything.
The other developers let me do it and, looking back, they obviously didn’t want to rain on my parade as a junior dev that was eager to help out and “improve” things, god bless them.
I think I actually prefer your type, at least they care about improving things, and they're going to make it theirs.
For context, I work predominantly with stats/DS problems, where errors may not actually cause obvious (or indeed any) warnings/errors.
And sometimes the harder it was to understand something, the more invested you become in it and the more you want to defend it.
The best commits have more red than green.
Imagine that you are developing a storage with an s3-compatible API for internal use. Maybe you should give up and install CEPH instead
Point being, yes, of course you can come up with 1000s of examples where it's good/bad to delete all code. The point of my comment wasn't "It's never good to remove all code for a project" but rather "If this change is good or not depends on variables from outside the Git repository".
- they know something about the context that I was unaware of or have an insight that I hadn't thought of and so I learn something and change my mind - they realise they've missed or misunderstood something, or were unaware of something which I can communicate to them, so they learn something and change their mind. Sometimes this can be as mundane as "this isn't idiomatic, we should prefer the community style.
It's almost always a learning experience for one of us, frequently both. I've learnt a lot over the years of reviewing other people's code.
In the cases where neither of these things happen it's because it's a question of personal taste, there's nothing wrong with the code, I just wouldn't have written it that way. In those cases I leave it alone.
That sounds exactly like the kind of judgement the article talks about.
So it's not as easy as saying "there's always a good reason" or "there's never a good reason". Make a fair effort at uncovering the reason and then it's a judgment call with insufficient data.
Peterson takes it to weird places, IMO, and Chesteron's Fence works better.
"Don't remove a fence until you know why it was put there."
[0] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
> Rewrite from scratch with zero external dependencies - always the fastest way (or at least the most fun way) - it increases understanding. [1]
I don't have a permanent viewpoint on this, I kind of bounce back and forth. I definitely think that whole rewrites are important for getting the module boundaries right, and I think it's important to have seen a problem from a bunch of different perspectives, ideally some of them really bad and borderline outrageous, before you commit to one solution. (“This problem is NP-complete, you just want to brute force it?!” -- yeah it turned out that in practice n was no greater than 9 and you could in fact easily hardcode an upper limit and try all possibilities to find the best one. But even if you don't get lucky, the fact that ridiculous ideas came to mind suggests that all the good ideas were on the table at least once.)
Right now I am more inclined to enjoy rewrites because I am working on a project which itself was a rewrite, and I would like to rewrite it back to something more like what it used to be, hah. If I do get my way you can bet I will turn coat, “we can't rewrite this now, don't you know how expensive rewriting is?!”
[1] https://twitter.com/joeerl/status/837781189385674753?t=RRItS...
I'd suggest there's a difference between "I don't understand how this is supposed to work" to "I do understand how this is supposed to work, and I don't understand why it isn't working."
Seat belt story seems to be Type 1. But what if a lot of "stupid" design decisions are actually Type 2?
And the reasons may or may not be good - somewhere on a scale from real budget and/or time constraints, lack of insight, indifference, penny pinching economics, to passive aggressive user hostility.
When Apple removed Magsafe no doubt there were perfectly good internal justifications for that decision. But ultimately the people outside the company who said it was a poor move from a user POV turned out to be right.
I personally hate the non-magsafe charger because I trip over it and yank the laptop around, but I can see the trade off in being able to use a single charger for everything. Because of that, I see the magsafe issue being a permutation, because by changing the environment that laptop chargers operate in, with the addition of usb-c, you've changed the game.
So why the *ck didn't they just include a little bit of magsafe-to-USB-C cable with the phones, and keep the wall-plug-to-magsafe charger? Then they could have transitioned the laptops over to USB-C at any time without inconveniencing users, added the safety of magsafe to the phones, and allowed users to mix-and-match chargers and cables.
But no, that's exactly what they didn't do. Funny that, for this vaunted "customer-centric" company...
Survivor bias? I'm sure there were people outside the company who said removing the headphone jack was a poor move, removing the CD drive was a poor move, moving to Intel was a poor move, removing the HDMI was a poor move, removing the F-keys was a poor move etc.
Eventually, some of those moves were reverted, some were not. Steve Jobs was exactly right: https://www.youtube.com/watch?v=FF-tKLISfPE
- you can please some of the people, some of the time.
- some mistakes will be made along the way. That's good, because at least some decisions are being made - when we find the mistakes, we'll fix them....and F-keys!
Also, do your USB-A ports on your monitor sit on the back?
It’s unfortunate how many people never come to this realization.
Like 99% of the stuff you encounter on a daily basis is how it is because of some 3-way trade between aesthetically pleasing, the economic realities of producing that object and "how they've always been." It is not engineered for performance in the slightest other than some basic "yeah that should do" napkin analysis.
But your explanation makes _way_ more sense.
But as other comments mention they found utility in it through layering. It may have been for hats once, but it’s certainly kept around because people found new uses.
Yasure that's the reason? I mean, sure, it's possible... But my money is on the "how they've always been" / "the original constraints made sense at the time but they’ve been forgotten and all we’re left with is the end product" mentioned above.
The reason seatbelts release tension is a compromise in safety made for the average driver (i.e lowest common denominator). The engineers probably thought they would compromise on safety because otherwise most people are not capable or willing to operate a harness. Aircraft and high performance automobiles use a design that would make perfect sense to a nine year old.
And more importantly, this misses the point of the original article, in which the author didn't understand how seat belts work at all.
If you do install a well-designed cage just so you can safely use a harness, now you also need to wear a helmet. A cage without a helmet is begging for a bad head injury, because your head bounces around a little during an accident, and those bars are hefty, rigid, immobile objects mere inches away from your skull.
Even in a fairly low-speed incident that wouldn't cause other injuries, the bars would put a dent in your naked skull. You're also going to want a neck restraint system for that helmet (it's like a collar under the harness with little straps to the helmet, so that it can't move far), in part because of the added head weight (momentum) from the helmet and how rigidly your torso is locked in place, to prevent neck injuries.
Now that you have all those parts down: the combination of the harness locking down your torso, the neck restraint, and the limited window of visibility from the helmet means you've lost a good chunk of your peripheral vision and can't turn your head/neck to check things either. With your vision more or less locked in straight forward, you can't see all the things you really need to see to drive in normal street conditions safely. The limited vision works fine on a racetrack under racing conditions because everyone's trained the same way and operating in a sanitized environment, with no "intersections" or cross traffic, you have flag workers and/or radios to warn you of some things you can't see, etc.
The bottom line is that both street and race car safety systems are a whole complex of things that are engineered together in concert. They're well-tuned to the appropriate environment, and foolishly mixing ideas from the two generally makes you less safe, not more.
Random context video showing a race crash from the inside and outside perspective. Loss of brakes at the end of a high speed straight at COTA (he was still moving at 136 mph at the wall impact, after all the attempts to slow it down). The driver walked away fine, thanks to all the safety gear that the cockpit video shows off nicely near the end: https://www.youtube.com/watch?v=dQitOyEyRd0 .
1. In a regular car, most accidents are at relatively low speed, and in those at high speed are generally front collisions (for at least one of the cars), so cars are designed in a way that the front and back are crumple zones to absorb the shock and limit energy transfer to the passengers. So after protecting passengers from flying out of (or within) the car with the belt, airbags are there to prevent whiplash from front/rear hits.
2. In a racing car, impacts are usually at high speed, and in basically any direction. Accelerations and decelerations will be significantly more brutal, and particularly for rally cars, vehicle rollover is really common. Hence the rigid cage + harness to reduce direct damage to the driver in those events. But even so, since the helmet's weight and the rigidity of the vehicle can make whiplash and basilar skull fractures, there are also helmet restraints (like HANS[0]) to reduce this risk.
So maybe, and this is a guess, airbags are not activated in lateral impacts like this one as they could make this escape more difficult than the damage they are preventing.
It wasn't until I had to install a child seat for the first time when suddenly it became clear this was a very useful feature.
I feel like, at this point in my career, and in the specific context where I work, this has now become the bottleneck to my career progress.
The problem is: It works as a self-fulfilling prophecy based on the fallacies of social proof and fundamental attribution error. People reach for the snap judgment "this is overcomplicated" because they expect me to just be the kind of person who just overcomplicates things. And they feel easily justified in that judgment given that other people also tend to make that judgment about me. This means they budget even less time for trying to understand the complexities in the problems I solve before reaching for the easy judgment of "this is overcomplicated".
So: The guy who always overcomplicates things, thus draining the company's cognitive resource needlessly and just generally being a nuisance, ends up looking much the same from the outside as the guy who could just be a company's strongest engineering asset. He could be the guy to put the company ahead of the competition, always understanding the engineering problems more deeply and solving them more thoroughly than others, including the competition, in a way that the competition can't easily replicate. -- ...if only the people tasked with passing judgment could overcome biased and lazy decision-making.
This is often the case, but even more often I think my annoyance with the overcomplexity of the code isn't that the code solves the problem in a too complex way, but that the code solves a much too complex problem.
Most of my job as a developer is fighting complexity. Doing it in code is an uphill battle. If you have to solve complex problems with non-complex code, you are fighting a losing battle. The struggle to keep complexity out of the code happens in the dialogue with stakeholders (Project managers, customers, team etc).
Now, there are of course cases where the conclusion after the complexity debate might have been that "yes, the requirement is for the program behavior to really be this complex, meaning the complexity of the code is required". But this is extremely rare. The reason I get annoyed when seeing complex code is because through the decades I have learned that almost invariably, someone took a complex requirement at face value and implemented a complex solution to the requirement.
Now, I do agree that 80% of all engineering problems that one comes across in practice are amenable to the kind of problem solving tactic where instead of solving problem X, you instead look for opportunities to solve adjacent problem Y which is of lesser complexity.
But sometimes, problem X is just really the problem you actually have and actually need to solve. And you need to add to that the fact that I specifically seek out these situations, because craftsmanship ranks high among my personal values.
To give you a bit of context: Using data from the stack overflow developer survey, I rank in the 87th percentile among developers in terms of years of my life that I've been coding, 70th percentile in terms of years of coding professionally when I don't count my Ph.D. as "professional" coding. The Ph.D. puts me in the 97th percentile of educational attainment, and happens to be from a top-5-ranked university. I spend 50% of my time at work doing boring mundane things like implementing ETLs, which I've done professionally since I was 15 years old (I'm now 37), and I don't even complain about that.
With the other 50% of my time, I try to get my psychological needs around craftsmanship met, and seek out the toughest engineering problems we have in the company where I work. And then those are precisely the sorts of situations, where I have 20-somethings who are my bosses tell me that I always overcomplicate things. This feels extremely humiliating to me, and is a huge lost opportunity for the company.
The problem with these "overcomplicators" is that they see those 80% of problems as the 20% (and in my experience it's more like a 95/5 split).
> To give you a bit of context: ...
If I gave one of my coworkers (or reports) feedback that they had overcomplicated a solution and their response was to drop they're in the 97th percentile of programmers with a PhD from a top-5 ranked university, I don't thikn that would dissuade me in any way, in fact probably the opposite. It's an ad-hominem defense; defending _you_ rather than the decisions you've made.
> With the other 50% of my time ... seek out the toughest engineering problems... where I have 20-somethings who are my bosses tell me that I always overcomplicate things.
With all due respect, they might have a point. If everywhere you go smells, maybe it's time to check your shoes.
...well it could also be the fundamental attribution error I mentioned earlier.
The very way this thread is unfolding reflects my initial point: From the outside it looks the same.
Telling which is which really requires looking at the specific situation, and thinking about it very deeply, and resisting reasoning from an ad-hominem basis, resisting fundamental attribution error, risisting superficial analogies, like your shoe-analogy, or "I've been in lots of situations with engineers who overcomplicate things and usually it's because they actually do overcomplicate things, so I'm just going to treat it like it always is the case that the actually do overcomplicate things".
Regarding the paragraph about percentiles: I did not write that to suggest that I'm always right, and others are always wrong. I wrote it because I think it's natural that 90th-percentile engineers would seek out 90th-percentile problems to tackle. And it's precisely that point where reasoning from "usually..." becomes invalid reasoning.
In fact the seatbelt example is the perfect example, because if you show somebody a seatbelt mechanism, their initial reaction is indeed likely to be "This is overcomplicated. Why not just use a fixed rope?"
It absolutely could be, you're right. On the balance of probabilities if it's _consistently_ happening to you, maybe it's not as simple as "I'm smarter than everyone else in the room".
> "This is overcomplicated. Why not just use a fixed rope?"
The answer to that is clearly demonstrable, and the analogy holds true. If you are an engineer designing a solution to a problem, you should be able to articulate _why_ this solution is necessary, and what problems it solves. If you're consistently being told that it's over engineered, and aren't able to refute that (as you're implying that this is humiliating for you), then maybe the solution is unwarranted.
All too often the pattern is the judge saying or thinking something like this: Since the subject matter is amenable to proof, and since I, the judge, am such a smart fellow that I would certainly be able to follow any proof presented to me with little effort, my reasoning now works as follows: Step 1: I expend little effort when passing judgment. For example, I shall feel free to pass judgment by declaring something to be "overcomplicated" if it comes from a person about whom I hold the opinion that he tends to overcomplicate stuff (fallacy). Step 2: The burden of proof to dissuade me from that judgment then falls on the enginneer. When he presents that proof, I shall then expend only little effort in trying to follow it, and if I can't, then it surely must be due to the fact that, on top of overcomplicating his engineering solutions, this particular engineer is also a bad communicator. Note that on top of piling on one piece of fallacious reasoning on top of another, this pattern now also starts to take on the flavour of special pleading. Step 3: I am then no longer under any professional or moral obligation to listen to pretty much anything that person has to say. And I will not let this stop me from using my influence to prevent this person from having a career in the company where I work.
While this is true, oftentimes it's true that the person who solved that problem solved it through a lens of their own knowledge (blindspots included). Some of the biggest, most difficult to use messes have come from the "expert" developers who solve a whole bunch of problems that are tangentially related with one solution that is 50% neat and 50% duct tape because they _didn't_ think about the complications when they designed it.
I find this is particularly the case when the design flaw is particularly bad, the developers end up adding complexity to work around the flaw, which has the effect of hiding the flaw, making it alot less obvious to the novice.
Fun (/s) example:
- Outlook email client in the browser (Firefox in my case)... typing a new email up. Hold down backspace to delete a bunch of characters... and occasionally my browser will navigate backwards. ("smart" text suggestion lagging, causing keypresses not to be always captured by the email text input box, perhaps?) At least Outlook auto-saves drafts reliably!
- I (probably) can't be mad at the individual programmer though. I'm the oddball that has reverted the browser setting for "treat backspace as browser-back, outside of text fields". I bet that never made it into a test-case anywhere.
- I could be mad at the browsers that changed that default behavior several years ago (I feel like Chrome did it first, but could be wrong), though they did it for the valid reason of protecting the (less aware, imo) users!
- I guess I could be mad at all the websites that poorly implemented form-filling, letting users get burned by accidentally going back a page and losing their input. But I can sympathize with too many "features" and not having time to implement that edge case!
Sigh, my ideals of software quality are all doomed, aren't they?
>less aware, imo
It was always a terrible feature! alt/super+left!
If I test a software requiring network connection, then I need to consider the possible states of two obvious layers: network and the os.
If both layers only have 3 qualities, with 3 distinct states, then they amount to a 3^6=729 total different unique environment my software can run in.
Then I need to test all my unique software states in all of the above cases, which is already impossible.
So are you making the point that the current abstractions are not good enough, because I cannot consider them “invisible”?
I think that's a general rule of thumb for abstractions. (I'm not sure, though; I just made it up.)
> How do you overcome schlep blindness? Frankly, the most valuable antidote to schlep blindness is probably ignorance. Most successful founders would probably say that if they'd known when they were starting their company about the obstacles they'd have to overcome, they might never have started it. Maybe that's one reason the most successful startups of all so often have young founders.
> More broadly, 2018 research published in the Harvard Business Review found that the average age at which a successful founder started their company is 45. That’s “among the top 0.1% of startups based on growth in their first five years,” according to the report.
https://www.cnbc.com/2021/05/27/super-founders-median-age-of...
Let's not perpetuate yet another ageist myth.
Also "most successful startups". OK let's do a quality of life scale, 0 for destitute, 10 for billionaire. Millionaire would be 9.8 on the scale. Hell maybe the other way around, being a millionaire is better than being a billionaire (because of the problem of fame).
A lot of people reach that by doing mundane things like starting a tyre fitting shop, or janitorial business, or flipping houses, or very niche software businesses.
Depends what we mean by success. There is the 'make investors rich' kind of success that an investor is looking at encouraging people to do.
You (probably intentionally?) put the finger on something that's been annoying me about this whole "Startup!" malarkey for a while now: The pretentious terminology. "Startups" are actually just small businesses.
So I'm not sure if ignorance is exactly what's called for...maybe irrational optimism is more like it?
My default nowadays is I never know enough, even in the fields I'm specialized in. Part of it is I think just a limit of how much information I can accurately refer to/pull up in my brain at any given time too.
What's interesting is that I now know something that the engineers designing the system should have known but apparently didn't, or knew and didn't care about. So sometimes (or much of the time?) users do know something the engineers don't.
This is a tradeoff.
You can have a pure pay-out based locking retractor (centrifugal clutch). Or you can have a pendulum-based mechanism, or a combination of the two.
If you have the pendulum-based one, you'll be less likely to false positive based on the movement of the occupant but more likely to false positive based on deceleration of the vehicle.
The combination is best, because you can be relatively insensitive to individually occupant movement and vehicle deceleration and still actuate reliably in a crash. But it still will false positive.
In any case, "not annoying the user" is prioritized beneath "saving lives in a crash" by regulators, and hence the auto industry.
I'm guessing you brake rather abruptly in this situation if this is something you routinely encounter.
Your tag line reminds me of all the times I've pondered how bad these complaining drivers must be.
A single rude salesperson and they won't step foot in the entire chain, a bad cop or doctor and the whole police force or medical establishment is corrupt. Listen to a politician giving a speech and people become lifelong supporters even when their policies change radically.
There is something deeply embedded in the human mind that makes us very susceptible to some stories - against all evidence, if it fits our preconceived perception or coincides with something in our memory.
I’m not sure these are the greatest examples.
If “good” cops stand by watching “bad” cops abusing their position including stealing, lying, assaulting, murdering or torturing people, then maybe we are speaking of institutional issues blurring the lines between behaviors typical for organized crime and ones observed with the police force. Especially if whole police teams threaten to stop doing their jobs if their insanely inflated budgets get reduced.
Of course there are good cops. You can often hear about them getting pushed out of the police force for reporting the crimes of the bad ones.
If doctors are allowed 20 minutes per patient visit and are constantly pressured to prescribe medication and procedures for profit then we might have an issue there, too.
If your reaction to group X is "it needs to be disbanded because <incident>"... I suggest that this is not a wise reaction. In this sense, all "establishment" is corrupt, to some degree, by definition. To try to create brand new "uncorrupted" replacement is often a recipe for disaster (especially if you only rely on "new people", not on actual new systematic ways of weeding out said corruption).
Because whenever caught, bad stuff will be always framed as individual failure, despite those individual being encouraged to act that way by their bosses and peers.
- There's a high likelihood that the institution was created because it's useful. Before arguing for its complete removal, the onus is on you to prove that you understand why it was originally needed, and why/how the circumstances changed in a way that makes it non-useful/not needed anymore.
- There's a high likelihood that if it's needed, just disbanding it and creating a new one will not solve stuff in the long run. Before replacing the institution one needs to show that they understand what are the challenges of reforming it (why reforming will be impossible/more difficult than recreation; and why the new institution will avoid having the same fate).
It's in a way similar to software: many engineers will jump at the opportunity to declare that "old code is garbage and should be rewritten from scratch"; but that is seldom a good choice, and once you start on that path, if you're simply trying to replicate the same functionality you are more likely than not to end up with new code that is still garbage.
For example, I will forget a compliment a day later, but I will never forget that one time I was harshly criticized.
It makes sense from an evolutionary perspective as well, the worst possible experience (death) is far worse than the best possible experience (food,sex,comfort,etc).
Re: your example about politics. Politicans explot this by talking about how bad the others are, rather than how good they are.
My younger self condemned my father's printer as "dumb" for printing a multi-page print job in reverse order. It took me a couple days to understand it does that so that you have them sorted once you pick them up (printed side was up). By that time I also have already publicly declared the stupidity of that printer. I think the shame after my enlightment deepened this life lesson.
Mostly stopped calling things dumb since I adopted that rule.
In those situations, "dumb" tends to be a correct judgement.
I'd also add: ...should be proportional to my need to or benefit from passing judgement.
Postpone judgement and you observe more. It's counterproductive to stamp everything in life "good/bad" "dumb/smart" "friend/foe" as soon as possible.
> Sometimes things really are poorly designed (check out The Design of Everyday Things)
They're sometimes called Norman doors after the author of that book. (Seems weird to me to name something after the person who pointed out how bad it is, but whatever...)
Assuming stupidity when you don't really know anything about the subject.
I judge something 'proportional to how much I know about it' and in context when it was developed.
Designers take things outside of the design into consideration. The design may remain alive and in use (but not necessarily the original intended use) way past the original, outside environment.
My logic:
Being a test pilot is dangerous. Only idiots do dangerous things. Therefore test pilots must be idiots.
Later (embarrassingly later) I learned that many test pilots were also engineers. This made me reconsider my opinion. I learned to be very careful when judging intelligence, and also the limits of inference.
Why? Plenty of engineers are complete idiots in many levels.
Intelligence and stupidity suffer from fundamental attribution error.
The main thing I learned from reflecting on my error is that making any sweeping conclusions about people is foolhardy.
So yes, engineers can be idiots, test pilots can be idiots, smart people can decide to do dangerous things on purpose, idiots can do dangerous things on purpose, idiots can do dangerous things on accident, so on to absurdity.
Putting people in buckets based on some observed criteria is rarely advisable; everyone's story is different.
If I find a stupidly designed product, it is often because it was the cheap option. Spending more saves money in the long run. Water bottles spring to mind - most of them leak or get damaged by dish-washing sooner or later. Spending $20 on a water bottle is cheaper than spending $5 ten times. Although a high price isn't a guarantee of quality either!
Well then they weren't being stupid - they were optimising for short-term cost. That's not stupidity - it's a tradeoff.
Maybe it was actually designed stupidly, or maybe someone just made a different choice given a different set of circumstances.
> My willingness to judge something should be proportional to how much I know about it.
I think it’s a sound rule. Going to try to remind myself of this more.
> There’s so much I don’t know.
To become:
"My willingness to judge something should be proportional to how much I know about it and there’s so much I don’t know."
When everyday folk start doubting the safety and/or effectiveness of mRNA vaccines this is what comes to my mind.
Source: I built a startup in this industry to prove it.
Edit: I kid you not, I once went to a conference and a traffic engineer for a sizable city got on stage to present the best idea they had and it went like this:
> So once traffic gets to 80% on the main road, we're just going to change all the lights to green and everybody on the side streets can just suck eggs for 5-7 minutes.
That's it. That's the best their simulations could come up with. These people use interns with clipboards to get their data.
Edit 2: "Suck eggs" were their words not mine.
Mind you, they had modernised it! It worked on 32-bit!
If anyone thinks that this Windows 95-era application had any kind of smarts in it at the same level as modern machine learning, AI, or even basic queuing theory, they would be sorely mistaken.
I believe all it had were some basic weekday-weekend and peak-afterhours scheduling capabilities. It also had sensor integration, but only at a few hundred key intersections around the city.
Be it some technical choice at work that had obvious flaws. Or when we were renovating our house and as a layperson I noticed a serious problem the experts didn't see. Or when I was reading about poststructuralism, or critical theory at university. I had a feeling it was just a lot of word games around a couple important ideas - then I put in the work and read books and went to courses, and yupp, that was basically true.
Looking at it from the other side, as an expert on some topics, I know there are a lot of things we do that are not justified by the "subject matter" but we just do them because we have always been doing them, or because a pointy haired boss decided so. Or we have operational blindness and can't notice the flaws anymore.
There is some conflation of these two concepts in the comment threads.
There are a lot more people programming social media sites than there are programming train traffic systems or missile controls—I have a strong feeling those that work on these sorts of projects have a much different attitude.
I would try not to write in C++. There are languages that are much safer.
Our code is the worst. But we're fast.