Elitism as the mid-career growth engine

A facility I worked at started off in low volume, high mix manufacturing (a job shop) and eventually moved into more high volume, medium mix manufacturing. What makes sense for low volume doesn't make sense when you move to high volume.

"Refactoring" happens at different levels. You can look at the entire facility, specific product lines, or specific machines. Generally you care about efficiency and yield. Safety is baked into everything you're doing, so sometimes you need to sacrifice efficiency or yield for greater operator safety.

You can have a product line with initially low sales volume, so you use less efficient or less tooling and automation heavy processes. As your volume increases, you can start to invest in new tooling, machinery, move the production to existing machines, or change the shop floor layout. For example, you can move from hand clamping some pieces for welding, dedicated fixtures / jigs to clamp and hold the parts, up to using robot welding machines for high production volumes.

You can have machines set up for batch processing as independent operations. If it makes sense through having higher volume, you can dedicate a specific set of machines and move them into a production cell.

At a machine level, you can realize that yield is too low and you can look at the design of the tooling or look at the sequencing of operations if it's a CNC machine.

Similar things happen for service operations. It makes sense to have someone manually process or copy and paste some stuff if it's low volume. Once it ramps up, it can make sense to automate in Excel with VBA and then eventually move to a more dedicated program.

This is one of the most common and traditional shining exemplars of awful code. Absolutely nightmarish stuff. Such code can only be written by someone who has absolutely no idea what programming even is. They looked at a problem and said: "You know what this problem needs? It needs a much worse programming language that I just invented, jammed into a config file." So the code was tremendously awful to begin with, and you threw it out. Good for you.

> I said look, we're SWEs, we know how to edit code.

Absolutely right: this is why we use programming languages to program, and not config files. Again illustrating that you never threw away good code; you threw away the trash.

> I'm replacing this with something centered around an if-else tree that just does exactly what we need right now and can be modified later, with little attention paid to quality. I'm not even gonna bother splitting the codebase into multiple files cause someone is probably gonna have a strong opinion about organization; that person can have fun doing that. So far that's been modified a lot in the past 3 years with ease, it's gotten the job done, and anything more structured would've broken during that time.

A chain of if-elses is probably not paragon-level code, but definitely an improvement over what you described as coming before. My overall impression is that nobody has really taken the time to sit down and really dig deep into the problem, extract out the invariants, model things mathematically, identify the important operations you need to perform, develop useful data structures to support those operations, etc. My feeling is that if it was actually set up well -- really well -- you'd look back on your current situation and cringe.

It's statements like "anything more structured would've broken during that time" that make me think you really just haven't been fortunate enough to even experience what good code actually looks like. You can't imagine the situation being better. But it can.

Does it need to be? Maybe not. Either way, this is still a story of replacing awful code with better code.

This what I was referring to. I'm not sure there are shortcuts here beyond saving some keystrokes.

As you've mentioned tests, this is one place I see a lot of people thinking they can save time not writing them out, even opting for no tests. I expect a good test suite for the average application easily doubles the number of keystrokes required, at very minimum. The code doubling in size sounds like a lot more work, but is it really in the grand scheme? You still have to put in all the same amount of thought into those tests in order to write the code (and again if you choose to manually test it). All you've saved is the effort of typing out the tests, which I don't find takes all that long.

Maybe there are some slow typists among us? If you spend most of your time clacking on the keyboard then, indeed, the number of keypresses required could become significant. But that's not my experience.