38 ms·

My 20 year career is technical debt or deprecated

• lutorm 3y ago
  20 years ago I was mostly writing C++ for work. I still am.
• woooooo 3y ago
  Which is better/worse, the hack with a plan which is removed promptly or the barnacle that persists forever? The barnacle did provide more lifetime business value after all.
  • maxbond 3y ago
    Barnacles can cut you pretty badly if you're not aware of them, and they have a habit of reproducing. When you have a large colony on the hull of your vessel they impose a nontrivial amount of drag. (I'm more committed to the bit than this position though, it's a judgement call that an engineer must make relative to the requirements and resources available.)
• YZF 3y ago
  There is plenty of code I've written that's still out there doing useful things. I'm sure some not insignificant parts of Windows, Linux, tools, libraries, browsers etc. etc. are fairly old code that just keeps working .. perhaps with fixes and improvements. Good code lasts a long time. Technical debt is something you are continuously paying "interest" on. Just like any debt, sometimes it's a good thing and sometimes it's a bad thing.
  • inconceivable 3y ago
    > perhaps with fixes and improvements. in my experience, if there's no will or budget for a rewrite, it gets virtualized, locked away behind a firewall/corporate network with a restricted set of users, and will basically run forever as long as the ISA and virtual storage is supported by emulation and the business process still exists and is able to support the infra/people involved. think of it like a zero coupon 100 year bond in technical debt issuance underwritten by the central bank (corporate hq). and highly liquid in the sense that a virtual image is easy to move around. the good part is it just gets faster and takes up less % resources as hardware improves, and forever-bugs are usually worked around and documented by the people pushing the buttons.
  • chrismarlow9 3y ago
    I got a new laptop recently and I hadn't used Windows in probably a decade. It came with windows 11 and I saw so many old interfaces under the hood while exploring that it made me laugh a few times.
• 1-6 3y ago
  As long as you know how to get out of technical debt (islands too) when you see one, you're suited for any task.
• hedora 3y ago
  The fun thing is that, until CS slows down, stuff gets better so fast that we get to reimplement the same thing, but 10x better every 5 years or so. First I wrote single threaded code code with automatic memory management, then single threaded synchronous with manual memory management, then synchronous multi-threaded, then async, and then async lock free. Now I am writing async lock free, and the compiler is helping me prove it is data-race-free and memory safe. Each time I rewrite this stuff, someone hands me 6-7 figures. This is awesome.
  • kneebonian 3y ago
    > so fast that we get to reimplement the same thing, but 10x better every 5 years or so. Citation needed. Seems that it just us getting more and more abstracted which can make it easier but not necessarily easier. The hardest part for the next gen of developers is not having Moore's law to save them from crappy coding.
    • rr808 3y ago
      Right, I worked on a async non-blocking project in C++ in the 90s. It was a lot simpler than any modern project, no cloud, no yaml, no containers, no fancy security. Sure it didn't have a pretty web interface but was great software.
    • userbinator 3y ago
      10x worse is how I'd put it. First example that comes to mind: Microsoft Teams.
      • shrimp_emoji 3y ago
        Teams is special. You could've cited Slack or Discord. Teams is an anomaly in horrible software quality that *only* Microsoft can manage to produce (also see OneNote (but DON'T see VS Code -- that's somehow really efficient despite being Electron!)).
  • YZF 3y ago
    More like the hardware gets faster but the software gets slower or stays the same ;) Lock-free goes way back. Multi-threaded goes way back. Both more than 20 years. SIMD goes way back. GPGPU goes way back. What is newer-ish are large scale distributed systems. But even that isn't so new any more.
• photochemsyn 3y ago
  Interesting how C programming has survived that entire time period in the operating system and embedded worlds, although the spread of multicore hardware running lots of threads in parallel has also led to many changes (but even those changes were beginning to be implemented 20 years ago). 20 years from now, C will probably still be a core language in its niche.
  • 2muchcoffeeman 3y ago
    Is it interesting? Somewhere along the chain someone needs to know assembly. Either hand crafting it or some compiler exists for some language that is one step removed. At this level my feeling is that there is less desire to constantly change tools.
  • imoverclocked 3y ago
    Queue rust apologists… I think C and its direct descendants will slowly fade away over the next 20 years as new developers want to get away from the legacy of language specifications that span existing codebases. There are so many sharp edges in C that have automatic fixes/detections/etc in newer languages and don’t get me started about multiprocessing complexity in C.
    • dralley 3y ago
      It will fade away the same way COBOL faded away, which is to say that it will still be at the core of a great many critical systems in 50 years, even if new critical systems aren't written in it.
    • sgtnoodle 3y ago
      My coworker and I were pair programming some Rust today. We were working on a convenience wrapper whose whole purpose is to reduce boilerplate. So, by its nature there's a lot of internal generic traits, thread safety, etc. He knows Rust well but software design not so much. I know software design well but Rust not so much. My experience can be summed up with: let &mut writer = Writer<T>::writer::new(connection.clone()).clone(); // TODO ??? writer.write(*data.clone()).unwrap(); Meanwhile in C++ I'm like if (!write(connection, data, data_len)) { return false; }
• chasil 3y ago
  Brian Kenighan wistfully removed the lex/yacc parser in the OneTrueAwk many years ago, and replaced it with a custom parser (I believe for performance reasons). The OneTrueAwk remains the standard awk in BSD, renewed, but not replaced. I don't think it's going anywhere. The POSIX standards, flawed as they may be, have incredible staying power. These standards run our phones and embedded, supercomputers, current Apple workstations, game consoles, and are significant in many other places. Microsoft itself implemented POSIX in Windows from the beginning (likely recognizing it's importance as the former vendor of Xenix), and while this has waxed and waned, running the "wsl.exe -l -o" command on modern Windows will catalog Ubuntu, Kali, and Oracle Linux that are not Linux, but serviced by the Windows kernel's POSIX layer under WSL1. Applications that implement or greatly enhance POSIX have staying power. Those who seek code longevity would do well to study it.
  • KerrAvon 3y ago
    Counterpoint: POSIX is increasingly a creaky anachronism required to support a legacy base of old Unix software. Every modern Unix-derivative OS replaces or significantly augments core POSIX functionality with something that works better for modern hardware and software needs, or suffers in some areas if they don’t/can’t.
  • froh 3y ago
    > that are not Linux, but serviced by the Windows kernel's POSIX layer under WSL1. that's not how that works. wsl is a Linux kernel running under a hypervisor integrated with windows.
    • temac 3y ago
      Wsl2 is how you say. WSL1 is a Linux syscall reimplementation in the NT kernel space.
      • froh 3y ago
        I see and TIL. Still said syscall reimplementation was not based off the old and long gone NT posix personality (just sayin' so I save face...)
• smackeyacky 3y ago
  I am somewhat amazed at the list of tech from that article, it's like he has a magical knack for picking dead ends. C was the 2nd language I learned and I'm still using it. The big surprise for me has been javascript - it's so...bad it became good or at least ubiquitous.
  • asdfman123 3y ago
    JavaScript is that guy you knew who didn’t have a lot of talent but has stuck at it for the last 30 years, so is now embarrassingly doing much better at his thing than you are.
    • QuadrupleA 3y ago
      Interesting thought experiment, how much worse would JS have to have been to have been abandoned and replaced?
  • nostrademons 3y ago
    C and Javascript are both worse-is-better languages, as is SQL. They have known gotchas and quirks and lots of them. But they basically work, they were good enough, and because of that they became so ubiquitous that it's impossible to replace them.
    • 59nadir 3y ago
      They were both THE languages of systems that became/were important. I agree that they both have the "worse-is-better" quality about them, but C is a much more appropriate language for what it's supposed to do than JavaScript is. The fact that we (mostly) haven't been able to execute anything else reasonably in the browser is the reason why it's stuck with us. C has had alternatives for a long time but stays put, because it's just better at what it does.
    • revelio 3y ago
      Not ... really. Those languages all became popular and got critical mass because they were the only way to access operating systems-like things. People wanted the value provided by those platforms and had to go through the language to get at them. So they buckled up, tolerated it and promptly spent decades and billions of dollars on creating wrappers, FFIs, transpilers and the like to avoid having to touch the underlying monopoly language. People wanted browsers. JS came along for the ride. It wouldn't have been so popular if it had lived its life outside the browser
• cabaalis 3y ago
  I have found my doppleganger. The exact same technologies, progression, I even wrote a VIN scanning app for car dealers myself. My mind is blown.
• 29athrowaway 3y ago
  What do all these things have in common? MS Visual Basic 6, MS ActiveX, MS Silverlight, MS Visual Foxpro, MS C# .NET Compact Framework, MS ASP.NET WebForms, MS ASP.NET MVC, MS Windows Communication Foundation... I think there common is a theme there. But shhh, don't tell him.
  • metaltyphoon 3y ago
    Oh yes… those were for sure the only thing to perish.
    • tuchsen 3y ago
      The space jam website from 96 is still up :). Standards go a long way. https://www.spacejam.com/1996/jam.html https://www.spacejam.com/1996/jam.html
  • rr808 3y ago
    They're all faster, more productive and richer environments than modern web apps?
    • senko 3y ago
      VB6 and FoxPro, yes. Others, not so much.
  • djbusby 3y ago
    Why not just say what's common (over hyped dead-ends)? Snark don't make you sound smarter.
    • dagss 3y ago
      Microsoft.
    • tasuki 3y ago
      I thought it was a smart comment. I did not notice the commonality before 29athrowaway pointed it out. 29athrowaway said eight times what's common. Eight times!
• MartinMcGirk 3y ago
  I feel like this is heavily connected with the idea of legacy. I grew up in Scotland, and lots of the buildings, culture, etc, have been around for hundreds of years. It would be nice to feel like something I was building would last as long and outlive me. It doesn’t though. Sometimes I think that this is just the nature of software development. Most of the stuff I build is built to solve an immediate business problem. It probably lasts 5/10 years and then someone rewrites it in a new language, or more often the task isn’t relevant anymore so the code gets deleted. I find myself thinking that maybe if I’d been in civil engineering or something then I’d be building stuff that lasts, but speaking to people who’ve worked a long time in construction has taught me that it’s the same there. Most of the buildings that go up, come down again in a few decades once regulations/fashions change or the new owner of the site wants something else. Every so often something like a Cathedral gets built, and those get built to last. But most people don’t get to work on those. If there’s a software equivalent of a Cathedral then I still haven’t found it.
  • Krutonium 3y ago
    Core Libraries/Kernels, like LibC or The Linux/NT Kernel.
    • fbdab103 3y ago
      To invoke the RIIR train, probably a lot of fertile ground in being the definitive Rust implementation of "solved" foundational libraries: zlib, libpng, libjpeg, etc. Something ubiquitously used which has very minimal/no churn. As Rust usage grows, dependency on the original C implementation will diminish.
      • pjmlp 3y ago
        It will diminish, but never go away until POSIX foundations or graphical programming standards get replaced (most of them defined via C ABIs). When I was mostly doing C++ and C on day job, 20 years ago, they were the languages to go when doing any kind of GUI or distributed computing, nowadays they have been mostly replaced for those use cases. Yet they are still there, as native libraries in some cases, or as the languages used to implement the compilers or language runtimes used by those alternatives, including Rust.
• SoftTalker 3y ago
  > printing from the browser was its own fun nightmare Remember Crystal Reports? Oh god, the pain. The pain.
  • comte7092 3y ago
    Remember? If only. I work outside of tech. We still use it.
    • nabogh 3y ago
      Yep still kicking in the water industry in Australia. Glad I left that behind
  • spo81rty 3y ago
    I got hired for a job specifically because I knew crystal reports! I don't miss that.
    • Kon-Peki 3y ago
      I got hired for a job because I was willing to learn to program on OpenVMS. I'd never heard of it, but asked the interviewer "it's a lot like UNIX, right?". He looked at me, waited 5 or 10 seconds, and said "no." Oh well, I passed their C and SQL tests, they weren't going to let me go that easily. I'll probably retire when they finally retire it, but at the rate they're going I may beat them to it. I won't miss it, but I won't regret it either.
  • HNDen21 3y ago
    I used that with classic asp as well as with ColdFusion :-) Eventually SQL Server Reporting Service replaced that in places I worked
