hinkley

I wonder what shovels were worth after the Gold Rush faltered. Blacksmiths probably had all the scrap iron they could ever care for.

That was why they wanted to store nuclear waste in a hole in a mine in Nevada, but then someone found a fault line that we didn't know much about.

Those started with money changers and long distance travel did they not?

Before phones, if you moved between two affluent areas there was enough surplus capital in both that instead of hauling a heavy chest of silver coins between them and risking getting Robin Hooded you turn your coins in at one end of the trip and get reimbursed by a fellow in the same money handling cooperative at the other end, and then they would square their books through traders moving money the opposite direction or if necessary by armed escort.

There are MMO economies that either ban the flow of real money into the game, or only allow it to enter the game and not leave. In the case of the latter, poorer players trade their time and skill for something transferable in the game, such as rare items, or in the case of Eve Online, one free month of play time. There are Eve players who only ever payed for the first couple months in the game and then found a revenue stream that was subsidized by other players buying excess play time and selling it in-game when the demand drives the price up high enough to be attractive.

Odd that a terrorist attack achieved what historical knowledge of flood and earthquake damage did not.

You’ll see this as a plot device in some Regency pieces. Someone gets ahold of the physical deed to a property and now there’s drama.

My ex was late from work once a week because the company did commercial real estate logistics (sort of similar domain here) and she had the job of going to the secure data center and grabbing a backup disk out of the cage and transferring it to a safety deposit box.

The dumb thing was the bank was two blocks from the data center and less than eight (six?) from the office so catastrophic events might have hit both or all three. The owner kept a second copy at his house, and that was the only geographically separated copy.

For me the first 2FA devices I’d had were for work but for my friends it was for a world of Warcraft. And it was years until my bank offered 2FA. I still think about that every time there is a breach.

Blizzard gave hardware tokens out to the entire convention one year. Smart phones became a variable not long after and then they didn’t make them mandatory but game guilds almost universally did. Especially for officers.

When I worked at a stressful place I was worried not only of our version control getting damaged but also someone deciding they had had enough and doing damage on their way out.

I had a copy of our code on media in my desk labeled “promotion” and updated it every month. In retrospect someone going through my desk would have assumed blackmail material and been disappointed to find only code.

It annoys engineers and causes inefficiency.

No, no, and no.

It causes unforced errors which damage your relationship with customers.

Burnout is a combination of wear and tear and lack of impact. Having giant footguns laying about facilitates the former. And I’ve been in arguments where people disagreed about time zone information and that is not good for interpersonal relationships. It’s not about efficiency it’s about turnover.

Jack lived long enough to become the villain.

Motorola will tell you that they invented Six Sigma and Welch copied it. They also made Digital Six Sigma and that community was a cult.

Everyone has to learn how much feedback they can give in a code review without making an ass of themselves. The code isn’t right at the end of that, it’s just less wrong.

On the first project I had with routine code reviews I learned to wait for one or two others to file their reviews and then I would catch everything they missed.

It was an app with too many interactive components on top few pages so perf issues and footguns were both a priority. That generates a lot more comments on CRS. There were two of us doing all of that work and the other had English as a second language so he tended to point out one or two issues and let the rest slide.

And you're going to right that wrong by making assumptions.

It's usually not the person who gets asked who acts like an asshole, and if you don't don't want to be judged by people for your behavior, start by not openly and loudly judging them for theirs.

No sympathy for this sort of behavior and you're out of line. Or you're the problem. I'll let you decide since I don't know you.

There are some people I'm not friends with anymore who didn't understand conversational bidding. They would jump straight to Why Don't You Google That and shut down any conversation we might have had.

Yes I could get some of this information off of IMDB or a DIY video but I'm looking for color commentary and regional advice, and also in some of these situations, the people I asked know me. They know the sorts of things I don't need help on and the ones I struggle with. So maybe they can tell me this movie or trick isn't for me and I should try this other thing instead. Or which store I should go to for this.

Tap to pay probably doesn't help with getting people into the alley but probably helps with 'one more game'.

Your beginners have to come for shoes anyway, and the pointer to which lanes to take (you don't want them taking a lane at 6:30 that's reserved at 7)

When I was in a junior league we were at a relatively recent vintage alley and once in a while it would glitch and reset the pins twice in a row. I bet the relay stayed closed too long.

Short repairs are always nice, but I'm curious about the frequency. You're your own repairman, but that won't be true for all owners. So it's not if the repair takes 5 minutes, it's how long the lanes are down any time there's a problem.

I wonder what sort of things you could do to harden the system. From potting to overbuilding to redundancy.

There's a woman I read about a while back who did here PhD thesis on the notion that David Hume's contribution to the Enlightenment was inspired by conversations with a Jesuit monk who had returned to France from a long engagement in a Buddhist area of India. DDG is telling me it might be Allison Gopnik but I've no recollection of the name, only the contents.

