Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My 20 year career is technical debt or deprecated

blog.visionarycto.com

Post reply on HN
Print view View original

151–160 of 585 posts

Re: My 20 year career is technical debt or deprecated

#151

Post by throwaway2037 »

emodendroket wrote: post #99
MartinMcGirk wrote: post #18

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 proble…

> If there’s a software equivalent of a Cathedral then I still haven’t found it. Probably like, some parts of Windows or Linux, or GNU tools, or some thing like that that, while still being updated, also has ancient components hanging around.

Good point about GNU coreutils: https://www.gnu.org/software/coreutils/

Also: That includes the man pages. They should be around in 50 years.

Re: My 20 year career is technical debt or deprecated

#152

Post by Tade0 »

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.

Re: My 20 year career is technical debt or deprecated

#153

Post by TacticalCoder »

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

Re: My 20 year career is technical debt or deprecated

#154

Post by biorach »

chriscappuccio wrote: post #77

The dude equivocates programming in Perl to programming in FoxPro, both are simply "deprecated" and "hard to find." Is this true?

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.

Re: My 20 year career is technical debt or deprecated

#155

Post by nabogh »

comte7092 wrote: post #49
SoftTalker wrote: post #24

> printing from the browser was its own fun nightmare Remember Crystal Reports? Oh god, the pain. The pain.

Remember? If only. I work outside of tech. We still use it.

Yep still kicking in the water industry in Australia. Glad I left that behind

Re: My 20 year career is technical debt or deprecated

#156

Post by VaxWithSex »

throwaway71271 wrote: post #91
hedora wrote: post #5

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…

what exactly is 10x better than 5 years ago? the technology gets better but the outcome gets worse somehow. most of the programs i use (besides the browser) are 20-50 years old (paste, cut, xterm, grep, emacs etc), almost any new thing i try is horribly slow (slack, whatsapp etc, the mac terminal app, even the mail app is slow compared to mutt) open a web page on a computer without adblock and look at what we have bu…

ripgrep

Re: My 20 year career is technical debt or deprecated

#157

Post by noobermin »

FrustratedMonky wrote: post #34

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…

It isn't necessarily a cycle, a lot of the issue is just a cultural issue with software development. You can change culture, however slowly, it can change.

Re: My 20 year career is technical debt or deprecated

#158

Post by tasuki »

djbusby wrote: post #31
29athrowaway wrote: post #15

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.

Why not just say what's common (over hyped dead-ends)? Snark don't make you sound smarter.

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!

Re: My 20 year career is technical debt or deprecated

#160

Post by sgtnoodle »

spease wrote: post #95
sgtnoodle wrote: post #22

Earlier quoted context omitted.

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 ::writer::new( connection.clone(…

I’m not sure why the API wouldn’t implement Write for connection so you could do: connection.write_all(data) Where data could be an argument that impls ToOwned or Into so that it would either use the object you pass in (if by value) or implicitly clone it (if by reference). Basically this looks more like an API design problem than a limitation of the language.

My example wasn't meant to be taken so literally. I'd say there's some truth to there being an API design problem to untangle, though. It's a relatively new language in a repo with dozens of contributors all frantically trying to get their work done. I'm just the salty senior engineer that's getting sucked in before wheels fly off. Stepping back even further, I think there was perhaps an overeager desire to use multithreading, both unnecessarily and at the wrong level of abstraction. That lead to a lot of lifetime management complexity at the lowest, deepest level. Then, folk slapped on progressively higher level abstractions, applying band-aids as they went rather than refactoring the lower layers.
Post reply on HN