• irrational 3y ago
  I’ve worked on the same website for 20+ years. Recently we were informed that the site was being shutdown and we would be reassigned to other teams. On the one hand, as long as they are still paying my exceedingly well, do I really care what I am working on? On the other hand, it is a bit painful seeing 20+ years worth of work being deleted.
  • SoftTalker 3y ago
    I've been doing this for over 30 years. Not only have I seen years of my work deleted, I've also seen large fractions of the rest of it never even used.
    • anonzzzies 3y ago
      > I've also seen large fractions of the rest of it never even used These were some of my favourite as a young freelancer (long time ago): they'd pay me $90/hr to write stacks and stacks of code with our small parents-garage team and when we finished, we demoed to the client who were very happy. But instead of having to wait for bugs, fixes and addition, we just got a new assignment after learning 'great job, but this is no longer needed'. Now I find it painful, but back then we could just focus on 'new things' like that. It didn't happen often, but there were a few large ones that I remember well.
• FrustratedMonky 3y ago
  Everyone one that has counter examples thinking they prove the opposite, are just not waiting long enough. All the kids think they will be young forever. Can't blame MS for new JS libraries every month, or a new language released every month. This web site is dedicated to people showing off things they created, which replace something that turns into debt, and in turn also become flavor of the month. Yes, biased old man that saw 30 years of code get replaced with the latest "thing that kind of works like the old thing, but not really as good, but we have to do it to keep up with technology or we'll have debt". I've seen old VB6 apps fulfill a business need just as well as anything written in a full LAMP stack that takes a team to implement. (not that I'd ever use VB6, but hey, it did a job). Take me out back of the shed and end it quick while I'm hunched over programming something cool.
  • arvinsim 3y ago
    Seeing the cyclic nature of things after 12 years of programming, I am focusing on the solving the domain aspects of a problem rather than code. I will leave that to juniors who probably appreciate doing the coding.
  • asdfman123 3y ago
    It’s so weird, I used to be much more of STEM triumphalist, the kind of person who used to think the past was evil and the future can’t come fast enough. I wouldn’t consider myself conservative by any means but increasingly in 30s I’m beginning to think everyone needs to stop messing with stuff and accept imperfection.
    • riffraff 3y ago
      As the adage goes, things that are new when you're a kid are the norm, things that are new when you're a young person are exciting, things that are new when you're older are unnecessary, confusing, or scary. It's true for everyone in every subject I'm afraid:)
      • hef19898 3y ago
        Even when young, new stuff is scary. Look at any community, ranging from RPGs (new rule editions, new meta plots (those are in the example I think of getting worse, objectively ;-)) to stuff like World of Warships (new classes and ships introduced after person started bad). Nothing to do with age, but rather emotional attachment. I try to avoid that kind of attachmemt, especially with regarda to my work. The odd time I stumble across something I didnyeaes ago more often than not I embarassed to thebpoint wantin to deprecate it myself! The rare, even odder, exception notwithstanding.
• deleted 3y ago
  [deleted]
• nurettin 3y ago
  I started with 6510 assembly. I have 25 year old delphi apps. But nodejs and go hypes are also 10+ years old. If you haven't learned, maybe you are stuck on purpose.
• kragen 3y ago
  a thing most of these have in common is that they're proprietary, so the users are dependent on the companies that own them for enhancements, bug fixes, and ports to new platforms. this is a recipe for wasting your time visual basic, asp, coldfusion, foxpro, activex, flash, and silverlight, windows ce, asp.net, webforms? proprietary, proprietary, proprietary, proprietary, proprietary, proprietary, proprietary, and proprietary and mostly pretty dead as a result how about the non-proprietary things in the list? html, css, js, fortran, java, ruby, and rails are all just about as alive as they were 10 or 20 years ago, if not more so, except that rails didn't exist then the exceptions are perl, objective-c, and the js frameworks. perl, ember, and backbone aren't going to disappear anytime soon but they will likely continue to stagnate. but unlike silverlight or windows ce, you can probably run your perl and backbone and angular and react and swift code 10 or 20 or 30 years from now on whatever platform people like then unless the platform is centrally controlled by an owner who forbids it, so try to avoid platforms like that (java applets were already dead 20 years ago, and soap sucked from the beginning, so these examples are out of place) there is certain knowledge with a very limited half-life. but hopefully you aren't spending most of your time learning react apis or wasm instructions or editor keystrokes or chromium bugs, but rather general principles that transfer across domains. algorithms, reasoning, type theory, math, writing skills, hierarchical decomposition, scientific debugging, generative testing, heuristic search, that kind of thing. a lot of that stuff goes back before computing and most code has an even shorter lifespan than the knowledge we use to build it. which is as it should be: most code is written to solve a problem that won't last decades or even years, but it's still profitable for companies to have it written. modifying a big system is harder than modifying a small one, so it's better to maintain just the code you need for today's problems. writing code and throwing it away is mostly fine still, i've spent my career on free-software tools, and their half-life seems to be a lot longer, about 25 years. i reviewed some of the stuff i'm using right now in a comment on here 10 days ago, https://news.ycombinator.com/item?id=35829663 https://news.ycombinator.com/item?id=35829663 i know a guy whose preferred programming editor is ex. the non-full-screen version of vi
  • turtleyacht 3y ago
    > whose preferred programming editor is ex It's intriguing, because that implies he can work on most things in a way that "fits inside one's head." Do you know if he extensively calls out to external tools, custom aliases, and the like? I imagine there is some fullscreen mode where he can--temporarily--suspend ex, make use of custom sourced mappings, and the output is piped back into his editing session. It's hard to find certain tidbits, so I'm always glad for even the smallest details. Thank-you.
• jgb1984 3y ago
  I guess I was lucky: I started 15 years ago doing web development using python and django on linux, which is still my toolset today ;)
  • anonzzzies 3y ago
    Nice. I was a less smart person who wanted to learn, like everyone does these days it seems (but not back then), the latest and the greatest. My Django projects of 10-15 years are running fine in production and get updates in their respective companies. All the rest I've written has all kinds of issues. And Django is still relevant, just not hip. Should've stuck with it.
• albertopv 3y ago
  Absolutely, that's why I'm trying to move to management, to leverage on my non tech experience. I'm 40 and younger colleagues are faster learner if not already "expert" on new stuff. I often have to "forget" what and how I learned old things to learn new techs, the effort can easily double.
• hgs3 3y ago
  Don't define your career by the technologies you've used, but rather by the problems you've solved and the knowledge and experience you've acquired.
• gravypod 3y ago
  > One of the biggest challenges we had at Stackify was getting stuck on an old version of Elasticsearch. At one point, they made some significant changes to how it worked that were not entirely backward compatible. I am glad I am not the only one who hit this roadblock with Elasticsearch. It felt like always trying to play catch up.
