Too many software developers just know the "current thing" without knowing why it is the current thing and the specific issues that caused us to move on from the old thing. This ignorance of the past frequently encourages developers to reinvent an old thing poorly without understanding that not only is it not new but that we stopped doing it in many contexts for good and nuanced reasons.

I think this sense of history is one of the most important aspects of "experience" when hiring. It is easy to train someone on an arbitrary tech stack but difficult to train someone on the history and path dependencies. Many developers are not interested in that history because it doesn't feel relevant to doing a job now. We tend to gain this sense of history by being in the industry long enough that we were part of that history.

Practically speaking, knowing the hows and whys of obsolete technologies makes it much easier to learn new the new stuff that is coming tomorrow as well. Everything is built on what has come before.

I see many "kids these days" who not only don't know the history, but actively think that knowing it is a waste of their time. It's a shame, because that attitude is a handicap. I also take it as an indication that the person doesn't have an interest in the field for its own sake.

I can tell you that in my experience employers do not value this kind of knowledge a lot. Quite the opposite: quite some employers hate such employees who ask "too many inconvenient questions" instead of surfing the hype of the "current/next big thing".

In my experience, startups with inexperienced technical leadership tend to be the “next big thing” (as far as tech stacks go) focused types of places.

That is more or less about virtue signalling that you are a "team player" that helps your boss advance his career rather than doing what nominally is your job. Think teenage clothing fashion. You need to show you are in.

Pretending that complex and risky solutions are needed is a key property of this. The boss need headcounts for the complex fancy project.

And so on, with different companies being in different circles of hell on the matter.

Good solutions usually look simple and easy in my experience. Downplaying the skill in doing them.

The author however seems to write about machine learning, which honestly is a really fast moving field right now. Sometimes things just move fast?

I agree with this, but I also have real frustration that so often, as an industry, I see big pendulum swings along the lines of "that old thing is bad, let's do this new thing that solves many of the problems of the old thing." Except that engineering is usually about balancing tradeoffs, and oftentimes that new thing leaves you with a different set of problems that the old thing fixed in response to the old-older thing.

Microservices were probably my best example of this, where companies were frustrated by the issues with monoliths so they said "Aha, microservices solve all those monolith problems", except microservices come with a whole slew of difficulties of their own, which in my opinion are often more difficult to manage than the problems with monoliths.

The industry's love for a hot minute when all these NoSql DBs first came out (i.e. around when Mongo came out), only to later find out "Hey, the ACID guarantees in RDBMS transactions are actually pretty essential a lot of the time" is another good example.

One bright spot is that I feel like the industry has matured somewhat when it comes to searching for these silver bullets. All frameworks and tech have pros and cons, and when you solve one problem, don't be unaware of the new problems that will create. E.g. sometimes you still see some "Do it all in the cloud!!" vs. "No, you lose control when you do it in the cloud, you should own it all", but I think more commonly you see reasoned responses along the lines of "it depends".

https://spectrum.ieee.org/an-engineering-career-only-a-young...

> Given a choice, many employers would rather hire a couple of inexperienced computer programmer and spend a few months training them than hiring (or retaining) a more experienced but expensive programmer.

In the very next paragraph:

> In addition, many employers aren’t interested in providing training to engineers or programmers who may start becoming obsolete, for fear of seeing them leave or be poached for employment elsewhere. [...] employers looking for experienced workers have fallen into the habit of poaching employees from their competitors as opposed to spending the resources to train from within their organization to meet a specific job skill.

That directly contradicts the preceding paragraph, so I find it hard to trust the other claims that it makes.

If large companies need to train someone (typically on a company-specific toolkit) they want to train someone with more room for optimism in their workplace expectations, fewer points of comparison for the quality or utility of the toolset, and who will have less of an ability to exit post-training.

>That directly contradicts the preceding paragraph,

The "many employers" can be 2 different subsets of employers and/or 2 different tech stack situations. Examples...

