Live data from Hacker News

My 20 year career is technical debt or deprecated

blog.visionarycto.com

391–400 of 585 posts

Re: My 20 year career is technical debt or deprecated

#391

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

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

It's also entirely possible you were encountering them more than you thought. My highschool website, for example, had around 4-8 on the homepage - minimalistic applets that simply showed and cycled through images, placed in a grid in the header area. They totally could have been javascript instead, you couldn't tell the difference just using the page.

Re: My 20 year career is technical debt or deprecated

#392
post #62

Earlier quoted context omitted.

aren't pdftex and xetex just patched versions of tex82

Maybe, but I've moved on to tectonic. Which surely isn't in the same language.

Last I checked (though it's been a while), I think tectonic basically wrapped the xetex code.

Re: My 20 year career is technical debt or deprecated

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

Re: My 20 year career is technical debt or deprecated

#394
post #36

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…

People are commenting core OS libraries and kernels, but the Space Jam movie website from 96 is still up. I bet the guy that wrote that didn't think it'd be around nearly 20 years later, I hope it never goes down. https://www.spacejam.com/1996/jam.html

Funny that the original Space Jam website can be considered the internet's equivalent to a cathedral.

Re: My 20 year career is technical debt or deprecated

#395

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

> long dead techs that I didn't bother to learn.

this is how I currently feel about Kubernetes and docker. I'm having all sorts of fun with the JVM, a monolithic jar, and about 20 lines of shell script. I can deploy in 20 seconds without much fuss.

Re: My 20 year career is technical debt or deprecated

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

Re: My 20 year career is technical debt or deprecated

#397
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

Re: My 20 year career is technical debt or deprecated

#398

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's a good thing if the environment around your VB6 stuff can still work with it, or accept it. Many systems get replaced when the substrate they run on is no longer supported as in "won't run on any hardware still in its warranty cycle or with parts available", or everything around has changed and the layer of glue needed to keep the old system alive and talking to everything else has grown to be prohibitively complex and expensive and is now more like a load-bearing structure by itself. If you can replace it and also fire warm bodies who used to keep it alive by being the irreplaceable wizards with arcane knowledge and job security, it just might be a net win.

I hear tales about several layers of emulators the sources for which are forever lost, with the bottommost of them running some very mission critical early COBOL or ALGOL-69 (or Lisp, who knows) code written back in the days when it had been that newfangled thing young guns liked, and which no one now can reimplement today (maybe because elves have died out from smog and the golden age is over), but they may be bunk.

Re: My 20 year career is technical debt or deprecated

#399
post #358

Earlier quoted context omitted.

> 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. Guilty as charged! I hate using Java because everything written in java seems to blend into the same indistinguishable swamp of classes with meaningless names, full of methods that constantly find new and interesting ways to obscure what your program is actually trying to do. De…

I've spent most of my programming life working in OOP. I see people critical of it, but I don't know what the alternative is for the kind of stuff I do for my job (not to say I have a choice in changing how we do it). Does anyone know of an open source project that implements a complex GUI app that doesn't use OOP so I can see what that code can look like?

[deleted]

Re: My 20 year career is technical debt or deprecated

#400

Earlier quoted context omitted.

Hah. I’ve spent several years writing javascript for a living. You can always tell when code was written by someone who’s arrived fresh from Java or C++. Their code is full of hundreds of lines of useless classes which can often be replaced by a few simple object literals. Unlike class instances, object literals can be easily json stringified and parsed, too! You can torture people who are like this in code review: “…

> “This isn’t idiomatic. Please rewrite this code without the class keyword”. I’ve seen people people make a face like I just had their child expelled from kindergarten. Lol true Don't forget all the getters and setters merely updating/reading a variable Python says "explicit is better than implicit" but Java goes too far with it, and in the most verbose/inflexible ways possible

> Don't forget all the getters and setters merely updating/reading a variable

> and in the most verbose/inflexible ways possible

It's actually extra flexibility meant for two things: being able to override the getter/setter in a subclass, and keeping a consistent interface so users don't need to change how it's called if there was a refactor that adds something to the getter/setter (such as transforming the value because a different representation was more useful internally; particularly useful for libraries).

Python has @property to maintain that interface if need be, but these Java conventions started when no such thing existed in the language. I haven't done Java in a long time, so I don't know if it has it even now..

Post reply on HN