Live data from Hacker News

My 20 year career is technical debt or deprecated

blog.visionarycto.com

161–170 of 585 posts

Re: My 20 year career is technical debt or deprecated

#161

Earlier quoted context omitted.

Core Libraries/Kernels, like LibC or The Linux/NT Kernel.

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.

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.

Re: My 20 year career is technical debt or deprecated

#162

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…

> as I tend to over-engineer systems and constantly doubt / second-guess my technical decisions

I find this as well. I also think that there is a sub-conscious fear as you become more senior that you need to justify that with more elaborate/complex solutions. In my experience there are also a lot of people in software who never come out of the other side of that view and constantly equate "complex" with "good". Being in an environment with lots of people like this makes it hard sometimes. Ultimately you need to trust yourself and do what you think best. If it goes wrong, at least you know you did it for the right reasons.

Re: My 20 year career is technical debt or deprecated

#163

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…

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.

Re: My 20 year career is technical debt or deprecated

#164
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.

Re: My 20 year career is technical debt or deprecated

#166
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...

Re: My 20 year career is technical debt or deprecated

#167
post #103

Earlier quoted context omitted.

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...

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.

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.

Re: My 20 year career is technical debt or deprecated

#168
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).

Re: My 20 year career is technical debt or deprecated

#169

Earlier quoted context omitted.

I think this is by far the most common outcome for work. A chefs product only lasts an hour at most. Most jobs don’t create anything other than a temporary service.

> A chefs product only lasts an hour at most. A chef's recipe, which is also something the chef creates, may last hundreds of years.

That's a very romantic view of the life of a chef but I'm afraid that by an overwhelmingly enormous margin the output of a chef is servings of food not century-spanning recipes.

The comparison between developer and chef is kind of a stretch but there is a similarity of sorts. It could be argued that the recipes are analogous to the algorithms or patterns that we use day-to-day in software development, and that the servings of dinner are analogous to the applications we build. The algorithms/patterns and recipes might persist for a while, the apps and food have a shorter lifetime.

I'm not advocating for throwaway or disposable code (though I'm not above implementing a quick hack, personally) but I don't think we need to think less of ourselves or our profession because we're producing things which currently have a shelf-life of years or decades at most.

Re: My 20 year career is technical debt or deprecated

#170

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…

But it will be an issue _eventually_... hopefully you'll be able to move the workload onto a VM / emulator easily.
Post reply on HN