For me, this is the greatest insight that is glossed over. The Unix Philosophy of reducing a program into a system of small composable parts which have a specific and FIXED functionality does more to reduce bugs and stop program rot (via unending features) than reams of tests on a constantly shifting codebase.

The problem with monolisthic codebases, even with a test framework, is that you still cant guarantee that one change in one part wont adversely affect another part. Process isolation at least limits bugs to "passing the wrong message".

Staying in the same technical stack is the fastest way to become irrelevant I can imagine. I've seen what it is like to switch everything up every few years (4 different tech stacks in 4 jobs), and the experience gained is invaluable.

The best part is seeing everything you knew from before change, except that parts that actually are beneficial. It's funny how much of a tech stack is either cargo culting or in response to a local pain point. Learning to distinguish those gives you a sharp eye, both for possible other fixes locally and for strategic direction changes.

It takes one critical ingredient though: you. You must have the humility and maturity to realize YOU ARE NOT YOUR CODE. If you want to go to a company, learn all they know, and leave, you must be comfortable being wrong, listening a lot, and keeping an open mind. Every time you make fun of a local company's choices (even if they are badly made), you'll isolate yourself more, and they will be less likely to bother explaining the next thing you are stuck on. Remember, don't complain, just build.

And whatever you do, STOP CARING ABOUT CODE FORMATTING STYLES. If you care, you'll hate every one but your "first", and you'll spend your entire social capital at each job trying to change theirs to match your favorite. Which is just about the stupidest thing you could do.

Is it even possible to become really proficient in 4 tech stacks in such a short period?

I'm a pretty fast learner and yet I feel that for actual mastery you'd need to be doing something for at least multiple years. I didn't feel I was any good at C until I had put almost a decade into the language.

Which is tough in the tech world because quite a few technologies won't even last long enough to get to 'master' level! Easy come, easy go. I'm having a hard time adapting to this Cambrian explosion of technology that for the most part seems to lack staying power. I guess that makes me a dinosaur... (or a Lizard!).

I'd not claim mastery in any of those stacks, but then again I've only been programming for six years! I'm not sure I'd claim mastery if I'd stayed in Java and Apache this whole time either. I do think I've seen enough that "coming up to speed" only takes me a fraction of what it used to.

Caring about code formatting is not binary. I've seen code that literally breaks syntax highlight in vim, and I've accepted that sometimes in this job I just have to do syntax-correction commits in order to be able to efficiently work. I'm not a perfectionist about that, but there are limits.

> Every time you make fun of a local company's choices (even if they are badly made), you'll isolate yourself more

I'd say this doesn't only apply to local companies.

Just assume that people you work with are smarter than you.

It's important to have consistent style, because once a programmer internalizes the local style - some types of bugs become transparent: the upon understanding what something is supposed to be doing, the style provides visual cues to the flows and a certain predictability in the code. When something is wrong it looks wrong.

As an aside, are there any editors that could automagically infer formatting rules (to use for indenting, folding, etc.) upon opening a file? I'm using vim but I think I'd be willing to switch for such a feature.

Two random titles 'Simoncini, L. (2011). Socio-technical complex systems of systems: Can we justifiably trust their resilience? Dependable and Historic Computing, pages 486–497.'

'Reeves, J., Eveleigh, T., Holzer, T., and Sarkani, S. (2012). The impact of early design phase risk identification biases on space system project performance. In Systems Conference (SysCon), 2012 IEEE International, pages 1–8. IEEE.'

http://www.fooledbyrandomness.com/DerivTBS.htm

Most software we build is not designed for chaos, and is thus fragile. There are lots of network distributed systems that might improve as you add nodes, but most of these rely on cooperative peers and have difficulty tolerating global scale networks and byzantine failures.

For one, software per se is extremely fragile. Variability in inputs can easily break it. New browser version, someone presses buttons in a different order, Y2K, and everything comes crashing down.

However, the overall system that includes the software and the team maintaining it can be antifragile, but it's not automatic. The team is like the immune system that fights off bugs; if it doesn't follow good practices, it can lose its ability to do so. For example, a policy of writing automated tests against bugs to make sure that do not reappear is antifragile (like creating antibodies).

Another relevant point: nothing is antifragile without running an energy deficit. It costs money to keep software working, even without adding any features.

It's got to be more nuanced than that. For example, software won't benefit from bugs being fixed if the rate of churn is very high, if new features are added rapidly and the size of the state space explodes. Times like that create technical debt. Surely technical debt isn't antifragile. Since we still don't know how to avoid it, it seems a stretch to say all software is antifragile.

The next sentences mention that.

Simple one-off programs designed at the keyboard can be so useful they get re-used and enhanced with more one-off hacks until they reach the point of utter incomprehensibility.