Live data from Hacker News

My 20 year career is technical debt or deprecated

blog.visionarycto.com

491–500 of 585 posts

Re: My 20 year career is technical debt or deprecated

#491
post #220

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

It baffles me it's the only comment pointing this out and it's not even at the top.

The rest of commenters for some reason seem to equate "technical debt" with old technology and "legacy" projects.

Re: My 20 year career is technical debt or deprecated

#492

Earlier quoted context omitted.

> It's very rare to find someone who has C as their favourite language Hello, I visit here every day. Nice to meet you

You should make friends with Steve Gibson ( https://www.grc.com/ ). He writes all his code is assembly. :-)

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.

Re: My 20 year career is technical debt or deprecated

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

Unfortunately users are not seeing 10x better performance with the average application. A bit of the curse of more resources leads to using more resources wastefully.

When I look at team sizes for '80s and '90s programs, and how fast those teams worked, and consider what I'd expect to be the team size for a modern program tackling the exact same features and how long I'd expect development to take, it also makes me wonder just how much these supposed productivity improvements—which are promoted as where these benefits are being realized, since they're plainly not showing up in program & system performance for the user—actually, like, exist.

Re: My 20 year career is technical debt or deprecated

#495
post #102

Earlier quoted context omitted.

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.

Wait, wasn't Perl 6 rebranded as new language Raku?

I believe so, after years of being vapourware and basically stopping Perl 5 development right when web as a platform started being important.

Re: My 20 year career is technical debt or deprecated

#496

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

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

> 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. Debugging very large Java codebases feels like living through Terry Gilliam's 1985 film Brazil.

That describes just about every codebase I've worked with that relies on object-oriented patterns, which is basically every codebase. This is particularly bad with Java, but as you mentioned, this is a cultural problem and not so much a language problem. I like Java the language, but what kept me away from it was every Java codebase I've seen. Layers upon layers of needless abstraction, overly abstract names, and so much code is meant to describe things rather than a sequence of data changing.

It's not that OO is completely wrong, but it's a meme that we as programmers are refusing to shake. It's like people are still getting taught OO in college courses by programmers who haven't worked professionally in decades, and those students are still going into the real world thinking that everything's gotta be object oriented. And usually what OO ends up meaning is having classes and inheritance and "this" and mutability, as opposed to having objects that pass each other information. The latter doesn't need classes, or inheritance, or any of the other similar features in programming languages. But if you've got to write to a file, then you've gotta make a class that wraps the file system functions, right? /s

Re: My 20 year career is technical debt or deprecated

#497

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

> my way to feel good is to look back at all the long dead techs that I didn't bother to learn.

That's how I feel about design patterns. Talk about the most useless pile of academic bullshit that gets overemphasized in terms of what "every programmer" must know before going into an interview. Although there are some domains where they may be necessary to know of the top of one's head, for the most part there's usually no utility in filling your head with individual ideas that worked in one circumstance but may lead to bad patterns in another. I'm so glad I gave up memorizing design patterns, especially given that many employers seem to have lost interest in trivia questions about design patterns as well.

Re: My 20 year career is technical debt or deprecated

#498

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…

The problem with Uncle Bub is that his views only work in sync within very limited situations such as hobby coding and small projects by a handful of developers who are starting on the same page. A lot about Uncle Bub's teachings and FrAgile isn't practical in most of the real world besides a minority of outlier stories (and the problem with those stories is they don't track whether practices continue working long term).

Take his views on "clean code" for instance. Or really any conception of "clean code." Clean code is bullshit. I guarantee you can take anything Uncle Bub or other notable programmers say about clean code, apply them to a tee at your job, and be told that your code isn't clean or "feels icky" by whomever joined the team before you did. No description of clean code that I've read has ever been truly helpful in my career. The only thing you can really do is decide what you think is clean code and for you and your team to reach a level of agreed disagreement so that everyone can get their job done. One person's descriptive variable name is another person's "that's too long I can't read with all these confusing names", and one person's set of short purposeful functions is another person's "I can't tell what's happening cuz I have to jump between all these functions." At the end of the day, you barely have time to write "clean code", because your boss wants features rolled out ASAP.

Uncle Bub is also one of those guys who thinks good code doesn't need comments because it's self descriptive. This is one of the worst ideas to ever have met the software industry. No one's code is self descriptive. It's all a bunch of gobbledygook because it's meant to be run by a computer and just understandable enough for a human. It wouldn't kill us to just write some documenting comments detailing the intention behind code, but sadly most programmers either are too lazy or believe that if they need to add comments then that necessarily means their code smells. The result is that nobody knows anything about any given software project except for those who have been on the project the longest, and even they often don't know because... surprise... nobody wrote anything down! Just like with "clean code", it should be left up to teams how they want to add comments to code, and how much you comment your code shouldn't be influenced by memes from other programmers.

Don't even get me started on FrAgile. It's just a way to dupe programmers into taking on more work and doing the job of middle management for them.

Re: My 20 year career is technical debt or deprecated

#499
post #220

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

It baffles me it's the only comment pointing this out and it's not even at the top. The rest of commenters for some reason seem to equate "technical debt" with old technology and "legacy" projects.

People just like excuses to rewrite stuff with new fancy toys I guess.

We have code running for 10+ years in our CM. It's not technical debt. It's well tested asset that continually produces value without much problems or maintenance, coz most of them were already rooted out.

Sure if it was 10 years old blob in language nobody writes in in company it would have been potential liability but assuming every piece of software is that because it is old is a problem.

Re: My 20 year career is technical debt or deprecated

#500
post #220

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

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

But way too many times it is used as an excuse. If you are startup, fair enough.

If you have existing consumers, it's not. Spend that extra 20% making code maintainable or not picking the quickest possible solution. Spend that extra 40% on planning and designing feature that will be in your product for next 5 years

Post reply on HN