• richardw 3y ago
  One company I worked at had heavy SQL Server stored procs. I was pretty dismissive initially ("don't put business logic in the database layer!") but grew to understand that really those were the gold. The first versions were written in 1997 and by the time I arrived that code was bulletproof. There were about 4 UI technologies over 20+ years (VB, ASP, Forms + asp.net), but the procs were the same shape with thousands of edits for edge cases. Changing UX for the new hotness was massively de-risked and faster because the procs were solid. CTO's change. They started replacing it with a "proper" ERP system around the time I left and it's been nearly 6 years of pain. Joel spaketh: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... (As usual: of course you can break the rule, but first deeply understand the risk you're taking.)
  • toadi 3y ago
    think around 2010 I worked for the one and only payment processor in my country. All ATM tx, POS, online were handled. The back office handling was done with Agile and Java. It was a pile of garbage. The frontend was still a massive mainframe. It had 10k+ COBOL program running it. With comment changelog on top from somewhere end of the 70s. The code review guy was doing this for 20 years and could tell if things would be slow and not scale all the Tx with just reading the code. Until today they never replaced it and is still running on it. sometimes you don't need fancy new stuff. Just learn the things very well at your disposal. Heck sed, awk and bunch of simple cli tools still work well on Big data sets :)
  • mongol 3y ago
    Yeah, when I started in this field 20+ years ago, the wisdom I learned was that it was bad practise to tie yourself to the DB like that. But just like you I can see the value in doing it. SQL may be one of the most futureproof languages there are.
    • richardw 3y ago
      Exactly. Code you learned a decade ago is absolutely useful today. When I started I outsourced SQL to the DBA’s or an ORM. Not since that team! It’s been a semi-secret weapon for me because most people ignore it.
• ThePhysicist 3y ago
  I think it's normal. Some systems I've built were quite sticky in the sense that they started as prototypes to be scrapped once we figure out the "real" system architecture, and 8 years later they're still in use and integrated into dozens of business processes, so hard to replace. In general, looking back at old code I wrote it seems my solutions were better when I was more naive / less experienced, as I would often go for the immediately obvious and simple solution (which is the right one in 90 % of cases). Working many years in software development and reading HN seems to have made me more insecure regarding software, as I tend to over-engineer systems and constantly doubt / second-guess my technical decisions. So one thing I'm actively trying to do is to go back to using simpler approaches again, and caring less about perfect code.
  • lambdaloop 3y ago
    Relevant xkcd: https://xkcd.com/2730/ https://xkcd.com/2730/
    • dsign 3y ago
      Plot twist: biological evolution works like that too.
  • mattmanser 3y ago
    I've taken the opposite lesson to you, I now keep everything super simple and am quite conservative on adopting new concepts. It's because I've so often seen the cycle here of "X is brilliant" and then 2 years later "how we switched off X and saved millions of manhours!".
    • rickdeckard 3y ago
      Sounds like you took the same lesson
      • mrits 3y ago
        Only reading the first paragraph is pretty simple though.
• chaostheory 3y ago
  Apparently, we’re making either Tibetan mandala art or Theseus’s Ship
  • Smaug123 3y ago
    Insert Pirates of the Caribbean meme. "This is without doubt the worst ship that's ever floated." "But it does float." There's no inherent shame in Ship-of-Theseusing something to accommodate changing requirements! Complete rewrites are hard and take forever!
• chriscappuccio 3y ago
  The dude equivocates programming in Perl to programming in FoxPro, both are simply "deprecated" and "hard to find." Is this true?
  • senko 3y ago
    Perl is not so much deprecated, more like the community performed collective jump off the cliff with Perl 6. If you think Python 2->3 transition was ugly, you haven't been watching that slow-mo trainwreck.
    • Jorengarenar 3y ago
      Wait, wasn't Perl 6 rebranded as new language Raku?
      • senko 3y ago
        I believe so, after years of being vapourware and basically stopping Perl 5 development right when web as a platform started being important.
        • cesarb 3y ago
          Perl 6 did get released, with that name, after years stuck in development (source: https://developers.slashdot.org/story/15/12/26/0354235/perl-6-released https://developers.slashdot.org/story/15/12/26/0354235/perl-...). Only later was it rebranded.
          • lizmat 3y ago
            In 2019 to be precise: https://raku.org https://raku.org
  • biorach 3y ago
    The guy way overused "deprecated" in that article. Perl 5 is alive and well, and while not the most actively developed of languages still has a steady trickle of small improvements. It's installable in all major linux distros and you can probably get code from 2 decades ago running without much hassle. Most people would shudder at the thought of starting a new project in it, but if you need to keep a legacy codebase going the community have your back for many many years to come.
• carl_sandland 3y ago
  Maybe implementations have much less value than has been assumed and paid for by stakeholders over the decades. If code is a throw-away implementation detail of some model/abstraction then why are we getting paid so much money again? Really makes me worry about generative AI approaches; just as well there is no universal very high level modelling language everyone loves yet. I think this is why working on games is nice; it's not technical debt it's just a toy, maybe everything is. Our cathedrals are surely [L,U]inux and the C programming language, HTML has done pretty well too.
  • kqr 3y ago
    Don't confuse short-lived for low value. Software solving the right problems has incredibly high ROI, even accounting for high programmer salaries. We're not getting that money for generating realistic-looking syntax, but for discussing with stakeholders and choosing appropriate designs with an eye for both the bigger picture and details. These are language-and-library-independent things, mostly, and incredibly difficult work. You may be able to give an LLM directions to do something like what you would have been able to do, but the money is not in the parts the LLM is able to accomplish, it's in the direction you give it.
• NikhilVerma 3y ago
  I've been programming professionally close to 16 years. Here is what I can remember of my code: # Job 1 (3 yrs) - Worked on around three products, all shut down, code probably lives in some SVN archive. - Learnt advanced JS, PHP, MySQL, Photoshop, jQuery etc (skills mostly relevant) # Job 2 (1.6 years) - Project never launched, code never saw the light of the day. Probably lives in some Git archive. - Learnt a few in-house frameworks (irrelevant) but also leant Git (relevant) # Job 3 (8.5 years) - Worked on several products, the biggest one is still active and seeing millions of users weekly. Rest got shut down and live in a Git repo. - Learnt about some inhouse frameworks (irrelevant). React, React Native (skills still relevant) # Job 4 (2 years) - Actively working - Learnt Vue (skills still relevant)
• QuadrupleA 3y ago
  https://phrasegenerator.com/ https://phrasegenerator.com/ , one of my first web projects, has survived since 1996 (almost 30 years, wow). It's definitely required a few "tech debt collections" - the original was in ColdFusion, the hot stuff of the time. Then an asp.net / xml phase when that was cool. Now hopefully a boundless future of stability and modernity with python and JavaScript. At least until the world sunsets any pre-4 python versions, and browser JavaScript is thrown away in favor of pure WASM. But seeing as we still support the <font> tag, I've got some time ...
  • bboygravity 3y ago
    This is what blows my mind about web stuff. You needed to completely change framework and even languages 3 times in not even 30 years?! Just to keep things maintainable? I don't feel that it's the same for other area's of programming: desktop apps, embedded stuff. Maybe I'm wrong...
    • deleted 3y ago
      [deleted]
    • z3t4 3y ago
      A website made in 1999 still work today, the browser is like an OS and the concensus is that you should never break userland, eg. You don't break the web. Then there are as many frameworks that there are developers.
      • oaiey 3y ago
        Which is good ... and bad at once. Think only about how nice could be the JavaScript API if we would allow it to break. Or CSS. Or HTML. But completely agreeing with your point. Underrated quality of browsers.
    • revelio 3y ago
      Sure it is. Win16 -> Win32 (only partly backwards compatible) -> .NET WinForms -> WPF -> WinUI 2 -> WinUI 3 (with of course Java and Electron being in the mix too) ... or ... Motif -> GTK 1 -> 2 -> 3 -> 4 (all backwards incompatible) ... or ... macOS Classic -> Carbon -> Cocoa/ObjC -> Cocoa/Swift The browser is actually one of the more stable environments out there with a lot of the churn being on the server side and optional JS frameworks as people oscillate around trying to figure out the best way to wrangle a document renderer into being an app platform.
• emodendroket 3y ago
  I will say that the core idea of SOAP/WCF services is honestly pretty sound. There is no sensible reason (imo, anyway) that everyone needs to be using stringly-typed data and manually parsing REST responses when the underlying code all has type definitions. I get that it came with headaches (and I suppose people wanted to work in untyped languages) but jettisoning the entire idea of generating the client feels like it was throwing out the baby with the bathwater.
  • edejong 3y ago
    But you know what happened to SOAP? It was smothered by its own success. The allure of interoperability and extensibility attracted everyone and their cat to the party. With so many stakeholders involved, it became a classic case of "too much design by committee." It's like trying to paint a masterpiece by having a thousand artists contribute strokes—chaos ensues. And let's not forget the influx of junior developers during that time. I mean, we can't blame them entirely, can we? SOAP standards were complex and enormous. It's no wonder they struggled to grasp the underlying paradigms. We had an army of fresh faces flooding the scene, and the sheer complexity overwhelmed them. So, SOAP ended up being the baby tossed out with the bathwater. It had its merits, but the challenges it faced were just too much to bear. Still, it's worth reflecting on its strengths and the lessons we can learn. Maybe someday we'll find a way to strike a balance between the elegant core idea and the practical realities of implementation.
    • emodendroket 3y ago
      It's not like people don't find a way to screw up REST semantics and make that complicated anyway.
      • edejong 3y ago
        Absolutely. The lasting ideas are KISS and Occam's Razor.
        • emodendroket 3y ago
• keithnz 3y ago
  weird, tons of my 20 year old code is still around, but my 30 year old code, except for embedded stuff, is likely dead.
• edejong 3y ago
  As I think about all the technologies that have come and gone, it's good to find some sturdy rocks as well. Here are some techs that withstood the test of time in my personal journey: * Simple, but reliable file formats: My old photos collection is 25 years old (jpeg) and I still look at them occasionally. * My influxdb/grafana/openhab setup is now 8 years old and has been operational with only minimal hickups. * Some home automation scripts I wrote have endured for 8 years now. * My Linux/Unix knowledge is 26 years old (although much has changed since Slackware). * My C and C++ programming language knowledge is 28 years old (although I rarely use it anymore, because of Rust). Occasionally it is useful during debugging performance problems in kernels. * My knowledge of distributed systems (stuff like leader election, distributed and centralised algorithms) is 15 years old. It is still very relevant to understand both existing systems and to evaluate new systems. It is crucial to distinguish the knowledge that stands the test of time from the fleeting trends. And finally then there are the non-technical skills, which pay off even more. Effective communication, negotiation skills, organisational finesse, inspirational leadership, adept management... These are the true constants that support us during our professional life.
  • kqr 3y ago
    Is jpeg really that simple or did it just happen to win the popularity contest big time?
• deepsun 3y ago
  > I have projects at my company in the old version of Angular that is a major technical debt we must upgrade. My favorite job -- to refactor something old. If only businesses wanted to pay for it.
  • anonzzzies 3y ago
    It's mine too. But it really depends on the time that has passed. Currently I'm redoing a 2 decade old project; it's not refactoring as that would be basically impossible. It's just a rewrite. Which I like too, but less, as now I need to really dive deep in the business side of things as decisions need to be taken to properly incorporate all the crap that was taped on over 20 years. Or, worse, make a whole new project. Then i'm out.
• secretsatan 3y ago
  From the article "Swift is another excellent example of how fast development tools change. As soon as Apple released Swift, it was hard to justify writing code in Objective C anymore. I am sure there are some use cases where it is still needed. But Swift is significantly easier to develop and a major evolutionary step forward. I would argue that any apps written in Objective C are probably technical debt now" I switched to Swift a few years ago after many years of obj-c, at first I was reluctant as there were still many things I liked about obj-c but Swift won me over. Thought I would never touch obj-c much until I had to integrate a cpp library, I can't believe how much I forgot in such a short time. It was interesting to find out how to structure the obj-c code to translate nicely to swift though.
• satisfice 3y ago
  A better way to think about technical debt is to understand that what WAS technical debt-- the residual tasks necessary to make something reasonably inexpensive to maintain and improve that come from kludging things together under time pressure-- gets FORGIVEN when the whole technology on which a product is based becomes obsolete. Products don't become technical debt, they merely depreciate along with any aassociated technical debt. This is why I don't like the term technical debt: it implies something that must be paid back. But you don't have to pay back the "debt" on product that will be completely replaced anyway. When I have a long list of todo items to perfect my work for a client, and then they run out of money for the whole project and end my contract. I don't say "oh no, now I'll never dot those i's and cross those t's!" I say "yay, I will cross everything off my todo list forever."
• Shorel 3y ago
  I think looking only at technologies is the wrong approach. The underlying concepts stay the same. Your own experience is much improved. Some old technology gets replaced? I celebrate the demise of Flash. I am not Flash or even a Flash developer. I am a software developer. I am a bit sad Dlang is not more used? Yes, I am. But I am not a "Dlang" developer. Tying yourself to some technology seems self limiting.
• self_awareness 3y ago
  Whole BSD's /bin directory disagrees with this thesis that everything eventually becomes technical debt. If you pick new technologies, don't be surprised that they will be quickly overridden by something else. Pick stable and boring frameworks and languages. I.e. lots of old Java Swing applications runs on today computers without recompilation.
• deleted 3y ago
  [deleted]
• peteforde 3y ago
  It's so weird that you'd even consider putting Rails in the same category as FoxPro, even as a theoretical. Rails is kicking ass. A huge number of people are coming back from bloated JS frameworks to realize that Rails just keeps getting better every year. Hotwire and similar technologies make the argument for SPAs look very questionable. And let's not forget where we are; over 75% of the raw gross value created by YC-backed companies use Rails. So it seems like Rails is only popular with successful startups.
  • xiphias2 3y ago
    You don’t need to use a bloated JS framework. I think TypeScript is important because of how bad JS operators are defined (operator matrix is just plain stupid, throwing error would be a better option), but everything else is optional. Otherwise JS is good enough. On the other hand hotwire (moving HTML around) costs real latency and money to mobile users with data plans. Since when it’s better than just executing code on the (for most people strong enough mobile) device with close to 0 cost?
    • peteforde 3y ago
      I fail to understand how shuttling JSON back and forth is superior to sending the HTML fragment(s) that have changed. JSON needs to be parsed and in 99% of scenarios, this blocks the main thread. Once the JSON has been converted to a data structure and passed around through your SPA's state logic and template rendering, what do you do? You convert it to HTML and render it. No matter how you slice it, sending HTML fragments and updating the DOM is faster and lighter than sending JSON. My app is already displayed and responsive before your app has even started parsing. The above doesn't even address the complexity and additional failure modes that you take on when you have to handle edge cases and errors, all of which is quite literally reimplementing functionality that the browser and HTTP already give you. SPA supremacy is a group delusion mind virus. Thank goodness the pendulum is finally swinging back.
• jononor 3y ago
  Paraphrasing... "There are only two kinds of code: the ones people complain about and the ones nobody uses"
• Tade0 3y ago
  The other day my friend from a previous job linked me to a PR I did 7 years ago, which he accepted, that introduces a regression which went unnoticed all this time and that is probably the oldest piece of code I've written that's provably in use today. The whole project will eventually disappear in history in favour of a rewrite which is around since before the pandemic.
• TacticalCoder 3y ago
  > My entire career is now technical debt, or the code has been deprecated. My fellow dev often laugh when I tell them that instead of looking at all the long dead techs that are not useful to me anymore, my way to feel good is to look back at all the long dead techs that I didn't bother to learn. And, geez, is the graveyard huge. > Java Applets were also a big thing once upon a time. They were slow, and having the correct version of Java installed on your computer was always a mess. Java applets were never that big. They didn't work very well (for the reason you mention) and weren't ubiquitous. They also nearly all looked like shit. But Java isn't disappearing anytime soon. Java is huge and it'll have a legacy dwarfing COBOL big big times. Many may not find Java sexy but the JVM is one heck of a serious piece of tech, with amazing tooling available. And most devs hating on Java are using an IDE written mainly in Java (all the JetBrains ones): the irony of that one gives me the giggles. Did anyone in the mid to late nineties / early 2000s really discover Java and Java applets and thought: "Java applets is the tech that'll catch on, I'll invest in that" and not invest in Java itself? To me Java was the obvious winner (not that it was that great but it was clear to me Sun was on to something). And, well, compared to the other dead tech, at least if you learned Java applets you got to learn Java too so it's not all lost.
  • hobbescotch 3y ago
    I learned Java Applets in school in 2009 and it was clear to me then that they were sort of… awkward. Java itself is fine and I still do a little Java work from time time and it’s a breath of fresh air from the daily python work.
  • ascar 3y ago
    > And most devs hating on Java are using an IDE written mainly in Java (all the JetBrains ones): the irony of that one gives me the giggles. Reminds me of so many devs hating on Ruby and the number of times I heard that Ruby isn't used for anything relevant, while the huge majority of them either use GitHub or Gitlab for their work.
    • OJFord 3y ago
      Does anyone say that? It's out of vogue but surely there must still be plenty of RoR about the web. Shopify too. Ruby not on Rails 'not used for anything relevant' is maybe a bit more defensible. Not sure it matters/what the point is though.
• SergeAx 3y ago
  Technical debt is something one have to "repay" eventually, thus the naming. "Making technical debt" is to do something in a quick but hacky way with the intention to re-do later and better. Almost never happens, by the way.
• jraph 3y ago
  That's fine. We build code for issues that are here and now. Like most jobs: they answer immediate needs. The small amount of code that's useful for years or decades needs to be built on a stable foundation and with few dependencies. This probably matters a lot more than the code being a bit messy. It should require as little maintenance as possible. I have two pieces of PHP code I wrote more than 10 years ago, in PHP 5.1, that I still use. Both are messy, one is outright horrible, but they have no dependencies (the horrible one optionally depends on GeSHi, but there's a runtime check for its presence and has a "degraded" mode for when it's not there). They work and are relatively bug-free (the horrible one in particular is battle-tested). I didn't have much to do to run them on PHP 8.2. A few superficial fixes that were actual issues (and took half an hour to fix). By the way, I can't figure out how PHP 5 was even able to run this code. You could have mandatory parameters after ones with default values. Yuk.
  • WA 3y ago
    Same here. I have PHP code in production that dates back to 2008. zero dependencies, a few quirks, it runs on PHP 7.something for now, might upgrade to 8 at some point. It’s ugly, but it gets the job done. Best thing is that front-facing HTML and JS from 10+ years ago still works flawlessly, even though the UI is certainly dated. But I guess that’s the same with HN, where the design never really changed at all and just works.
    • withinboredom 3y ago
      You do realize PHP 7 is EOL for quite a while now[1]? PHP 8.0 is on security updates only. You might want to upgrade sooner rather than later unless you're paying for backports. [1]: https://endoflife.date/php https://endoflife.date/php
      • WA 3y ago
        Yes, thanks for the reminder.
  • aspyct 3y ago
    I must say, I never quite liked PHP as much as other environments, but I keep using it because it just gets the job done.
• nomercy400 3y ago
  The technology might have aged, but the initial concepts used for that technical design are still there and relevant.
• chrisatthestudy 3y ago
  For much of my (35+ years) programming career I have worked in Delphi/Object Pascal. When I was first introduced to it, it was the new hotness, but the last Delphi job I worked on was supporting a 15 year old legacy product. On the other hand I'm currently working on Android, where everything seems to be obsolete within a year...
• RalfWausE 3y ago
  The company i work for is using a C64 mainboard for controling some production equipment... and there are ABSOLUTELY no plans to move to anything different. Is this system deprecated from a technological standpoint? Yes, absolutely. But on the other hand it is a super stable solution that will work tomorrow in the same way as it has worked the last 30 years (and with the whole retro computing scene around spare parts will be no big issue in the forseeable future).
  • Cthulhu_ 3y ago
    But it will be an issue _eventually_... hopefully you'll be able to move the workload onto a VM / emulator easily.
    • hef19898 3y ago
      Depends on the equipment. Either it is physically dismantled by then, or people find ways to keep it running. No joke, I worked at sites than ran production equipment from the interwar period and, in one case, the early 1900s. If it is profitable, and you are allowed to run it fornenvironmental reasons, it will run forna long, long time indeed regardless of tech (controlers, chips, software) used in running. By the way, those pre-pre-war stuff ran in the southern part of Germany. So funds and avaiaibility for newequipment was not a big issue in the literal century+ since it was built.
• tlocke 3y ago
  Ozymandias By Percy Bysshe Shelley I met a traveller from an antique land, Who said—“Two vast and trunkless legs of stone Stand in the desert. . . . Near them, on the sand, Half sunk a shattered visage lies, whose frown, And wrinkled lip, and sneer of cold command, Tell that its sculptor well those passions read Which yet survive, stamped on these lifeless things, The hand that mocked them, and the heart that fed; And on the pedestal, these words appear: My name is Ozymandias, King of Kings; Look on my Works, ye Mighty, and despair! Nothing beside remains. Round the decay Of that colossal Wreck, boundless and bare The lone and level sands stretch far away.”
  • tsukikage 3y ago
    The Palace - Rudyard Kipling When I was a King and a Mason - a Master proven and skilled I cleared me ground for a Palace such as a King should build. I decreed and dug down to my levels. Presently under the silt I came on the wreck of a Palace such as a King had built. There was no worth in the fashion - there was no wit in the plan - Hither and thither, aimless, the ruined footings ran - Masonry, brute, mishandled, but carven on every stone: "After me cometh a Builder. Tell him I too have known. Swift to my use in the trenches, where my well-planned ground-works grew, I tumbled his quoins and his ashlars, and cut and reset them anew. Lime I milled of his marbles; burned it slacked it, and spread; Taking and leaving at pleasure the gifts of the humble dead. Yet I despised not nor gloried; yet, as we wrenched them apart, I read in the razed foundations the heart of that builder’s heart. As he had written and pleaded, so did I understand The form of the dream he had followed in the face of the thing he had planned. When I was a King and a Mason, in the open noon of my pride, They sent me a Word from the Darkness. They whispered and called me aside. They said - "The end is forbidden." They said - "Thy use is fulfilled. "Thy Palace shall stand as that other’s - the spoil of a King who shall build." I called my men from my trenches, my quarries my wharves and my sheers. All I had wrought I abandoned to the faith of the faithless years. Only I cut on the timber - only I carved on the stone: "After me cometh a Builder. Tell him, I too have known."
    • 3y ago
• peter_retief 3y ago
  Think of the hours lost building code that becomes useless. This is one of my greatest regrets in writing code. I blame the likes of Microsoft that have consistently created bad frameworks that locked out other options and designed for their own buggy operating systems. This is still happening, one of the reasons I do not use Microsoft. Hang on I lie, I am using visual code on my Linux box at the moment.
• maxehmookau 3y ago
  The Strong Bad clip at the end just transported me back 15 years.
• hermitcrab 3y ago
  "In the long run. we are all dead". But I find it hard not to look at software and think how ephemeral it all is. All those late nights and all that debugging and it has mostly disappeared without a trace within 10-20 years. And that is the stuff that even got used at all. :0(
  • geraldwhen 3y ago
    Don’t stay up late. Work during normal business hours, and don’t stress too hard. Almost none of what most software developers are doing really matters.
• ascar 3y ago
  This might ring true for most jobs and especially for anything business related. If you go lower on the library, tooling or infrastructure side things tend to live on much longer, especially if it's simple but necessary functionality. Code doesn't automatically become technical dept just because it becomes older.
• robertlagrant 3y ago
  It's harder now. Way back when you could write ls and it would basically be a "done" piece of software to be distributed everywhere. More recently the big standards are enormous projects involving thousands of people, such as Docker or Kubernetes, that seem to have fairly unbounded feature lists. One exception: I think the jq tool could stay viable, if it made it into a standard toolset. It solves a defined problem.
• jpgvm 3y ago
  This is largely why I have tried to build as much as possible with OSS and contribute stuff as necessary to make that possible. OSS tends to have a much longer relevant shelf-life and experience with it, especially internals remain highly transferable skills. My work in and around Apache and CNCF ecosystems has been the only code I have written that truly endures in a good way rather than an ossified and decrepit legacy way.
• amelius 3y ago
  "Your grandfather was a brilliant man and his peers all praised him. Go ask him about it!" "Grandfather, what did you spend your life on?" "I made people click ads. Don't worry, it's all technical debt or deprecated now ..."
  • foderking 3y ago
    lol
  • winstonprivacy 3y ago
    This is such a silly statement. You could say it about practically anything. "Your grandfather was a brilliant man and his peers all praised him. Go ask him about it!" "Grandfather, what did you spend your life on?" "I fixed people's shoes. Don't worry, ..."
• DrScientist 3y ago
  Element of inevitability of course, but I have to look at those tech choices - largely from the MS walled garden - and wonder whether that was a factor as well. Do walled gardens not last as long I wonder?
• throwaway3838g 3y ago
  If a business lasts long enough for your code to be replaced, that’s a success. The code you wrote helped your company beat the odds and stay alive.
• ben_w 3y ago
  Similar vibes, looking back on my CV; now I'm the "grumpy old man" shaking his fist at reactive programming and VIPER…
• bryanrasmussen 3y ago
  My 20+ year career is technical debt, deprecated, or parts of governmental standards.
• theK 3y ago
  I find it interesting how tech that mostly comes out of enterprises tends to have a shorter shelf life than the "more open" options. > Basic, Silverlight, ColdFusion, asp... I'd add > Lingo, Flash Basically if Microsoft, Adobe or any other entrenched player make it easy for you to develop in it and they offer the only Dev stack then its probably going to die quickly. Counter case, apple seems to be doing fine with swift. So I might be wrong here.
  • ChuckNorris89 3y ago
    >Basically if Microsoft, Adobe or any other entrenched player make it easy for you to develop in it and they offer the only Dev stack then its probably going to die quickly. .NET and C# are heavily used, so is SAP and other corporate proprietary stuff. Enterprise customers prefer entrenched players that own the whole stack.
    • theK 3y ago
      Agreed. I also think it sort of makes my point. Afaik the .Net ecosystem started getting significantly more traction once they started opensourcing it and giving control to more open bodies. I don't know why you would bring up SAP though. I've dealt with SAP deployments in the past its usually the type of the project where you have to integrate through some arcane protocol due to reasons(TM) and the end results resembles less a live connection and more a sneakernet
• ilyt 3y ago
  That's like calling a chair you built 10 years ago "technical debt" because it can eventually break. No, it's just a fucking product you made. The fact it has to be maintained doesn't mean it is "debt", it's just like any other asset. You don't get to your car and think "that's technical debt". There is nothing technical about it. It's a tool with maintenance needs. The difference is choosing worse now to get it faster, that's technical debt.
  • hoodwink 3y ago
    thank you.
  • svnt 3y ago
    I was going to make a joke about how it isn’t all that surprising that a person with this history of language selection would completely misunderstand and misuse relevant technical slang in the English language. But I’m not supposed to sow discord so I won’t. The author navigates the technology world very differently than I do.
  • koheripbal 3y ago
    Well, a more accurate comparison would be if you made a chair 20 years ago, and now no one makes chairs anymore because we have all become robots.
    • Jorengarenar 3y ago
      If everybody became a robot and there's no need for chairs, then to whom is the technical debt supposed to be paid? If there are still fleshbags who need chair, the one created 20 years ago, if properly cared for, works just fine. Now, if I used a piece of rotten wood for one leg, because I couldn't bet bothered to go fetch a new plank, this is debt that will need to be paid in the form of putting additional work to fix said leg later.
  • rco8786 3y ago
    > The difference is choosing worse now to get it faster, that's technical debt. Right, but we always do that. We always make some tradeoff to get things shipped faster. And that's fine, otherwise we wouldn't ship things. It's a balance - and the general meta of "all technical debt bad" is harmful to actually building working software.
• fsniper 3y ago
  Am I reading this incorrectly or author is equating "using old/boring/forgotten techs" as technical debt? How did technical debt become so bloated and meaningless? Isn't it "remaining half baked/incorrect code, known edge cases, bad/slow implementations, or even bugs due to constraints imposed on the engineering team"? How is dead technologies are imposed constraints? Author is not talking about technical debt but experience that is not directly applicable anymore.
• rudenoise 3y ago
  I've seen things you people wouldn't believe... Attack ships on fire off the shoulder of Orion... I watched C-beams glitter in the dark near the Tannhäuser Gate. All those moments will be lost in time, like tears in rain... Time to die.
• syntheweave 3y ago
  The lessons I've learned from all my programming projects are: 1. If the codebase would still work on a "dead platform", but you are targeting something new, you are chasing after hype, to some degree. 2. If the code involves significant data entry, you probably want to leverage a spreadsheet, because eventually you will want to edit something tabular and also make charts and reports. The things "dashboards" do are also very reasonable to do from inside a spreadsheet - make a tiny shim to pipe in some data, and then make the dashboard frontend using all the built-in goodies. 3. If the code is mostly about making custom UI, you are on the path to saleable application software, or at minimum, a tech demo that people will talk about.
• forgotmypw17 3y ago
  I write a project using primarily a foss stack which has a 20+ year history of being committed to backwards compatibility, and I couldn't be happier. Utilizing the Lindy Effect to my benefit, I've been able to almost entirely avoid the typical framework frustrations, such as breaking changes and abandoned dependencies. Instead, I've been able to focus on features, figure out a good code style, and support nearly all mainstream or once-mainstream browsers. On the back-end, I'm working on the Windows install process, but on *nix it's fairly uniform across different flavors and lineages. For those curious, it is Perl, text files, PGP, HTML, CSS, low-sugar JS, and a little bit of sh, Python and PHP for server glue. Now probably to include batch files...
• 876978095789789 3y ago
  Will Rust succeed in eventually making all C (and even C++) code technical debt?
  • 3v1n0 3y ago
    I don't think it will... C will never die. If it does, congrats. But still so far C is for many things the prime access
• raincole 3y ago
  I mean unless the human as a species stop growing, all of your career will be deprecated one day, right?
• hoc 3y ago
  Lot's of "near-RAD" tools with large runtimes and platform/environment/framework dependencies in this list. The typical thing some of us tried to avoid while others (or their employers) totally embraced these comfortable (advertised as productive and fast) and often proprietary tools. The contrasting would be HTML, JS, C/C++, all closer to the bare metal of their respective targets. Or Java and Python as the two that made the race in more complex but purely language levels, as Rust is doing right now. Java has gotten connected more and more to its typical business frameworks these days, so beware :) Some of them died just with their platform as ObjC/Swift would die with Apple, Kotlin with Android these days. It seems a split between language and environment/frameworks has proven to provide some stabilty at least. Seldom (and funny) to see such a "consistent" list, though :) There might be something like "consulting work" as the recurring theme in it. As a product/system/platform developer one might have had (and would have been forced to) put more effort in selecting the tools for long term availability where they are not forced upon you by the platform or time-to-market considerations.
• mpeg 3y ago
  I've only been programming professionally for 15~ years and I fully agree with the article. In my career I've gone through so many tech stacks, most of which are dead or dying today. A lot of my projects you could today replace with a couple API calls or an AWS product. At least I like to think I learnt a few things along the way that make me a better developer, I never know what to say when recruiters or interviewers ask me about my tech stack experience expecting some sort of very specific answer – to me it makes as much sense as asking whether I have firefox experience, or just chrome.
• knorker 3y ago
  I made a whole bunch of things that have not been deprecated or tech debt. It's about which technologies you use. C is not deprecated. Maybe in a 100 years it will be, but it seems unlikely. It's very rare to find someone who has C as their favourite language, but it's incredibly persistent. C is the opposite of the latest JS framework. I regularly fix bugs in open source, where when checking when the bug was introduced the trail often runs cold in the mid to early 90s, as it predates that project's use of source control. But yeah, if you have a 20 year career of following what is clearly the latest fad, then you'll have that experience. Java applets were never "big". They were a fad, and promise of big. But they always sucked, even by the standards at the time.
  • Jorengarenar 3y ago
    > It's very rare to find someone who has C as their favourite language Hello, I visit here every day. Nice to meet you
    • knorker 3y ago
      You should make friends with Steve Gibson (https://www.grc.com/ https://www.grc.com/). He writes all his code is assembly. :-)
      • Jorengarenar 3y ago
        Don't worry, I personally know plenty of devs whose favourites are assembly, C, C++, Pascal, Perl... even BASIC, Fortran, COBOL or Forth! And surprisingly enough, among them, even the old farts aren't so old.
        • knorker 3y ago
          Bah, as someone who until recently had C++ as favorite language (now Rust), I'd say C++ doesn't belong on that list! But so say probably all those people too, about "their" language. ;-)
• samhuk 3y ago
  > My entire career is now technical debt, or the code has been deprecated. Contrary to the author, for me, over my entire career, I feel like I have been relatively incredibly lucky with my choices of 1) What (web) technologies to invest lots of time into, and 2) Therefore what tools I use in my own projects and at companies I have worked for. I think that 50% of the reason is down to when I was born and therefore when I started my software engineering career (for example, therefore avoiding lots of bad alleyways that web dev went down), and 50% was just common sense (realizing early-on that X tool was obviously going to be superior to Y tool). 1. I was fortunate enough to be born at a time such that I just about missed the AngularJS --> Angular2 betrayal + debacle. 2. I realized, through playing around with the Angular2 beta around 2014 (IIRC), that it was going to be inferior to React. I remember that at the time React was this tiny thing that had existed for around a year or so, but it was clearly conceptually superior, with more talented Facebook developers behind it vs the Google developers behind the early Angular2. Not to be too disparaging or direspectful, but at least in the early days, it felt like Angular2 was made by a team of your usual C++ Google engineers who didn't have a lot of experience with web dev. Just being honest here... This lead me to A) selecting React for my personal projects, and B) advising to pick React at companies I worked for. This meant that there are React codebases that I contributed to ~8 years ago that are still active at companies today. 3. Through sheer luck, I started my true web dev career after the "random crazy insecure web technologies" era such as Flash, Java applets, and all that nonsense. 4. Through sheer luck, I started my true web dev career shortly after Typescript was created, and I just happened to use a framework (now non-existent) which used it, co-introducing it to me in ~2014. This meant that I have been able to create relatively maintainable Typescript codebases, mostly avoiding creating any quick-to-deprecate JS mess-heaps. There are a couple more examples, but I think that captures why I feel so lucky. I feel bad for the engineers that, through a combination of bad luck (time born, time entering the field, etc.) and lack of foresight, were led down paths causing them to invest a tonne of time into technologies that were just never going to be around for the long-run. My time will likely come where my luck runs out, and I end up investing a tonne of time into some nonsense tech that initially seems solid but ends up rubbish for whatever reason, but for now, I'm quite pleased :)