She proved that he made a trip to a town where the monk lived after his return, and the library contained a copy of his reports. She could not prove more than opportunity but she strongly suspects that Hume not only read the report but may have met with the monk as well.

Bike shedding means no decision of consequence is made. People wanted to participate in something, and they sucked all of the oxygen out of the room for other decisions.

It's that important decisions were either not made or got insufficient scrutiny that's the problem. So aggressively shutting down bike shedding that is actually bike shedding by picking a solution and moving on or tabling the discussion to let a team of 2 solve it offline is what you're after.

Sometimes though, bike shedding can be a delay tactic. We have a decision we are not ready to make that someone is forcing a vote on, and there's a silent conspiracy to derail the conversation to avoid the vote for one more meeting.

And then there's people learning not to be responsible for anything, either as a career choice or due to previous trauma at this business. So they are asking for too much input so any consequences are not their fault alone. As you say, being a coin flipper in such situations becomes its own soft power. I've worked at a couple places where a handful of people clearly followed my advice solely because they knew I'd say it was my fault if things went wrong. They just wanted a Decider and I sounded like one so they did things the way I wanted them done. Their motivation was to avoid having to deal with being yelled at. I did my yelling in private, instead of turning it into an opportunity for public humiliation.

Let me rephrase that. I've seen a few cases where it became a major issue, rather than just being a fact.

Often people are smart enough to not ask questions they don't want the answer to. If the three people trusted to handle a problem all are in agreement as to how, then the peanut gallery may just be confounding issues in order to pad resumes or to feel important and involved.

I don't know what the black art of tool selection is, but I'm at least a couple std deviations above average on picking libraries that have legs. Nobody gets it right every time, but some people seem to get it wrong every time.

Be sure the work is given to someone who puts some intention into tool selection and you'll probably be okay though. We don't need three different tools doing the same kind of tasks. But sometimes the old old stuff gets moved to the new tool because the old tool couldn't handle that scenario.

Always fun when they manage to categorize it wrong 3 times in a row.

One of the hardest parts of my job is trying to convince people where the pool of blood on the floor is coming from. We are forever stitching up the wrong wounds and missing others entirely.

Pain sneaks up on people and they often don't realize they're in pain until someone takes it away. This is probably why Refactoring is one of my favorite tech books. It's a set of tools and justifications for chipping away at that pain bit by bit, instead of tolerating more and more while productivity grinds to a halt.

At the end of the day, if only three people really have to care about a thing and they're fine with it, is it their business to run the project the way they prefer/tolerate? It does matter if the opportunity costs and externalities are affecting other projects. If they don't have time to work on other features because of the mistakes they never correct. If other people's flow is constantly interrupted trying to work around their quirky stuff. But if we don't see any of that, or only rarely, then it's more that my internal architect trying to be bossy rather than lift all boats.

I've been doing this a long time and I've rarely seen a separate team and budget for maintenance.

Except for "all of the original team left and we're just here to keep the lights on."

I think it's important to distinguish between situations where the business intentionally made this decision from ones where it was forced upon them. Because the delusion of thinking we can still go on after we scared off all of the people who made this thing leads to a very different dynamic.

In addition to Second System Syndrome that has already been covered, I think there are several other things going on here that lead to the tug of war.

In another reply I already mentioned a flavor of Sunk Cost, which is resistance to any change to the code that 'made us successful' because they consider they have already won and taking it away now is some sort of revisionist history effort instead of just Progress. Hofstadter's Law, which tells you we still have plenty of time, despite three initiatives already having finished long past the point of maximum tolerable pain already.

But more damningly, I have worked with a lot of people who want to skip from Make it Work straight to Make it Fast without Making it Right in the middle. Those are the people who, among other things, reach for caching too early, and then declare the war for cost reductions over before they've even started, because there are no perf analysis tools that can see past and around the caching logic to find the issues that caching either didn't fix or made much much worse.

I'm not advocating for making hot decisions at every point along the way. I'm advocating for people having enough experience and foresight to understand which 20% of the code flow is Architecture from which is just feature factory work and making sure that 20% gets 80% of the design thinking and timely preventative maintenance.

On a couple projects I've just done all that myself. But it is a quick road to being a bottleneck and then to burnout. You have to aggressively recruit people to be bus numbers on all of those things. This is part of why I do so much mentoring.

This is what usually happens if you let incompetent people make design decision: they stay with the first and worst version forever.

This is what usually happens when you confuse the decisions that mattered from the ones that didn't. It's like back before 'just use a linter' was the solution to code formatting. You'd start a project, you'd have the 'code style meeting' and everyone would bash themselves into the rocks of whitespace and bracket placement, and never get to things like code organization, structure, and naming of things.

