Live data from Hacker News

My 20 year career is technical debt or deprecated

blog.visionarycto.com

411–420 of 585 posts

Re: My 20 year career is technical debt or deprecated

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

I have been explaining to folks how OpenAPI is basically WSDL-lite. And is building up to be as big, at their current velocity. Kubernetes and friends, it is hard not to see as non JVM Glassfish servers. I remember WAR files being far easier to reason about than the current bundle setups we have today. SAR files were an amusing stab at the same thing, complete with the server managing deployment/startup order.

I still don't want to go back to that time, mind you. Is probably why I'm so hesitant on the current attempts.

Re: My 20 year career is technical debt or deprecated

#412

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

> Anyone who writes class names like FactoryBuilderFactoryImpl and claims to walk in the light is at best a scoundrel, and at worst a follower of a religion so dark we don't name it in polite company.

I have to say I already expected the comments to be good when I read the title but this nugget of pure gold - I would PAY to read comments like this!

Re: My 20 year career is technical debt or deprecated

#413

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

> If you're working on a part of the code base you should just have to change classes in one single folder. A new feature should just be a new folder. That change alone speeds up teams by huge factors.

This is a neat idea. Have you done this in practice, and how does it work over a long time frame?

One of the big advantages of separate packages is purely for references: The model package has no reference to service or database code, so it's not possible to include SQL or other hidden service calls in it -- at least not without adding a new dependency which makes it blatantly obvious you're doing something wrong.

On the other hand, if your features are self-contained, and you have good unit test coverage of all the logic, then I guess it doesn't really matter as much what the structure is. The fact it's unit tested forces it to be loosely coupled, and testability is one of the main reasons to organize code into layers in the first place.

Re: My 20 year career is technical debt or deprecated

#414

I think it's normal. Some systems I've built were quite sticky in the sense that they started as prototypes to be scrapped once we figure out the "real" system architecture, and 8 years later they're still in use and integrated into dozens of business processes, so hard to replace. In general, looking back at old code I wrote it seems my solutions were better when I was more naive / less experienced, as I would often…

I think most of us go through that journey.

Can be hard to decouple overengineered messes from Good Software: an idiot admires complexity, et cetera.

Re: My 20 year career is technical debt or deprecated

#415

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

> I want to link it to whoever insisted on adding a useless TextDecoder class in javascript that you have to instantiate, instead of just calling textDecode(…, “utf8”) using a global function like the rest of the standard library. I for one would rather punch the person who proposes such a global function as the only mechanism for conversion, because charset conversion is a reasonable thing to do on chunked partial i…

You can have the global function and make it work on "chunked partial inputs" while maintaining the state between calls (that state can be hidden in a closure or made explicit as an argument or a receiver - functions in JS can be called on objects even if they were defined outside of them). The very bad example of this is C's `strtok`, but it's pretty typical for JS to encapsulate the state in a closure to get similar functionality.

Said another way: the functional, simplified interface doesn't mean you have to get simplified or lacking functionality. Haskell wouldn't exist if that was the case. The simplified interface providing as much functionality as the more complex interface is possible because the expressive power of JS is leagues above Java - porting Java patterns that emerged due to Java's shortcomings (some call them "design decisions", and they're also right) to JavaScript is simply not a good use of JS as a language.

Re: My 20 year career is technical debt or deprecated

#416

Earlier quoted context omitted.

> as I tend to over-engineer systems and constantly doubt / second-guess my technical decisions I find this as well. I also think that there is a sub-conscious fear as you become more senior that you need to justify that with more elaborate/complex solutions. In my experience there are also a lot of people in software who never come out of the other side of that view and constantly equate "complex" with "good". Being…

I don't know what this means about my personal (in-)ability but I've been developing for years (15+) and I feel like all of the other developers I have to deal with are constantly turning to weird, convoluted solutions to problems. I have also never been able to get past the first step in the google interview process so I have this deep, frustrated insecurity. And people constantly like to point out how simple my stu…

Simple is good, you have nothing to fear (as long as it's not naive/laggy).

Re: My 20 year career is technical debt or deprecated

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

nope; just checked, there are none

(and even the ones that are pretending to not be here said they don't give a shit)

Re: My 20 year career is technical debt or deprecated

#418

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

Someone has to link this here, so it may as well be me :)

https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

Re: My 20 year career is technical debt or deprecated

#419
That's a lot of fad-based tech in this article but you do what you have to do. The first language I used professionally is not the same language I use today. However any one of them certainly could have become "fad" tech... except maybe C, Lisp, and Haskell; those ones seem to be built on foundations (discovered or invented) that are repeated, rediscovered, or reinvented but rarely change.

I generally think of "fad" tech as frameworks and ecosystems that are built around a commercial interest or novel idea. They often fail to overcome network effects. And this leads them into obscurity to await deprecation.

There's a lot of churn that happens in the frothy red waters of "trying to make programming easier/faster/accessible-to-non-programmers".

And we're not so great at maintaining our legacy, the state of the art, the pedagogy and history of our science. Over a twenty-plus year career I've seen people re-invent solutions to the same problems over and over. Each time it's a revolution. You don't want to dishearten the young and eager but at the same time seeing them run into the same problems, learning the same conclusions, etc means we've not been doing a great job at teaching and mentoring and all that.

Post reply on HN