• ChrisMarshallNY 3y ago
  > I would argue that any apps written in Objective C are probably technical debt now. That would probably include the lions' share of system code in the Apple OS ecosystem. I'll bet a lot of it hearkens back to the NextStep days. Since it is a UNIX OS (all of the OSes), then there's plenty of good ol' ANSI C, as well. I'm almost positive that every AAA app is still a ObjC BoM (Ball of Mud).
• kelnos 3y ago
  I kinda find the premise here to be flawed. To me, technical debt is stuff that you do intentionally that you know is bad and will have to be fixed at some point, but you've decided the trade off of shipping sooner is worth it. Sure, all code rots, frameworks and even languages come and go. That's not technical debt, to me, though. Put another way, if everything is tech debt, then there's really no point to having the term at all.
• ur-whale 3y ago
  When I look at the list of "technologies" the author invested in learning ... no surprise it's all technical debt or deprecated: all the things he lists are completely superficial and have obvious short-term, "I can make money now with this stuff" flavor to them. Had the author invested in learning stuff like math, physics, cryptography, advanced data structures and algorithms, functional programming theory, 3d programming, compiler theory, database theory, etc... None of it would be obsolete today, and all of it would be almost immediately applicable in any language that happens to be the flavor of the day at a given point in time. Let that be a lesson to all of the folks who become extremely proficient in the latest react-like fad javascript framework: in 10 years time, all your knowledge will be useful for one thing: maintaining and patching old crumbling code piles that no one wants to touch. Do yourself a favor instead and go learn timeless things that will still be completely relevant 20 years from now. Then spend a minimal amount of time learning how to apply it in whatever language/framework of the day is fashionable at your job.
