by notaboredguy on 12/7/23, 12:49 AM with 80 comments
by jandrewrogers on 12/10/23, 4:41 PM
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.
by joshuaissac on 12/10/23, 11:51 AM
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.
by a_c on 12/10/23, 12:27 PM
- 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"
by jacquesm on 12/10/23, 4:03 PM
by aeonque on 12/10/23, 4:19 PM
by yetanother12345 on 12/10/23, 9:16 PM
Enthropy is increasing.
Things that used to be in one domain will in time split up into multiple, each having a higher level of detail / sophistication than before. Or, that one domain will die off, possibly being replaced by "something else". This can not be reversed - "you cannot unbreak the broken glass" (It seems that we need to be able to reverse our direction in spacetime to do that, and I believe that is considered a hard problem.)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."
by roenxi on 12/10/23, 12:20 PM
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.
by eightnoteight on 12/10/23, 9:48 AM
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
by nemoniac on 12/10/23, 11:44 AM
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.
by bawolff on 12/10/23, 3:30 PM
I think its kind of like the difference between being up to date with latest slang vs knowing how to read well.
by derrickpersson on 12/10/23, 9:33 PM
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!
by idkdotcom on 12/10/23, 2:12 PM
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.
by epgui on 12/10/23, 1:14 PM
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.
by lauriewired on 12/10/23, 8:06 AM
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.
by zer00eyz on 12/10/23, 8:42 AM
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.
by barrysteve on 12/10/23, 7:32 PM
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.
by madaxe_again on 12/10/23, 8:24 AM
While there’s certainly currently an accelerando going on in terms of knowledge growth and change in many fields, there is also bias built into us and our perception of the world - every human has a tendency to be surprised by the degree of change that occurs in their lifetime - we are raised with the world presented as-is, with a static set of truths, yet the only constant thing about the human world is change.
by reactordev on 12/10/23, 5:11 PM
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.
by csneeky on 12/10/23, 2:27 PM
by vaidhy on 12/10/23, 8:35 AM
It might be half-life of his retention, but not half-life of knowledge.
by DeathArrow on 12/10/23, 9:30 AM