So then you end up with code that uses the same noun in three places to mean 3 different things and uses it as a verb in a fourth.

You only get so many opportunities to really change the direction the boat is steering and you can wear out your welcome trying to exceed it. If you get some things right they'll let you do a few more.

Amazon unfortunately downplays the value of ethics over numbers, and we see how that has turned out. The numbers say that counterfeit goods are just fine.

When you first introduce the idea you'll find a bunch of people think decisions are Reversible which are not, as you say. And the flip side of Reversible decisions is the Last Responsible Moment, which runs afoul of Hofstadter's Law, and people wait until halfway past the last responsible moment.

The key to reversing a decision is getting over Sunk Cost, to start thinking of some code as scaffolding. Scaffolding allows you to get on to other work and then remove it after, because it's either not needed or the 'real' solution has been installed. People get defensive when you propose to rip out their code. Hey that code made us $250k at a time when we were about to miss payroll. Yes. It did. Thank you for your service. But now it's costing us $30k a month and that shit needs to go.

Getting people to figure out that if a decision is important, making it later is actually the sane thing to do, is a challenge. Because many people's intuition is that we should put energy into this now while it's fresh and we have abundant energy. We can 'solve' it and not have it dangling over our heads. But we don't know the right answer yet. We don't know the strength of our tools or the expertise of our coworkers.

The product roadmap is now and has ever been complete bullshit. Refactoring teaches that you amortize rework across all new stories. That's just how it goes.

(And everything should be in GMT unless you can literally point me to a several hundred page treatise on why another time zone is the correct one. Yeah I've worked west coast places that got bought by NY or Chicago companies and it's a clusterfuck if you both didn't use GMT)

— Day 1-2. Tried $tool out. Oh boy! We have some work to do.

— Day 3-5. OK, there were a couple of solid bugs there, and a fair number of what were technically bugs, but not actually all that bad.

— Week 2. I guess that was it?

There are a bunch of tools in the developer toolbox that some people never use, and the opposition use religiously. We are especially bad in this industry at turning things into a boolean where they should be a dial or a continuum. Something about that intro to Logic class either rots our brains or works as a filter to keep most of the philosophers out.

In sports there are drills one does a couple times a month instead of every day. You're trying to harden pathways in the brain to make certain reactions be more automatic, to correct subtle errors and suboptimal answers to problems. You don't do them all the time because they're expensive in some way, like time or danger.

I think this is an area where we miss a lot. I don't do TDD all the time. Maybe a week every couple of months. And it's a split between very hard tasks and very simple ones where I practice it. It's easier to work on first principles on a simple problem, but sometimes when you're stuck on a very difficult one, you have to go back to first principles anyway.

"Difficult" can be further broken down into several categories. 1) I don't know how to solve this, 2) the problem is straightforward but arduous and I don't know if I have the stamina for it, 3) I thought I solved it but it's not working.

TDD is a good way to get yourself into bottom up thinking and 'work the problem' by testing your assumptions one at a time. At the very least you have something to show for your work at the next standup even if the answer still eludes.

Similarly, a linter can be good while you're building up muscle memory for writing code the way the current team thinks it should be written. However, it can be a nightmare when you're trying to do exploratory development to fix a bug. I've landed PRs on two different FOSS projects to run the linter after the unit tests for this very reason. I don't fucking care if the code is Clean right now I only care if I've fixed the NPE that is crashing production. The PR is a problem for an hour from now. I need to make it work and then I can make it right.

A bit of an aside, but after someone introduced me to the notion of Reversible Decisions, it quickly became apparent to me that the solution to the bikeshed problem is to throw money at it before the roosters can start preening about which color the shed should be.

Decisions that are reversible should just go with the instinctive answer of whoever volunteers to work on it.

I've been in many meeting rooms where, because of the number and caliber of people in the room, we've blown $5000 worth of combined salary arguing about basically nothing. I've been in a few where that number was well over $10k.

If you're going to assign a relatively medium talent engineer to solve a problem, it's cheaper to let them solve it twice, maybe even three times, than it is to try to figure out what the right solution is before touching a keyboard. It helps them grow to give them that autonomy, and more importantly training your team out of reflexively reaching for optimization for every single feature saves gobs of money over time.

The interface for a piece of code matters to everyone. The internal implementation details mostly matter to the bus number on that code. If they're happy with it, that matters a lot. That can be overridden by the consequences of that design, but I've seen a couple cases where the bus number for a module wanted a solution with fewer consequences but the group wisdom wanted something flashier but also more brittle.

Also the same Rivest as Cormen, Leiserson and Rivest (that Stein dude was after my time), and the R in RSA.

Sounds like it. I wasn't familiar with how python does this but it looks like the identity operator is 'is' so while someone could definitely screw that up, it would stick out more in a code review than == versus ===