I feel this in my bones. Even before the recent round of restructuring we’ve had a significant about of turnover. Our infrastructure is a massive rube golberg machine with multiple houses of cards built on top of it. Institutional knowledge was never written down and it has been leaving the company at an accelerating rate over the past 5 years. Tons of “new blood” making lots of assumptions on how things work is resulting in… humorous end results.

I am a product manager that loves coming up with detailed specs. How else will I actually get what I want? If you care about some specific behavior/outcome you must specify it. This logic is lost on my leadership.

Agree. The default download location on iOS and padOS is iCloud and it’s pretty clear that Microsoft is chasing Apple’s monetization model.

Haha, TIL that SQL is 51 years old. IBM mainframes were still all the rage in the 70s. My assumption is that government would have not been an early adopter, but I could obviously be wrong.

That sounds surprising modern. That’s good! Or at least I would think it is good. So many things run on mainframes still.

We have a test environment but it’s a hot mess. All the data is made up and extremely low quality. All the things you would normally interface with are also in test, but getting other teams to coordinate testing in the test space is… a chore. We do the best we can with mock services, but without having real services or representative data some of the data pattern assumptions don’t play out. Leaders value writing code and our lack of architects that span teams mean that when team architects either don’t meet ahead of time, make assumptions, or don’t ever agree on a design then…

We always host UAT. We also track logins. Guess how many users even show up for UAT, let alone actually click on anything.

This is why the vast majority of our testing happens in prod when our users are doing real work.

Sorry for the baby rant :)

This can also be one of the frustrating parts of open source.

Find something you don’t like? Fix it. Will the repo owner approve your pull request? Who knows. Maybe they’re a bit absentee. Maybe they view the original behavior as working as designed. Maybe your design doesn’t fit their architectural model, so they’ll (eventually) heavily refactor your changes and merge them in.

You can always stand up a fork, but keeping those two at feature parity and going in the same general direction can become harder and harder with time.

That’s not to say not to try! But it also means reaching out to the repo owners/maintainers before making your first change.

If it snows “bad enough” this is very common. The roads are going to be hard to drive on, which leads to more accidents and just puts first responders in jeopardy. The day before a big snow the grocery stores are usually slammed.

I would love to teach kids. I take any opportunity I can to mentor people at work, but in a school setting would be super cool. The pay cut relative to what I make now just isn’t worth it. Maybe in another decade when we have enough set aside…

If anyone is ever in SE MI, the Henry Ford Museum and it’s adjacent Greenfield Village are worth a stop if you’re into Americana and machinery. They’re both filled with a lot of interesting things to see, learn, and do.

Most OEMs usually show an update screen on their radio, even if something unrelated is being updated.

If the update is taking a long time it could be a really big file on a SOC. It could also be a smaller file being written to… very slow internal memory because when the part was sourced 8 years ago no one considered including memory read/write speed in the sourcing documentation. I’m betting the second, unless this OEM didn’t include background programming on SOCs, which is kind of foolish given how much easier it is on a SOC than MCU.

I can’t speak for this particular OEM, but 12 volt lead acid batteries don’t have very deep power reserves. The OEM choosing to leave the battery on during programming is likely a method of ensuring there’s enough juice to install the update and start the car on the next attempt.

It’s a mix of piece coat optimization and a lot of creep in what used to be a pretty lightweight process throwing it into the ditch.

The things that run software in cars largely fall into one of two camps: MCUs and SOCs. Think Arduinos and Raspberry PIs. Background programming, with an active and inactive partition, is absolutely possible on a SOC. They’re even file based, so you can do all kinds of clever things. Cars tend to not have many SOCs, so it’s not a monumental task to pitch having them each coat a little bit more for extra storage/processing. The biggest hurdles here are automotive grade and the very long development cycles. These both mean that the hardware is 3+ years old when it launches.

MCUs tend to have monolithic software builds (think literally everything gets compiled into a single .exe). There are a million billion of these things in a typical vehicle from most automotive OEMs. It’s… very hard to make them all have more capacity because you would take that cost and multiply it by 40 or so to get all the MCUs on a vehicle ‘upgraded’ for extra capacity.

If this all sounds a little crazy, it is. From two angles. First: do we really need as much software control in cars as we do? Marketing departments seem to think so. Second: the reason why there are so many small compute units in a car is the slow migration from mechanically controlled components to electrically controlled on. Back in the 80s the majory of automatic transmissions shifted based on a very complex mechanical system (look up a transmission valve body if you’re curious). Moving that to electronic control meant adding a computer to control that functional. Now take this and multiply it and you’ll kind of see the wreck in motion. Most OEMs are moving toward more centralized compute (fewer, larger, and smarter control units), but new electrical architectures take a lot of time/effort so it’s slow going.