• sam_goody 3y ago
  PHP. Still works and the codebase is still being incrementally updated ~20 years in. Stint with Laravel, which was a huge task to add, and an even huger task to eventually remove; After an update by Laravel that was not backwards compatible made us rethink the cost/value. Javascript on the frontend, with no libraries as critical infra except for HTMX. Was once a contributor to Mootools; now use quite a bit of homegrown funcs, and use libraries for spot instances (Alpine, Uppy, QuillJS - all of which are written modular with intention to be traded out.) MySQL and eventually Postgres. "NoSQL" only when it was added (as JSONB) to Postgres. All of those years of coding are an asset, not a liability. Don't go chasing the new and shiny, it doesn't last. (And steer clear of Web3, will ya?) EDIT: We use Tailwind - and time will tell if that is a mistake.
• mediascreen 3y ago
  > Fast forward to today, and MVC has since fallen out of fashion. Everything is now done in React, Angular, Vue, and other frameworks. I wouldn't be so sure about that. Fallen out of fashion perhaps, but still very stable, easy work with, predictable and with pretty clear best practices that don't change every three months.
• VyseofArcadia 3y ago
  I've been focusing lately on stepping off the new and shiny treadmill. While the kids and startups are chasing that new hotness, I can be incredibly productive in less fashionable tools that I already know.
