20 ms·
> In the nineteen-twenties, an engineer’s “half life of knowledge”—the time it took for half of his expertise to become obsolete—was thirty-five years. In the n
by jeremyjh 9y ago
> In the nineteen-twenties, an engineer’s “half life of knowledge”—the time it took for half of his expertise to become obsolete—was thirty-five years. In the nineteen-sixties, it was a decade. Now it’s five years at most, and, for a software engineer, less than three.
This sort of mythology is NOT helping. An experienced Software Engineer has valuable skills that do not age at all. Yes there are new languages and frameworks we have to learn, but if we apply any effort (and we've stayed current over the years) that happens really quickly because we're just integrating all the knowledge we already have around a new set of features.
- BatFastard 9y ago60 year old dev here. I have been living on the cutting edge of tech for 30 years, and I have many scars to prove it. New is usually not better if you actually want scalable, maintainable, and monetizable results. I disagree that many area's of my knowledge has a half life. My deep understanding of network protocols hasn't aged. My deep understanding of SQL and NoSQL databases hasn't aged. The principles of distributed systems haven't changed, but they have been given more tools. When, where, and how to optimize hasn't changed. Debugging, naming, and design whether it be functional or OO hasn't changed. Sure there are new tools and methods, but I say the fundamentals are the same.
- FussyZeus 9y agoMore to the point, in my experience training more than a few college grad devs, what I look for in hiring isn't any particular language or technology, I look for someone who knows how to think like a programmer. That's something incredibly hard to teach, but if you can find someone who already has the thought processes in place for how to turn intent into code, that's 90% of your training done right there, and the remainder can happen largely with googling, stack overflow, and good code review from more experienced devs. I'm not knocking coding bootcamps or colleges, I've had hires from both. I'm moreso saying that the idea that a programmers skills are isolated to the code they currently can write is a little shortsighted.
- SmellTheGlove 9y ago> Sure there are new tools and methods, but I say the fundamentals are the same. Absolutely. Folks need to get their heads around software engineering as a practiced discipline. Your education is about the fundamentals of how you think and approach, even if the tools themselves change over time.
- ataturk 9y agoOh man, how do you even do it? I'm 44 and looking for the door! My motivation to put up with the same bs year in and year out isn't there anymore. The pay isn't worth it, either--if I could find some "no load" type role at half my pay I'd be gone tomorrow. It doesn't help my outlook that sites like this limit me to only 2 comments per hour because of the way I cast this whole industry in such an unfavorable light. Dog eat dog.
- pizza234 9y agoThis is a sensible perspective, but the job market is actually the opposite of sensible (in a way). Paradoxically, the (again, sensible) attitude that fundamentals are the same with a different coating, will distantiate one from chasing the latest fads... which is actually what the [majority of the] market looks for.
- user5994461 9y agoThe job market for database and networking skills is pretty different than the market for web apps. There are places where you get a job because you want to rewrite everything, and places where you get a job because you didn't suggest to rewrite anything.
- BatFastard 9y agoI agree on the market being crazy. Does any employer in the world interview people with real world skills?
- Swinx43 9y agoThis mythology leads directly to horribly created software that will either ensure many terrible security breaches in the future or the continued proliferation of "magic" throughout a product. One of the issues is using the word "engineer" for any of the brogrammer types. an engineer in any other proper engineering discipline does not become worthless with age, their experience actually counts for something. Somehow we have confused people who stitch together software from pieces of "magic" that they do not understand with engineers. The work I did in my 20s cannot even begin to compare with what I am doing today in my 30s. Those years of experience really makes a massive difference. It is time people are honest about ageism and simply states the real reason they prefer fresh grad or 20-something brogrammers. It normally boils down to those people being willing to work longer hours for less money. At least in most of the cases of ageism that I have seen.
- Harvey-Specter 9y ago> One of the issues is using the word "engineer" for any of the brogrammer types In Canada the term 'engineer' is regulated at the provincial level, and a person can be prosecuted for labeling themselves as an engineer if they are not registered and licensed with their province's engineering association. For example in Ontario in order to join Professional Engineers Ontario and call yourself an engineer you must meet strict academic and work experience requirements[1], pass an ethics exam, and pay a yearly membership fee. Everyone who graduates from an accredited engineering program in Canada has to take an ethics course and has these rules drilled into their heads. I know I did. But then I graduated and half the people I run in to at hackathons and conferences did a two week bootcamp and have "Software Engineer" in their job title, and proudly introduce themselves as such. I call myself a software developer because although I have a software engineering degree I'm not registered with the PEO and it wouldn't benefit me if I was. [1] http://www.peo.on.ca/index.php?ci_id=1848&la_id=1 http://www.peo.on.ca/index.php?ci_id=1848&la_id=1
- vonmoltke 9y agoCanada, along with a couple other nations I do not recall, is an outlier in this respect. As an American EE degree holder who has been employed as an EE in the past, I think the attachment of "engineer" to shitloads of titles just to fluff them up is ridiculous. However, I think the Canadian position is equally ridiculous in the opposite direction.
- Nursie 9y agoI've worked in C, embedded and server-side, for about 15 years of my 17 year career. Companies I've worked with recently are having trouble finding C-capable developers, particularly C developers who have the first clue about 'modern' developments like CI and CD, or git. C is a language invented in the 70s. If you kept up with thread APIS when they became usable in the late 90s you could quite easily have had a 40 year career in one tech stack, and be looking at a bit of consultancy by now (if you haven't moved in to management or other areas). So even without keeping current on frameworks and languages, the idea that knowledge becomes obsolete in our field after just a few years is wrong. You do need to keep an eye on wider trends and newer tools, but still. That said, there is still ageism in this arena. And I'm breaking out because, really, there are better things to be doing in 2017 :)
- BatFastard 9y agoSuch as?
- Nursie 9y agoHonestly? I've had more fun coding Java (8) and Python lately, for server-side stuff. I'd also like to get paid to do some Rust and/or Go at some point. It's all subjective, of course, and partly I'm just bored of doing the same thing for so long.
- ryandrake 9y ago> Companies I've worked with recently are having trouble finding C-capable developers, particularly C developers who have the first clue about 'modern' developments like CI and CD, or git. As is always the case when a claim is made about "companies having trouble finding developers" of some sort: Are they actually having trouble finding developers despite offering top-of-market salary, remote work and gold plated benefits? Or are they the usual "we think we offer above average salary with great benefits!" companies who get no interest from developers and conclude there's a shortage?
- Nursie 9y ago
- icebraining 9y agoEven languages and frameworks don't change that much outside of certain niches. Django and Rails have been around for over a decade. Go, a "new" language, is eight years old. I've been working for 5.5 years with a Python-based platform called Odoo (purely by chance of employment) and I don't see it going away any time soon. A colleague of mine also recently got a very good offer for helping maintain a codebase in Informix-4GL.
- Clubber 9y agoC# has been around since 2002. 15 years. It's changed quite a bit since it's introduction. C# is just a wee tot compared to C.
- eeZah7Ux 9y agoThis is besides the point. Smart companies hire engineers that understands principles and concepts. Hipster companies hire by buzzword of the year. Stay away from those.
- ams6110 9y agoI think you have that backwards. It's inside certain niches that people are still building stuff in Rails and other decade(s)-old frameworks. Now it's node.js and react, to name a couple of examples. By 2020 something else will probably be the hotness. By 2025, those frameworks will still be around, running established systems, but won't be very interesting to any new developers.
- icebraining 9y agoEven Node.js will be nine years old next May, and it's just a runtime for a 22 year old language.
- henrik_w 9y agoI think the "half life of knowledge" misses so many parts of what makes a SW developer good. Sure, there are new languages, libraries and frameworks to learn and keep up with. But the fundamental parts of programming don't change - it is still sequences, loops, if-statements. Also, quite a large part is independent of the language - how to break the problem down into parts, thinking through the scenarios that can occur, good naming, consistency in the small and large. Not to mention everything else that isn't programming per se - domain knowledge, talking to people, negotiating, in which order to develop things... More details on what I think makes a good dev: https://henrikwarne.com/2014/06/30/what-makes-a-good-programmer/ https://henrikwarne.com/2014/06/30/what-makes-a-good-program... and about programmer knowledge: https://henrikwarne.com/2014/12/15/programmer-knowledge/ https://henrikwarne.com/2014/12/15/programmer-knowledge/
- fjsolwmv 9y agoRemember when we were all becoming functional programmers and we put loops and if-statements behind us?
- madengr 9y agoYep, that engineering half-life is so much bullshit. Electromagnetics hasn’t changed much in 120 years. Maybe a new transistor topology comes out every 20 years.
- hawkice 9y agoAlso draws a poor comparison between e.g. a 20-years-experience coder who was writing C++ until a year ago and someone fresh out of college whose been writing node.js nonstop in the three years since getting their degree. There may be one you have more fun playing ping pong with, but (and I say this as a youngster myself) the professional choice is the one where the value for dollar is best and the code is something you won't dread maintaining.
- zbentley 9y ago> the professional choice is the one where the value for dollar is best and the code is something you won't dread maintaining. That's very true, but might not necessarily favor either of your two examples. The choice between "20yr C++ veteran and 3yr node coder" is not always obvious or clear-cut, and the quality differential does not, in my experience, clearly favor either side based on that information alone. I've seen people who left school and coded like crazy for a few years on flaky and fad-oriented stacks--because that was where they could get employed in a hurry with zero experience and a lot of debt. I've seen those people emerge from those environments with an incredibly solid understanding of software design principles and how to do things professionally while balancing time/money/legacy/human/etc. concerns. They learned those lessons not by refining their craft over 20 years of working on an old stack, but in just over 2 years of working on a stack where every day they had to ask their "rockstar" colleagues questions like "Why is this simple thing so hard to do? Why do you keep writing the same kind of bug over and over? What alternatives exist to these tools/strategies?" and not getting good answers. These folks didn't code much outside of work, but they did read about other tools/practices in their free time. By the time they left, they learned excellent techniques (and professionalism) out of acute, concentrated discomfort at what they were made to work on, even while everyone else was taking shots of the piss and calling it brandy. (And yes, I've seen people in that same situation internalize the cancer and become "X. It's the future!" zombies.) And I've seen 20+ year veterans who were extremely proficient in a very few (one or two) methodologies, who tried to apply those methodologies to everything--even use cases where it didn't make sense, confused their colleagues, and directly induced bugs ("Making a chat app prototype/mockup for management next week? JavaScript doesn't have CORBA support? Let's write low-level TCP code in Node so we can emulate CORBA using a library I'll write for you. Thrift is too new, I don't care if it's already supported; WebSockets are the 'wrong model'; you need a proper brokered architecture for this . . . proof of concept . . . wait, why is my TCP reading code corrupting data because of off-by-one errors in my read loop?"). I've seen very senior programmers whose "breadth" of tools understanding consisted of re-implementing very specific design patterns from e.g. Java or C in a dozen languages, rather than learning to use the tool that was correct for the job. I've seen extremely experienced people whose expert understanding of a few things concealed intense insecurity about their knowledge in other areas, and who defensively tried to fit many square pegs in round holes--anything from "we need to use this email collaboration tool I'm super good at that everyone (happily using $other_solution already) has never heard of", to crazy implementations of object/factory patterns in functional languages, to bizarre architecture review and management practices. These people were all competent, and very experienced. They were also scared--not of learning new things, but of being inferior in any single way to their colleagues, even after decades coding. That's a shame, since those folks had the most to teach others, if they'd taken time to have a sense of perspective and/or face their fears. (And yes, I've seen people with that experience be refined into amazing teachers and stellar coders over the years--people who could get deep understanding of a totally unfamiliar tool in a week, be teaching others to use it in two, and be teaching others when not to use it in three.) TL;DR the choice is not that simple. But I haven't seen a clear correlation either way between time-spent-in-industry alone and professionalism or output quality. Every industry has old deadweight and young cocky rockstar-wannabes.
- Spooky23 9y agoThe people pushing this viewpoint are self-interested Vinod Khosla’s quote is missing a punchline — “Young people are just smarter” [except for me]. The only timeless ageism thing is the willingness of old men to schnooker young turks into things, whether that is getting blown up on a battlefield for king and country or getting exploited to make guys like Khosla money.
- throwanem 9y agoYou'd think someone who writes for such an august publication would be a little less of a chump, wouldn't you? (ETA: Unless you're familiar with the output of such publications, I suppose, at least enough so to validate the "Gell-Mann amnesia" concept firsthand. I can't say they serve no useful purpose - one doesn't care to contemplate packs of feral journalists roaming the streets, shaking down sundry passersby for tweed and elbow patches - but really, one is well advised not to take them overly seriously.)
- jonahx 9y ago> This sort of mythology is NOT helping. An experienced Software Engineer has valuable skills that do not age at all. Not only is the claim "now it’s five years at most, and, for a software engineer, less than three" an unhelpful mythology, it's laughably incorrect to the point that I can't imagine anyone knowledgable espousing the view with a straight face. It stems from, on the one hand, "software as popular culture," which is a great way to choose bad tools, and, on the other, the conflation of surface knowledge (the syntax of a new language, the API of a new hot library, etc) with deep knowledge (design principles that transcend language, the ability to evaluate a library based on those principle, etc).
- ams6110 9y ago> Not only is the claim "now it’s five years at most, and, for a software engineer, less than three" an unhelpful mythology, it's laughably incorrect It's narrowly referring to the "framework fads" that do seem to sweep through our profession on about a three-to-five-year cycle.
- jerf 9y agoYes, but when Framework B goes sweeping through the world, Framework A doesn't actually go anywhere. People keep working with it. If software engineers actually burned down all the old code every three years and literally everybody had to learn this new thing in order to do anything at all, this claim would make sense. But it's all additive. Even as we here on HN are shrieking and hooting about Framework B and the way it shines a unique light on the world of programming and how no thinking person could possibly resist its charms, thousands of people keep chugging along on Framework A for years afterwards. In no small part because they've heard it before, and remember that somewhere around the 2 year mark of Framework B's run you can expect well-written and cogent articles about "Framework B Considered Harmful", "Framework B Is Permanently Ruining An Entire Generation Of Programmers", "Why I'm Switching Back To Framework A And Regret Ever Listening To Hacker News" and "Oh Shit, I Bet My Business On Framework B And All My Developers Have Turned Into Feral Wombats And They're Biting Me Ow Ow Ow".
- 9y ago
- emidln 9y agoI'm 31 and I've been hacking software professionally for 15 years. I've debugged issues in the last month that I couldn't have done 5 years ago with 10 years experience, let alone when I was 21. As I grow more experienced my responsibilities increase in both breadth and depth.
- markshead 9y ago> and we've stayed current over the years I think this may be the key.
- notyourday 9y agoIf you are 40 and you are still thinking about your skills in terms of "i can code", then I have very bad news for you. There are hundreds of people who can code just as good as you who are younger which means that they are going to replace you because you are just not that good or that irreplaceable. Is there a way out? Sure: 1. If you actually are that good of a software engineer, start a My Code As Service company - it is the "402 PAY_ME_A_TRUCKLOAD_OF_MONEY" response. There are gobs of companies out there that pay gobs of money for rock star performers because there are just not that many of them. 2. Create - or buy - your own lifestyle business. You will never make millions of dollars but you should be comfortable. 3. Stop pretending that coding matters. Start managing those that produce code. Being a technically competent manager is a great way not to get fired.
- mgbmtl 9y agoYep, but perhaps to phrase differently: once you get to a certain point, you build a reputation and business network. People usually want to work with you because they know what to expect (in terms of professionalism, code quality, etc). There's also value in that, whether as a programmer, manager and/or consultant.
- davidgay 9y agoIf you are 60 and just won the Nobel prize and you are still thinking about your skills in terms of "I can win a Nobel prize", then I have very bad news for you. There are hundreds of people (https://www.nobelprize.org/nobel_prizes/lists/age.html https://www.nobelprize.org/nobel_prizes/lists/age.html) who can win Nobel prizes at ages younger than you. Or: this argument is meaningless because it's assuming more supply (of someone like you) than jobs (and perfectly informed employers for that matter).
- notyourday 9y agoI'm not seeing those winning Nobel prizes complaining about them being fired from a job because they are old.
- blub 9y agoCoding does matter, but most companies can only extract a limited amount of value from code, due to various dysfunctionalities in how they operate. Being a good coder in such a company could be problematic, because they won't be able to recognize ability or benefit from the difference in skill to an average coder. These companies will treat programmers poorly, will try to save costs, outsource, etc. I don't get why you claim that younger people will replace 40-somethings. It's not like the older devs will break outside of the warranty period.
- legohead 9y agoI wish companies saw it this way. My company is downsizing and I've been interviewing like crazy. 5 years ago when my tech stack was hot I had to fight off companies, now I feel they are just humoring me. I make it clear in my cover letter that I am capable of picking up new technologies and languages with ease, which if you look at my resume and my personal projects on github is pretty plain and obvious -- I have 15+ years of professional experience in multiple languages and using all kinds of technologies. But they look at my current job/tech stack and say "hey, you don't match ours. sorry". I even applied to dozens of jobs in the HN Who's Hiring, got a couple phone interviews, and nothing past that. I finally got a job at a place that was using my stack and wants to convert it to something more modern. This has definitely been a strange interviewing experience for me. I'm nearing 40 and have to wonder if ageism is becoming an issue for me.
- dep_b 9y agoLie on LinkedIn about knowing Python after doing one simple Django project 1). Watch the desperate recruiters fill your inbox. 1) actually I didn't lie, people I knew just kept +1'ing Python on my LinkedIn profile because I talked about it sometimes while I was doing a one off project in Python
- lovich 9y agoI'm under 30 and I've had the same experience. Every place I've applied to felt like they had a checklist of hundreds of items and a no on any of them was an instant disqualification. Even at places where I had a friend recommend me and could find out their reason for not giving me an offer, there was no consistent reason and it was usually just one person saying no so their team sat for 6-12 months looking for people. It's like every business is now completely terrified by a wrong hire and will only take the "perfect candidate" but at market rate
- bitcrusher 9y agoThis has been my experience as well; It's as if every company is looking for a unicorn programmer... when their domain isn't any more or less unique than any other domain. One of the "interesting" side effects is that it seems like interviewers are starting with the assumption that the person interviewing is an idiot who knows nothing and then works from there. So any slight misstep or misremembering of something puts you the fail box immediately. My theory is that part of this is the broken culture of interviewing that we have as an industry. This "tricky CS puzzle" crap that originated at GOOG and MSFT is so prevalent that it's nigh impossible to actually succeed. More than once, it's obvious to me that the people DOING the interviewing couldn't pass their own interview...
- matt4077 9y agoI belief that sentence to be broadly correct. First and foremost, it is making a comparison more than an absolute statement of fact. And (without having first-hand experience), it doesn't seem obviously wrong to say that someone who left for an extended vacation in 2014 would have more surprises waiting for him today than a mechanical engineer who did the same from 1926 to 1929. Note also that the statement is also talking about the "half life", indicating an understanding that there is a part to expertise that is less susceptible to aging. One can criticize that the concept of half life is misapplied, because the underlying process isn't stochastic, i. e. that half of knowledge will not again half in another half life. But then one would be splitting half hairs, which of course is one of the engineering skills that never go out of date.
- throwanem 9y agoIt wouldn't be wrong to say that I took an extended vacation from early 2015 to mid-2017, if not from the industry entire, then certainly from modern fullstack dev - spent the time working with best-of-2008 because reasons. Coming back, there weren't all that many surprises. I went from first exposure to ES6, Babel, Webpack, protobuf RPC, and Kubernetes, to shipping, inside a month. And I am not in any way special. So I hope I might be excused for feeling I have some basis for the statement that I think you're vastly overestimating the scale of the issue here.
- breakyerself 9y agoKids playing with building blocks that adults made trying to find a configuration that strikes pay dirt. If everyone over 35 in the tech industry disappeared the world would come unglued fast.
- kafkaesq 9y agoThis sort of mythology is NOT helping. Unfortunately it's partially valid. Job ads in particular are (presumably for a want of some other way to whittle down the pile of incoming resumes) considerably biased towards frameworks and gizmos that have been around 3 years or less. Yes there are new languages and frameworks we have to learn, but if we apply any effort ... You'd think a lot of these places assuming we're all utterly incapable of "learning", they way they phrase some of these requirement lists.