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

501–510 of 585 posts

Re: My 20 year career is technical debt or deprecated

#501

Post by ilyt »

P_I_Staker wrote: post #389
ilyt wrote: 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…

I don't understand the need for obscenities. Their are children on this blog.

Not using obscenities when fitting is reducing the depth of expression. Some things are done suboptimally, some are done badly, and some are utterly fucked.

And replacing obscenities with silly words is just that, silly

> Their are children on this blog.

Putting children on tech blogs is abuse, they might learn something terrible like JS by accident, that's worse than any bad word they could find

Re: My 20 year career is technical debt or deprecated

#502

Post by vikramkr »

TacticalCoder wrote: post #153

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

I'm not sure why hating Java means I'm supposed to hate things written in Java, or where the irony is there

Re: My 20 year career is technical debt or deprecated

#503

Post by ilyt »

abraxas wrote: post #284
ilyt wrote: post #216

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. The IDE that's written in Java most likely shares nothing with Java ecosystem parts they "hate" (I'm guessing all of the EJB, applets an general 90's Java enterprise stuff). Only irony here is you thinking it is. The 90's Java was a thing to hate. Running fat complex app server…

Ironically, deployment, management, monitoring and security of a single (even clustered) EJB app server was a much more straightforward affair that today's cloud based Rube Goldberg machines that I encouter in practically every "modern" enterprise app.

Seriously, I work in ops with a side of coding and in order of "most pleasant" to "most annoying":

- Go and similar "one binary". Bonus points if static files are also embedded

- "Just a JAR with few parameters"

- Anything that comes pre-packaged in OS. Perl with OS-provided libs.

- Enterprise Java with code-as-xml for config. More pleasant if we're not the ones managing the XMLS

- C/C++ apps with reasonable deps that don't need re-compiling half of OS

- Bare containers. Shit visibility without a lot of tooling but at least we don't have fight deps

- k8s. Complexity of system rarely pays off with the relatively simple apps our devs are deploying and need even more tooling for good visibility

- Ruby outside of container - just fucking kill me. A bunch of requirements for libs in system just to compile "gems" (why those cunts can't call it libs like everyone else), long startup, leaks memory, took them 10+ years to make a web server that's not completely shit...

- Python - if I see something is in Python I try to find alternative solutions. I swear half of the install instructions either just don't work or shit all over home/system dirs. The absolute clusterfuck of py2-3 migration didn't help either, thankfully it appears its finally over. Bonus demerit if instructions mention setup.py. Tho to be fair I didn't tried recently, maybe it is better

Re: My 20 year career is technical debt or deprecated

#504

Post by ilyt »

osigurdson wrote: post #356
ilyt wrote: post #216

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. The IDE that's written in Java most likely shares nothing with Java ecosystem parts they "hate" (I'm guessing all of the EJB, applets an general 90's Java enterprise stuff). Only irony here is you thinking it is. The 90's Java was a thing to hate. Running fat complex app server…

>> bunch of code-as-XML for configuration Code as json or yaml is fundamentally the same while being nicer to look at (yaml at least).

It's in a way more terrible as it usually is templating language + YAML

So you need to navigate pitfalls of YAML (or bear ugliness of JSON) all while learning a templating language.

All because someone decided "Users will not want to learn Python for DSL, let's give them YAML"...

Every single tool that went that route has that problem and every single one would be better served just picking (Lua is nice and embeddable, just saying) and using it as DSL.

Re: My 20 year career is technical debt or deprecated

#505

Post by cesarb »

senko wrote: post #495
Jorengarenar wrote: post #490

Earlier quoted context omitted.

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.

Perl 6 did get released, with that name, after years stuck in development (source: https://developers.slashdot.org/story/15/12/26/0354235/perl-...). Only later was it rebranded.

Re: My 20 year career is technical debt or deprecated

#506

Post by stodor89 »

TacticalCoder wrote: post #153

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

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

I did. Getting people to install JRE didn't really seem that hard of a problem, and neither did sandboxing.

Around the same time Rockstar Games released GTA 3 with its third-person camera, and I thought this is the worst idea ever. 20 years and 400 million sales later, I still hate it.

Re: My 20 year career is technical debt or deprecated

#507

Post by josephg »

Izkata wrote: post #400
raverbashing wrote: post #329

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…

> 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

This always strikes me as any-benefit mentality thinking. I agree there is some small marginal benefit to this pattern, but the cost (in time, decreased readability and lines of code) is massive. The benefit of being able to change your getters and setters later in a public interface almost never actually shows up.

Most getters and setters aren’t even part of a public interface anyway - because either they’re private or they’re in application code. In both of these cases, you can delay replacing a public class field with public getters and setters until you actually need to. When it actually provides value, it’ll take all of 5 minutes to do the refactor. Intellij can probably do it instantly. And, Spoilers: this will almost never come up in practice. Public fields are almost always fine.

Re: My 20 year career is technical debt or deprecated

#508

Post by Jorengarenar »

koheripbal wrote: post #338
ilyt wrote: 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…

Well, a more accurate comparison would be if you made a chair 20 years ago, and now no one makes chairs anymore because we have all become robots.

If everybody became a robot and there's no need for chairs, then to whom is the technical debt supposed to be paid?

If there are still fleshbags who need chair, the one created 20 years ago, if properly cared for, works just fine.

Now, if I used a piece of rotten wood for one leg, because I couldn't bet bothered to go fetch a new plank, this is debt that will need to be paid in the form of putting additional work to fix said leg later.

Re: My 20 year career is technical debt or deprecated

#509

Post by P_I_Staker »

veidr wrote: post #417
P_I_Staker wrote: post #389

Earlier quoted context omitted.

I don't understand the need for obscenities. Their are children on this blog.

nope; just checked, there are none (and even the ones that are pretending to not be here said they don't give a shit)

There you go again with your potty moth. I insure you there was a sweary in your OP.

Re: My 20 year career is technical debt or deprecated

#510

Post by josephg »

stcroixx wrote: post #442
klibertp wrote: post #281

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…

Don’t bother. Your preferred style will go out of fashion just like the previous ones all have. Chasing this is low value busy work.

The enterprise java programming style is worth avoiding because it’s a productivity killer. This style obscures your business logic, it makes debugging harder through needless indirection, and it creates pointless busywork from the need to write, maintain and document reams of unnecessary boilerplate.

Foundationdb has official bindings in C, Python, go, Ruby and Java. The real bindings are in C, and all other languages’ bindings are well written, idiomatic wrappers around the same C library exposing the same functionality. The Java bindings need over twice as many lines of code as the Ruby and Python bindings to achieve the same thing.

Even if this style of Java is only 10% less productive than that of idiomatic Kotlin, Go or Python, you will probably break even on the investment of migrating languages after mere months. I think that undersells it. The productivity difference is probably much higher. Especially for large projects.

Improving your personal and teams long term productivity is just about the highest value work you can do.

Post reply on HN