• rawoke083600 3y ago
  Sooooo then LISP for growth, profit and staying power ? Sorta like how LISP might be the "Guns & Roses" of coding; Not everyone like it, but in their hearts they know it has greatness on some level. And no one can argue with their staying power :D
• austin-cheney 3y ago
  I predict WebAssembly will eventually overtake how front-end development is today, and a whole new world will evolve. I have heard this with great emotion for at least 6 years now and nothing. It’s starting to look like bitcoin: all these dreams and ideals that come to nothing in practice but a Ponzi scheme. The funny thing is that it clearly indicates nobody know what they are doing. People advocating for WASM want DOM bindings because the DOM is great and JavaScript is the great evil. Most people who actually write JavaScript professionally feel equally about the DOM, a great evil, and so they are completely reliant on some massive framework to justify the their existence.
• eimrine 3y ago
  > All code rots or gets replaced > Over time, you can see how almost everything you create gets scrapped and replaced for various reasons or is now based on old technology. Is this problem fixable by using some great technologies? React code does not rot and Common Lisp applications are famous as having the most time without getting rot among other programming languages.
  • Sarkie 3y ago
    React code does not rot? How so?
    • eimrine 3y ago
      There are no significant changes in architecture AFAIK. I used it just for fun a long time ago and may not know everything.
