Live data from Hacker News

My 20 year career is technical debt or deprecated

blog.visionarycto.com

451–460 of 585 posts

Re: My 20 year career is technical debt or deprecated

#451

Kinda a weird article to be honest. It seems less like the author is annoyed at having to learn new languages or that their language specific knowledge because less useful as time goes on, and more that they are frustrated their code doesnt live on forever. I guess I don't particularly care if my code lives on or not. I build something. It's hopefully useful for others or myself for some period of time, then its gone…

I felt the same way.

If you want to build something permanent and long-lasting, go build bridges. It does seem kind of silly to expect software to be around for a long time.

Re: My 20 year career is technical debt or deprecated

#453
From my few years in e-commerce I noticed this kind of pattern: - you(your company/employer/etc) have a problem.

- you solve said problem

- profit

- competitors catch up and hit the same problem

- 3rd party (or one of the 1st parties pivots) notices all of you have the same problem. implements solution to fix the generic version of the problem: a standard is born

- hubs appear that make it easy for your competitors to eat into your market share because they now use the 3rd party solution and are more agile.

- you can't integrate because your solution is not complying to the new "standard"

- rewrite is needed

(edit: I hate HN formatting)

Re: My 20 year career is technical debt or deprecated

#454

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…

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

Been doing this for a few years. If I have an `Item` class, it's going into its own package. Along with `ItemService` (business logic), `ItemResource` (endpoint), `ItemDao` (persistence interface), etc. If `Widget` has a dependency on `Item`, then `WidgetService can either import `ItemClient` or roll its own.

Makes it super easy to split out microservices when the monolith gets big. Just keep from injecting one Service class into another, rely on the Resource or Client instead.

Re: My 20 year career is technical debt or deprecated

#455

Earlier quoted context omitted.

I think a lot of it comes from the Spring framework. People saw those gigantic stack traces with all the crazy abstractions and huge names, and took it as the norm. It doesn’t have to be that way (see also Guice). But the Uncle Bob effect is sadly real.

Some genius ported the Spring framework to PHP (and called it Symfony) and we have to live with the BS from Java world in PHP land. Anemic models and lots of indirection. What a sad world we live in.

Isn't laravel based on symphony components?

Re: My 20 year career is technical debt or deprecated

#456
post #203

Earlier quoted context omitted.

But tbf, that happens once in a billion recipes. 99% of new recipes are forgotten, often after a week or two.

Even some of the most famous recipes can change over time. I’m sure that things like McDonald’s burgers are slightly different now. Perhaps the most enduring a chef can do is invent a new technique.

The chicken nugget and McChicken batter are different from when I worked at McDonald's as a kid. Naturally it was better back then...

Re: My 20 year career is technical debt or deprecated

#457
post #400

Earlier quoted context omitted.

> 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

When you are coding a dynamic library, and providing consistent ABI between versions is a thing, you could appreciate this.

Perhaps you may also appreciate PImpl/D_PTR etc.

Re: My 20 year career is technical debt or deprecated

#458
post #455

Earlier quoted context omitted.

Some genius ported the Spring framework to PHP (and called it Symfony) and we have to live with the BS from Java world in PHP land. Anemic models and lots of indirection. What a sad world we live in.

Isn't laravel based on symphony components?

The Java infestation is real.

Re: My 20 year career is technical debt or deprecated

#459

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…

> sourced from demonic inspiration.

Actually writing demonic technical debt on purpose in one sitting would be quite an accomplishment too.

Re: My 20 year career is technical debt or deprecated

#460
post #260

Earlier quoted context omitted.

Same here. I have PHP code in production that dates back to 2008. zero dependencies, a few quirks, it runs on PHP 7.something for now, might upgrade to 8 at some point. It’s ugly, but it gets the job done. Best thing is that front-facing HTML and JS from 10+ years ago still works flawlessly, even though the UI is certainly dated. But I guess that’s the same with HN, where the design never really changed at all and ju…

You do realize PHP 7 is EOL for quite a while now[1]? PHP 8.0 is on security updates only. You might want to upgrade sooner rather than later unless you're paying for backports. [1]: https://endoflife.date/php

Yes, thanks for the reminder.
Post reply on HN