Subset (1) FAANG or "tech" companies will train on specific in-house technology stacks for younger new hires. The "inexperienced" was in referencing "young". E.g. Apple hires fresh young college graduates that only did Scheme and Python in school but will train them on Objective-C and Swift so they can work on macOS and iOS. However, Apple typically doesn't hire older experienced COBOL programmers to re-train them in Swift.

Subset (2) companies that don't train new hires (many non-tech companies where IT/dev is a cost center). They usually don't recruit from college campuses and prefer the job candidates to have existing skills that already match the job listing. E.g. a hospital IT's department has a job listing for a Java programmer to help maintain their billing system. The hospital is not interested in a candidate who's skillset is only Turbo Pascal and Macromedia ColdFusion and retraining them on Java.

Maybe they were trying to make a different point, but that's how I interpret it.

The first paragraph is about training inexperienced computer programmers to do things their way. It's a point frequently made that more experienced programmers don't just need to be trained in the new company's ways, but often need to be untrained from their previous ways -- yet they still cost more. So this isn't about "industry-wide" training, it's more about how company-specific training.

While the second paragraph is more about training relating to transferrable skills. Companies don't want to teach people to become data scientists or ML experts -- they'd rather hire people with those skills already.

Perhaps it helps to think of the first bucket as "generic" programmers, the ones writing CRUD apps or websites or similar. While the second bucket is about "domain-specific" engineers.

I wonder if the so called knowledge half life exists because everyone is working in very niche, specialized area these days. Those skills are simply less transferable to even similar jobs in the same field.

People tend to fall somewhere on a robot/ninja spectrum.

The observation that employers have multiple motives that are in tension is simply human.

Let us understand "loyal" as "not very willing to switch jobs" (and not in the sense of "submissive"/"obedient").

(Loyal) autodidacts are still a nuisance to many bosses, because autodidacts, nearly by definition, often have a very strong tendency to "think autonomously". Thus they have a tendency to question a lot of (technological, architectural, ...) decisions - often for good reasons (and if they are experienced autodidacts they often also the background knowledge to support their reasoning). In other words: autodidacts are commonly less ingrained in "the way things are usually done", which can easily lead to conflicts with bosses "who love to boss around".

- focus on the fundamentals rather than the particular brand of tools. HTTP, tcp, HTML, OS, CPU, filesystem, etc will almost certainly out last a language, framework and SaaS

- See beyond the assumptions. Solutions are based on assumptions of current problem. Solutions come and go but the fundamental problem of, for example, go from a place to another, rarely change. Try to distill THE problem.

- focus on outcome rather than action. Ask ourselves why such and such actions matter. Do we know why are we implementing a thing, or if a thing we implemented 6 months ago matter at all.

All of these demands consideration beyond do you know "dewalts" or "bosch"

Umm, you are just picking survivorship bias tech things.

Focusing on html was a good choice. Focusing on xhtml2 or vrml would be a bad choice.

HTTP will serve you well. FTP or Gopher not so much.

TCP is a better choice than IPX or SCTP, etc.

Ultimately though, i think the point is to focus on the underlying ideas. You should understand transport protocols not tcp specificly, then you can easily apply that knowledge to QUIC or whatever.