• frithsun 3y ago
  This is why I stubbornly refuse to use Typescript. Javascript is an ECMA standard. I'll just do the JSDoc hack and cheer for TC39 rather than waste my time with a technology that's great for now but will probably end up being technical debt. Think of how little somebody who uses C, bash, vim, and javascript has had to adapt in the past several decades, all because they avoided technologies where the buck stops with a community rather than a corporation. Corporations are cool and all. I'm not a dirty hippie. But at the end of the day they don't make money when things don't change.
• chasd00 3y ago
  I’m assuming your paychecks didn’t bounce over those 20 years so who cares?
• kohlerm 3y ago
  After 20 years (for me) Java is still kind of alive
• papito 3y ago
  Don't get attached to your code, ever. You are not building the Pyramids of Giza, no one will study your work 3000 years from now, or 15, for that matter. ALL of your code will be dead in a few years. The company goes under, or some punk CTO comes in and commands a "full rewrite ASAP!". Even with normal evolution and refactoring, your original work will be unrecognizable. Either way, you take experience and friendships from your employment, you are not going to be the Picasso of software engineering.
  • Jorengarenar 3y ago
    You forgot to put "\s" here. But I appreciate the Picasso joke. Too many devs try applying over-engineered abstraction to simple problems. ------ From this place I want to greet one such "Picasso" whose code from over 20 years ago I was debugging last week... I know your name...
• joemasilotti 3y ago
  > Ruby on Rails is in jeopardy of being added to this list. It has fallen out of favor, and it is tough to find developers for it. What once made it unique is now available in other languages. I beg to differ. There are 1000+ Rails developers actively looking for work on railsdevs.com
  • rco8786 3y ago
    Yea Rails seems to be having a bit of a renaissance moment right now
• rco8786 3y ago
  Agree with the premise. I currently work with a PM that is simply terrified of introducing any technical debt or "throwaway work". Mind you, he isn't writing or maintaining any of the code himself. It's like pulling teeth getting him to realize that we have to ship some product in order to learn, and some of what we will learn will be what is WRONG with our product and needs to change (aka throwaway work) and that every codebase eventually becomes a legacy codebase (aka technical debt). I think we've done ourselves a very big disservice as an industry by focusing on this boogeyman.
