Live data from Hacker News

My 20 year career is technical debt or deprecated

blog.visionarycto.com

431–440 of 585 posts

Re: My 20 year career is technical debt or deprecated

#431

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

Conversely, I’ve often heard people say they like working in tech because they’re “always learning new things!” It seems pretty clear to me that most of the stuff I learn in tech is a total waste of time, except for the fact that I need to understand it to get paid. It feels as if I’m learning how to work on puzzles in a book. (eg, Sudoku, or other logic puzzles.) It might be interesting to work through them, but they don’t really have any value in my life.

Re: My 20 year career is technical debt or deprecated

#432

Earlier quoted context omitted.

I've seen people take Bob Martin's concepts and do some truly awful things with it. Mind-bogglingly awful contortions of concepts into classes in arrangements that have to be sourced from demonic inspiration. At the same time, I've seen the best code of my entire life formed from his concepts. Code that will last decades, far outlasting the UIs that feed it data or the databases that will store it. I think the differ…

Your last paragraph is really interesting to me. It obviously makes total sense. Yet, three environment I've used most in my career is Rails which also splits these things into folders by type rather than feature. It's never bothered me. Now I wonder if that because Ruby isn't Java and folders aren't packages or because I'm so very used to it.

I've worked in a few codebases that tried to group things by feature. In my experience, it never really worked that well.

Usually there would either be poor isolation between them or they'd be so well isolated that I'd wonder why they were even in the same project. In the latter, they'd often be difficult to maintain because of a web of dependencies pulled in by the little isolated subfeatures.

I prefer the separation by type, tbh. It also has the upside that it naturally encourages the developer to follow the same patterns within that particular package.

Re: My 20 year career is technical debt or deprecated

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

Re: My 20 year career is technical debt or deprecated

#434

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…

Does anybody know where I can find a good, substantiated, critique of the common Java coding patterns, including on Android? This niche is such a huge mess that simply documenting all the bad things in a single codebase (along with explanation why they're bad) took me a month. It's tiring and mentally draining to do this: every other line of code you read makes you go "Why. Please, just tell me why anybody could ever…

Those Kotlin issues are common when a lot of engineers from one language switch to another at the same time.

We used to see the same thing with companies that had moved C engineers over to Java. Lots of weirdly overcomplicated C constructs. Meanwhile the newbs who only knew Java were writing FactoryFactoryFactoryImpls. :facepalm

Re: My 20 year career is technical debt or deprecated

#435

Earlier quoted context omitted.

Does anybody know where I can find a good, substantiated, critique of the common Java coding patterns, including on Android? This niche is such a huge mess that simply documenting all the bad things in a single codebase (along with explanation why they're bad) took me a month. It's tiring and mentally draining to do this: every other line of code you read makes you go "Why. Please, just tell me why anybody could ever…

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: “…

> You can always tell when code was written by someone who’s arrived fresh from Java or C++.

AS3 and Flex was practically an attempt by these people to take over the language. Thankfully that failed.

TS is great by comparison!

Re: My 20 year career is technical debt or deprecated

#436

Earlier quoted context omitted.

Saying that a software is god awful when it's commercially successful is not a good argument. Certainly tons of people and orgs out there are deriving value out of it. I still have to see anything that comes closer to Confluence for arranging organisational knowledge

Do you imply a positive correlation between quality and commercial success? I don't think I can name many instances of this, really. E.g. by far the most commercially successful video games are the bottom-of-the-barrel casinos for kids.

I am implying that there's evidence that more people like it and are willing to pay for it than people not finding it upto the mark. Yes, that's the definition of a successful software.

Re: My 20 year career is technical debt or deprecated

#438

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

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

Re: My 20 year career is technical debt or deprecated

#439

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

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

Re: My 20 year career is technical debt or deprecated

#440
post #400

Earlier quoted context omitted.

> “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 bec…

No, it's not extra functionality, it's a crutch

> being able to override the getter/setter in a subclass

I think even C++ can do this without an explicitly named getter/setter

> and keeping a consistent interface so users don't need to change how it's called

Just use a better language

> Python has @property to maintain that interface if need be

Exactly. Java is unjustifiably limited in this regard

Post reply on HN