> The Lindy effect (also known as Lindy's Law) is a theorized phenomenon by which the future life expectancy of some non-perishable things, like a technology or an idea, is proportional to their current age. Thus, the Lindy effect proposes the longer a period something has survived to exist or be used in the present, the longer its remaining life expectancy.

https://en.wikipedia.org/wiki/Lindy_effect

But anyway, my take is that the problem the article is describing is caused by the existence of way too many fundamentals that can't all be practiced.

There are those that have resumes tailored to a single particular thing that if hot right now, will have 1000 recruiters after them to run certain grid studies. I'm more of a fundamentalist (need to think of a better term)for my field where I can tell you the underlying math behind most of the studies performed, familiar with the pro/cons of a dozen different application softwares, can code, use SQL, Linux whatever. I'm also a people person, which is helpful as there is a lot of stakeholder interaction. If you understand the equations/theory and how all the technical junk works....there aren't many roles in my industry I can't get up to speed on in very little time, while having a global understanding for how it fits as a cog in the bigger machine. This isn't true of most in my industry unfortunately. Many many only know a single role, have experience with one tool, don't understand the math behind the tools, can't code or do data analysis... etc.

I've found the broad/general experience to be very valuable, but it's harder to convey that to recruiters sometimes that are looking for "X". I sometimes have to tell them that what I have is highly transferable to "X" and that I have a bunch of other goodies their employer would be very interested in. Sometimes it works if they're communicating with the manager looking to fill the role and not HR. If I can actually talk to someone at the company.... usually not hard to arrange, then they've often offered to make a custom role as well. I know it always isn't the same for software shops or large companies with layers of beauracracy, but that's my experience.

"I tend to focus more on the fundamentals".

But you went on to list a bunch of tools. Sure today HTML, TCP, HTTP seem fundamental, but when they first came out?

CPU is very open ended, what do you mean focus on CPU? Do you mean x86 or do you just mean that there exists a concept called a central processing unit where bits go in and bits come out?

With that said all I have to say on this issue is that there are different strategies to learning, and for some people such as myself, I prefer learning things from the concrete and towards the abstract. I like starting from the actual tools and frameworks and very specific and particular things I can manipulate, and then abstracting from them and building up concepts, as opposed to what it seems many others like to do which is to start from high level concepts.

If someone understands trees they can understand html in one sentence.

For example, the evolution and development of the Internet technology in the 1990s occurred at an incredible pace that is as fast as anything I've seen since, but back then you could switch to being e.g. an Oracle DBA if you wanted to avoid the chaos, and many people did. Those safe harbors have become rare in tech and the relative pay for them declines every year.

    Enthropy is increasing.

If you want deep knowledge you can't have broad knowledge. It follows from this that, eg AGI is deadborn; but then specialized AIs have huge potential. This should be the scary part, not the utopian know-it-all Mechanical Turk / HAL / Marvin.

Speaking of the latter, we will have little use for an AGI anyway as such a thing will be way out of our league and we will not be able to use it, as D Adams famously postulated: "Here I am with a brain the size of a planet and they ask me to pick up a piece of paper. Call that job satisfaction? I don't."

I really don't like this analogy. You can weld glass back together. Or melt the pieces down and reforge it.

Analogies are always breaking down but break down faster if people don't just try to see them as analogies rather than the thing itself, the idea was to convey a point and you indicated that you got it perfectly well.

It is a mug's game trying to master a tech stack anyway. The clever thing to do is master problem domains. Then if you encounter the problem you can just solve it using old tools and be happy.

its very easy to retain a significant portion of the knowledge by building mental models. sure you will forget about the API surface of a technology, but you would surely remember the underlying knowledge models and you would surely apply it in many other contexts.

like remembering the REST API inputs and output data types is also a knowledge whose half life is much shorter. but building mental models of those would stay for a long time. the point never is to remember and include REST API input and output data as part of your skill set, the point is to include their underlying knowledge. and you can't treat the API surface of a library as knowledge, its essentially a volatile memory and supposed to be cleared away

When you know the basic "underlying" model, switching from a framework or language to another is not a very big deal. Not much bigger deal than figuring out a new large codebase with a familiar framework/language.

Sure, it may take a few weeks of learning new stuff and being unproductive (or even negatively productive) during this phase, but this is to be expected in any job.

I don't think learning the more fundamental concepts is that hard but it does require some time (and interest) that is not immediately productive. Perhaps due to demands of being productive, as in churning code, all the time gets people (and the industry) to get stuck in such "local optimum".

Arguably a lot of the ways modern software sucks is a direct consequence of developers not understanding the tools and languages they're using. It's a bakery that bakes bread by scraping the toppings off frozen pizza.

So despite the fact that knowledge may have a half-life, it may be even more important to acquire the skills to learn that knowledge.

https://news.ycombinator.com/item?id=38590888

I think its kind of like the difference between being up to date with latest slang vs knowing how to read well.

I'm building a learning focused note taking app for this very purpose - https://www.wonderpkm.com/ , would love to chat further with you about your learning approach!

My own solution to this problem has been to work in startups for 2-3 years and then move on rather than try to seek a well paid job at a large, prestigious company.

Why? I started my career at one of these brand name, "everybody wants to get in" kind of companies that hadn't made institutional layoffs ever. When time came to do their first mass layoff, I saw people who had spent their entire careers at the company lose their jobs unemployable because thy had essentially become bureaucrats.

Startups offer you the possibility of "on the job training" for the most recent technical stack. And precisely because there are too many people with golden handcuffs at the large companies, good startups are a bit easier to get into (not "easy", but "easier").

The downside is that 90% of startups fail, and you need to live with that. At the same time, if you happen to work at one that succeeds spectacularly, you won't have to worry about making a living until you die.

It's not directly about getting skills that will land me a high paying job (via... marketable resume keywords?), it's more about trying to understand the fundamentals that no PL or framework trend, or social current, can obviate.

I find 30 minutes a day of supermemo, supplemented by an hour of purposefully randomized review on weekends keeps even very old topics near the forefront of my mind. It's like having a well-maintained toolbox I can throw at different problems at any time. The slight daily effort is more than compensated by the retention gains I've noticed over time.

I do feel like the culture of tech has become one of maintenance not being part of what we do. When was the last time you saw someone get promoted for "cutting costs" or "making the code less complicated". When was the last time you sat down and read someone else's code and were impressed at how CLEAR and SIMPLE it was?

20 years ago we were all running on bare hardware. Now it's a hypervisor, with a VM, that has a docker container, that imports everything and a cat. We get tools like artifactory to make up for the fact that all of that might disappear. Top it of with zero ownership (infrastructure as a cost center and not a depreciable asset).

It feels like a fuck shit stack of wet turds and were trying to play jenga with them, shuffling them back to the top and trying to get our next gig before the whole thing falls over and hopefully lands in someone else's lap.

To make a point: do we need docker? No, but writing installable software is hard (depending on language and what you're doing). Docker doesn't fix the problem it just adds another layer in.

The original service is the database. Yet we dont normally expose it because its security model remains rooted in the 19xx's. So we have layers of shims over it, ORM, JSON... pick your stack and "scalable" abstraction.

The author mentions LLM's. The more I play with them the more I feel like this is going to be cool after engineers beat it into submission over the course of the next few years. So much opaque, and so little clarity on what is going on under the hood. It's no wonder people are having trouble coming to grips, it's a mess! If it were a battery break through it would take 10 years to turn it into a mass producible product, but because its software we throw money at it and let it dangle out on the web!!! (and I dont fear AGI)

FTA: >> I don’t have a prescriptive solution for this. I wrote this text to start a discussion around a feeling I previously struggled with but didn’t know how to label.

I do. We need to do better. We need to stop piling on more and strip back to clear and well understood. We need to value readable code over DRY, or Design patterns or what ever the next FOTM is. We need to laud people who make systems simpler, who reduces costs, who reshape and extend existing things rather than build new ones and pile more on top because it's "easy" or looks good on the resume.

I am part of the problem too, and I need to stop. I need to stop reaching for that next shiny bit of tech, next framework, next library. Because acting like a schizophrenic ADHD child finding candy hasn't really served anyone.

A lot of the problems, associated tooling and "best practices" you mention arose as a result of the VC bubble from the last decade, where the primary objective was not to solve the business problem but to manufacture complexity so the next VC round and large headcount could be justified.

Sadly, this is not limited to VC - either collusion or technical incompetence is rampant at the executive level, which means crap vendors can nevertheless get their "solutions" into companies and lock them in. Do this long enough, and entire careers start relying on these "solutions" so you get a guaranteed supply of people who can collude with you to bleed their company dry.

See also:

* cloud computing

* blockchain

* microservices

* resume-driven-development

Also I'd like to kindly ask you not to use "ADHD child" in that manner because I think it stigmatizes it although I do understand the point you were trying to make there.

AS for the ADHD thing, I get it, it's also a pretty accurate description of how I feel some days working in this industry. Its hard not to be a technological magpie collecting shiny rocks!

I really valued their insight and perspective (rural China by motorcycle, for example, is not a common perspective in the west), but eventually had to unsubscribe from their toxic bitterness.

Your in a place that is more rare than you think, a lot of us have experiences more like this:

https://news.ycombinator.com/item?id=38069710

I think this is a slippery slope. praising is fine, but aws bills is essentially a non-functional quality attribute of the software. the job is to never even let it become a problem in the first place

what about teams that have built their software in time and with quality, are they essentially losing one of the opportunities to get promoted because they built a better software in the first place?

it's the economically rational thing to do... you woudln't want your kids to have a boring future

gota leave some problems to them, heck cause some because we didn't know any better anyways

Writing installable software doesn't help with isolation, self healing and scalability. In a microservice world you kind of need Docker/Kubernetes.

Your system's scalability is completely defined by how you architect it, and Docker changes nothing.

And WTF is self healing? Docker can't fix any ops problem that it didn't create.

The gp you replied to mentioned both "Docker/Kubernetes"

It's the Kubernetes management layer of Docker-style containers (in pods) that helps with monitoring and restarts: https://www.google.com/search?q=kubernetes+self-healing

This sentiment is common in people that lack understanding why each of the stack elements currently in place has been put in there for. I'm not picking on parent specifically, but having been working for "big tech" for quite some time I'm meeting young-er people that are starting their first gig in a "big tech stack" company(at a senior position due to their entire 5 years of experience) and their first instinct is as the above. "Why are you using all this crap? Just rip it all out and start from scratch!

No

I was like that a couple of times in my career and being more convincing I was allowed to" rip it all out" on more than one occasion. A year later my system was better than the original, but by the time I finished it was already out of date with "modern practices" and during that year I rediscovered every single seemingly stupid decision I saw made in the original system.

Now, when I see something that doesn't make sense that looks like a mind boggling tech stack doing almost nothing(and yet it works well) I ask myself, what is it I don't know about this. What documentation is lacking/out of date? (all of it usually). I then dive into the source code and learn why things were done the way they are. Also knowing how the entire stack works from the bare metal to k8 and "server less" helps.

If I was an educator I'd make up an It curriculum teaching the basics of how computers work with something like basic on 8 bit, later assembly.

Then I'd go through features of modern hardware, multi-cores, caches, etc.

Then networking basics with focus on low level protocols "tcp/Ip Ethernet, vlans, vpns". With some layer 7 stuff added like HTTP(S),SMTP etc at the same time as OS level knowledge based on Linux on the console and Windows Server is introduced(as well as bash/powershell/python scripting) . I'd have students code simple servers/clients, stand up their own SMTP gateway and Web server on bare metal. Data science should run from this time on too.

Only after they've been using and learning on bate metal for at least a year I'd start with hypervisors. Teaching things like distributed switching, more advanced features like FT and HA using virtual machines. Also NAS and Sans at this stage.

Then and only then comes containers and k8 at the same time as serverless and cloud. Then topic like resilience, meeting SLAs, SLOs (risk calculation) , business continuity, DR in depth, etc

As mentioned before few things should be thought alongside this throughout, probably java programming, data science with python. Maybe ML basics.

I don't know what is thought on It courses these days, but I strongly suspect not what I listed above. /rant over

The same concept can happen with coders. They don't have an understanding and purpose for code outside of the computer, and they code reactively. Therefore it is easy for them to forget.

It is also worth noting that the culture and electronic lesuire has become very mentally consuming (if you allow it to be). It is possible to use electronic media so much that you forget code.

Knowing how you got to Z from A is valuable knowledge too. Not just in changes to the old stack that is now new again, but to your own knowledge and journey.

It’s ok to not be the smartest person in the room. It’s ok to admit that you need ramp up. What’s not ok is to go around claiming to be an expert and spout inaccurate facts so you’re already one step closer to being awesome in stack A again.