• kunley 3y ago
  By the way (not to diss author's involvement in windows-related technologies) I am very happy to still use many of the inventions of Mr Ken Thompson that did not become technical debt and it's unlikely they will (apart from being rewritten/transformed).
• antomeie 3y ago
  I still maintain apps in Objective-C, but I don't view them as technical debt. I find it mostly fun to maintain the knowledge. One day the apps (products) may themselves become technical debt, but that is not the fault of the language they were written in.
• MadSudaca 3y ago
  it’s paradoxical but the opposite might be true as well… code you’d be happy to hear was replaced because you were not particularly proud of it, turns out to live on for a long time having people maintaining it without understanding it very well long after you’ve left the organization
• cookieperson 3y ago
  I wish more mid career devs understood this. All those PR review battles over commas in comments are mostly wastes of time. Entropy comes, it's one of the few guarantees we have. Your legacy will not be the software you wrote, but the impact that software had.
• p0w3n3d 3y ago
  Flaaash! shouting in Will Shatner voice
• gadders 3y ago
  Interesting article. I wonder how, say, builders or architects feel when a building of theirs is demolished.
• hudsonhs 3y ago
  I use an open-source version of ColdFusion at the company I work for that was founded 10 years ago. I mean, I don't like it but...
• markb139 3y ago
  Some of the stuff I’ve worked on (Nokia phones) have been museum pieces for some time
• Jeff_Brown 3y ago
  The guy is still coding for money, right? So clearly he managed to absorb something that's still valuable.
• nologic01 3y ago
  In the future there won't be any technical debt. You were lucky to live early. Code, most code, will eventually turn into some sort of sanitised applied maths corpus (with a heavy overlay of "AI" analytical tools). In applied mathematics you have cultural obsolescence (stuff that we no longer find interesting or relevant, like an asymptotic formula for the Airy function [0]) but the corpus is intrinsically add-only. Once something is solved it does not have be solved again. Its essence is eternal, so to speak. Think about code development in such as mature state. It will mostly work by pulling together (using AI prompts) logical units from the future version of Rosetta [1]. When we get to that stage it will be hard to add something truly new. Just like it takes a long incubation and a PhD to add some marginal new thing to applied mathematics, it will take effectively trained applied mathematicians to add something minor to the evolving code corpus. Coding for the common folk will be mostly compositing. It might be productive and even fun, but not quite the same. We lived through a period of widespread democratization of development. Cherish the freedom of reinventing the wheel in countless flawed ways :-) [0] https://en.wikipedia.org/wiki/Airy_function https://en.wikipedia.org/wiki/Airy_function [1] https://rosettacode.org/wiki/Rosetta_Code https://rosettacode.org/wiki/Rosetta_Code
  • phkahler 3y ago
    >> Code, most code, will eventually turn into some sort of sanitised applied maths corpus >> Think about code development in such as mature state. I agree with you. That end state is of course all open source. Anyone not working toward that state is making money (understandably) as the higher priority. I'm still not sure why businesses do so much proprietary customization as opposed to working in an upstream OSS project. I suppose the OSS foundation in those cases isn't solid enough yet.
• mathgladiator 3y ago
  > Developers jump ship quickly this is probably the most damning thing about the field. We don't invest in developers, so why would they invest in the business?
• efields 3y ago
  > Ruby on Rails is in jeopardy of being added to this list. It has fallen out of favor, and it is tough to find developers for it. Hardly. > What once made it unique is now available in other languages. Sure, yay open source. You still can't get as much out of the box with one CLI command for a new rails app in node.js. I would love to be corrected on this.
• FpUser 3y ago
  All my desktop GUI software since 90s was / still is done in Delphi (Lazarus for multiplatform). The language / IDE grew but remained compatible and I've never had to throw away the code. C++ merrily carried my backend solutions over the same timeframe with the same results. Same for C when writing firmware. Same for JavaScript / HTML for browser based front ends. In all of the above I used some domain specific libs but stayed away from big frameworks as those come and go pretty fast. I consider neither as a tech debt as they let me concentrate on the product rather than dwell on what tech do I use. I've never felt inferior for not using this new and shiny doodad as I've always delivered superior products and that is what mattered for my clients. Yes I had to program in whole bunch of other languages upon client requests but this was rather rare. I have good track record in creating new products from scratch and that is what my clients really want. They mostly do not care what I use for development. So no. I do not feel that tech debt at all and I still play with other tech a little to stay current in case it is needed by client.
• Mister_Snuggles 3y ago
  Interestingly enough, I've got a thing for "ancient" technology. My dream retirement job is to work at a tax agency, like CRA or IRS, and help maintain their mountain of COBOL. I don't know COBOL, I don't know the ecosystem around it, but I absolutely know that I would love to learn it. My first job was in a similar environment, supporting a homegrown application (which had grown out of a long-defunct commercial application) running on a Pick-style database system (UniVerse). The whole thing could trace its roots back to a Prime mainframe. Reading the code, especially the older stuff, was such an adventure. ScarletDME[0] is seriously scratching the itch to play in this world. [0] https://github.com/geneb/ScarletDME https://github.com/geneb/ScarletDME
• Avalaxy 3y ago
  I'm a freelancer in data engineering / machine learning engineer. I've so far never held a role that I had the technical skills for (well... I do have the underlying knowledge, but not the particular frameworks/tools), because every time my freelance project ends and I'm looking for the next one, the tools have already changed to something else that is hip. Or the go-to architecture is now a different one. Or the way you deploy it all is completely different. It's pretty frustrating. I keep trying to do courses to keep my skills up-to-date, but it doesn't matter. Those courses by themselves are already outdated a year later. The only things that have been solid in my career, is the CS knowledge and theoretical knowledge from books like 'designing data intensive applications'. That stuff rarely changes. The rest is like waves in a sea. They come and go.
• metafunctor 3y ago
  The stickiest code I ever wrote was an open source library released in 2000 or thereabouts. It’s still in use, and still new users are adopting it. Someone made a Wikipedia page for it. I think it’s embedded in most Apple products. Other than that, yeah, most of what I’ve made is no longer used by any significant number of people. Not sure if there’s any wisdom to draw from this anecdote, but I did spend a lot of cycles in trying to perfect that library!
• agentultra 3y ago
  That's a lot of fad-based tech in this article but you do what you have to do. The first language I used professionally is not the same language I use today. However any one of them certainly could have become "fad" tech... except maybe C, Lisp, and Haskell; those ones seem to be built on foundations (discovered or invented) that are repeated, rediscovered, or reinvented but rarely change. I generally think of "fad" tech as frameworks and ecosystems that are built around a commercial interest or novel idea. They often fail to overcome network effects. And this leads them into obscurity to await deprecation. There's a lot of churn that happens in the frothy red waters of "trying to make programming easier/faster/accessible-to-non-programmers". And we're not so great at maintaining our legacy, the state of the art, the pedagogy and history of our science. Over a twenty-plus year career I've seen people re-invent solutions to the same problems over and over. Each time it's a revolution. You don't want to dishearten the young and eager but at the same time seeing them run into the same problems, learning the same conclusions, etc means we've not been doing a great job at teaching and mentoring and all that.
• knallfrosch 3y ago
  All 5 years of my web software development, I've ported code to Angular. I've read your legacy code, and ported it to a framework that's already in decline. Of course it's all legacy.
• mark_l_watson 3y ago
  I don’t disagree with the author, but I don’t worry much about old tech that is no longer useful. I have worked in the field of AI for 40 years, and we have had a huge trash heap of technologies that ended up being useless except for lessons learned from failure. I have always been motivated to work for just two reasons: supporting myself and my family, and learning and using new tech. The great fun is in learning new things. That said, sometimes there is good short term work supporting old tech that companies still want to use.
  • PurpleRamen 3y ago
    > huge trash heap of technologies that ended up being useless except for lessons learned from failure. The joke is, even the lessons will deprecate at some point, either when younger generations, who did not learn/understand them yet, will enter the playing field, or because the progress of technology will invalidate the lessons. Nothing is really meant to stay.
• bgirard 3y ago
  This is why I'm particularly proud of my contributions to (web) standards. There's a good chance that they'll be my longest lasting contribution.
• carapace 3y ago
  I used to feel bad about how much of my career was waste. Then one day I met a retired hardware engineer, a old hand who had rubbed shoulders with Shockley, who told me that 80% of the projects he worked on never even made it to production. Four-fifths of his hardware career was waste! If it's that bad in hardware land I don't feel so bad about this virtual detritus we software people spew. At least it's cheap, eh?
• UncleOxidant 3y ago
  All of our work is ephemeral. Software development is just more ephemeral than most work. 40 years ago when I first got into this biz I didn't notice this. Now I notice ephemerality everywhere. You need to make peace with it. The things you're working on now probably won't be used or useful in 5 years. An architect can drive by a building they designed and take pride in that building for decades... but even that building will eventually come down. It just happens a lot faster in tech.
  • spiffytech 3y ago
    Even the goal of doing something that will outlive you is an arbitrary bar: you are "settling" for mere centuries. Making something that really lasts is hard. My favorite example is the Clock of the Long Now, a timepiece designed to operate for the next 10,000 years: https://en.m.wikipedia.org/wiki/Clock_of_the_Long_Now https://en.m.wikipedia.org/wiki/Clock_of_the_Long_Now
• momirlan 3y ago
  that is true for front end dev. not so much for back end. SQL, Oracle, Sql Server, Teradata, Data Warehousing are still used after more than 20 years. Skills are easily transferable to Snowflake, Big Query, Azure ...(whatever it's called at this moment)
• AlwaysRock 3y ago
  > Ruby on Rails is in jeopardy of being added to this list. It has fallen out of favor, and it is tough to find developers for it. Ruby is the 8th most popular programming language. Ahead of C, C#, and a bunch of "cool" languages like Scala, Kotlin, and Rust. Source: https://madnight.github.io/githut/#/pull_requests/2023/1 https://madnight.github.io/githut/#/pull_requests/2023/1
• AlwaysRock 3y ago
  Kinda a weird article to be honest. It seems less like the author is annoyed at having to learn new languages or that their language specific knowledge because less useful as time goes on, and more that they are frustrated their code doesnt live on forever. I guess I don't particularly care if my code lives on or not. I build something. It's hopefully useful for others or myself for some period of time, then its gone. It's just lines I've written. Why would that be more important than other lines I've written? In other careers I never thought about how my work was eventually going to be forgotten. That's just how life goes.
  • pc86 3y ago
    I felt the same way. If you want to build something permanent and long-lasting, go build bridges. It does seem kind of silly to expect software to be around for a long time.
• Cerpicio 3y ago
  Don't be sad because your code is old. Smile because you got to write code. -- Me (paraphrasing Dr. Seuss)
• amne 3y ago
  From my few years in e-commerce I noticed this kind of pattern: - you(your company/employer/etc) have a problem. - you solve said problem - profit - competitors catch up and hit the same problem - 3rd party (or one of the 1st parties pivots) notices all of you have the same problem. implements solution to fix the generic version of the problem: a standard is born - hubs appear that make it easy for your competitors to eat into your market share because they now use the 3rd party solution and are more agile. - you can't integrate because your solution is not complying to the new "standard" - rewrite is needed (edit: I hate HN formatting)
• dep_b 3y ago
  Skills I learned and are still valid today: - SQL - Terminal - OO programming travelled pretty well from C#/Java to Objective-C to Swift Then there's stuff that is still called the same but completely unrecognizable compared to the time I was good at it like HTML / JS / CSS
• g9yuayon 3y ago
  Is it just me or somehow programming languages and frameworks are not my focus any more? I'm still interested in programming language designs and implementations, but I'm quite neutral on what language/framework to use in my work. There are just too many other things to take priority: organizational structures, system architectures, emerging technologies, new hardware, algorithms, insights in a domain, and etc. Choice of languages barely moves the needle.
• TheRealDunkirk 3y ago
  I've been down on myself about this. I've been at it for coming up on 30 years. I've written scores of programs and applications. There are only a couple still in use. Rather than be upset about it, I find that it's more helpful to think of coding as tooling. As in, actual tooling that machine shops make: dies, jigs, gauges, etc. You know, the stuff that's used to make the actual stuff. Tools go out of date. Tools get upgraded. Product lines change. Tools get scrapped. It's all ephemeral. It's just the nature of it. And this applies to "the bigs" as well, like Facebook or Google. The individual components and services are just tooling in service of the overall product, and rollover and change as time goes on. The only coding that ossifies into archeological strata is COBOL on mainframes.
  • lcnPylGDnU4H9OF 3y ago
    Over time I've come to realize that the various "IT things" in business which retain the most value are databases. Not because they never become outdated or redundant but because the data in them can always be migrated to a new schema to be used by a new application. Usually the "tooling" to do this is exactly the kind of work I might do which becomes something that is no longer in use. (I guess here I should mention the context that I'm not coming up on 30 years; instead it's a little over 10.) The "no longer in use" part is something I think I ultimately disagree with. It's kind of an "application of Theseus" situation. Where did this data really come from? If it was an older application, did that application ever really go away or did it just become what replaced it? Anyway, I guess I just have to hope I still have this outlook in ~20 years.
• bdhndnd 3y ago
  Today’s best practice is tomorrow’s technical debt. Paint that shed.
• orsenthil 3y ago
  The point this piece is missing is, the defining tech as how marketing defines product. Customer needs evolve and products need to change to cater to that. It is just evolution. The work that under powers the solutions (C Programming language for instance), hasn't changed.
• kazinator 3y ago
  Years before this guy got started, I was working in C. Then I moved onto more C, C++, then back to C. Today I'm working in a C++ codebase that compiles to C. Lisp on the side, plus the Unix cruft that goes with build systems: shell, awk, make, ... I went through the language churn as a kid. BASIC, assembly languages, Pascal, Modula-2. Studying CS pulled me into C world; all the upper level coursework at that time was systems programming in C on Unix, whether it be compilers, networking, distributed systems, operating systems or computer graphics or what have you. I didn't think I'd be cranking out C for another 30 years after that, but I also didn't think of any reasons I wouldn't be. Not everything I worked on is around; but the skills left behind are entirely relevant. There is hardly any technique I ever used that is inapplicable.
• ironmagma 3y ago
  Not anymore, now we have JavaScript and that stuff will simply run until the apocalypse.
• kangaroozach 3y ago
  So what are the current languages and frameworks that are least likely to soon become “technical debt”? We use Python, Django, Node JS, Next JS, React JS. How do those fare?
• lofaszvanitt 3y ago
  Use jQuery. Let others jump on these speeding, then derailing trains and collect their broken bodies at the crash sites years later.
• sershe 3y ago
  I left a company once due to some reorg/internal politics while we were in the middle of developing a new system from scratch. 6 years later, I was going to leave my then-current job and I got some interest from my old team (that was by that point made up of almost entirely different people) where part of my job would be... decommissioning and migrating tons of people off the system I was developing 6 years ago! I also had expertise in the new stuff they needed but I thought that was funny and also I think it helped me negotiate a good offer...
• berkeshire 3y ago
  The idea of leaving behind a lasting legacy of work is vanity squared. The ones who do selfless work for open-source do not necessarily do it for a place in history. The point of choosing a purely materialistic software career was to have the ego humbling of watching one's work get decimated or trivialized in due course.