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

571–580 of 585 posts

Re: My 20 year career is technical debt or deprecated

#571

Post by tcfhgj »

josephg wrote: post #558
wruza wrote: post #540

Earlier quoted context omitted.

You can always pass a closure.

Or pass an options object. Regardless, it’s a strictly worse api in the general case. And it’s on par with passing around an options object in the case you want to share the same options in multiple places. If the current api is either the same or worse compared to a pure function version in all cases, I’d prefer the pure function version thanks.

An Options object is a worse API, since it assumes an implicit dependency.

> If the current api is [...] the same [...] compared to a pure function version in all cases, I’d prefer the pure function version thanks.

Why?

Re: My 20 year career is technical debt or deprecated

#572

Post by mobiuscog »

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…

Many managers or higher-up business leaders do not understand the concept of maintenance, which is why it becomes 'technical debt'.

They just expect the existing thing to keep working in the background and more imporantly do the new stuff that is wanted.

It's generally a debt, because engineers are not given time to maintain it properly. Imagine the car never getting to go to a garage to be serviced, because it's needed for driving all the time. There is your debt.

Re: My 20 year career is technical debt or deprecated

#573

Post by tcfhgj »

ravenstine wrote: post #560
tcfhgj wrote: post #541

Earlier quoted context omitted.

If you only write comments about intention, your code seems self descriptive, doesn't it? Why don't you write comments describing what the code does? > and even they often don't know because... surprise... nobody wrote anything down! Well, read the code

> If you only write comments about intention, your code seems self descriptive, doesn't it? And who mentioned writing comments only about intention? > Why don't you write comments describing what the code does? Yes, why don't we? > Well, read the code Because code is never long and vague, and human language can never sum up complex ideas or code?

You wrote:

> It wouldn't kill us to just write some documenting comments detailing the intention behind code

Intention behind the code != Describe the code

> Because code is never long and vague, and human language can never sum up complex ideas or code?

No, code isn't vague, and hood code mostly it isn't long.

Variable names are human language btw. A programming language is a human language.

Re: My 20 year career is technical debt or deprecated

#574

Post by ravenstine »

tcfhgj wrote: post #573
ravenstine wrote: post #560

Earlier quoted context omitted.

> If you only write comments about intention, your code seems self descriptive, doesn't it? And who mentioned writing comments only about intention? > Why don't you write comments describing what the code does? Yes, why don't we? > Well, read the code Because code is never long and vague, and human language can never sum up complex ideas or code?

You wrote: > It wouldn't kill us to just write some documenting comments detailing the intention behind code Intention behind the code != Describe the code > Because code is never long and vague, and human language can never sum up complex ideas or code? No, code isn't vague, and hood code mostly it isn't long. Variable names are human language btw. A programming language is a human language.

> Intention behind the code != Describe the code

Where are you getting this exclusivity from? Given your use of an equality operator, maybe you're thinking in code a bit too much.

> No, code isn't vague, and [good] code mostly it isn't long.

This isn't even remotely true. There are many dimensions to code that a human might subjectively use to determine whether code is "good." Code that is "clean" can often be a performance nightmare, but code that someone subjectively claims to be "unreadable" can be more performant, more fault resistant, future proof, and so forth. In the context of human interpretation, code can be vague regardless of how "good" that code seems to someone.

Also, the mere fact that anyone can disagree with you that good code "mostly" isn't long discredits the very idea in an objective sense. Plenty of programmers don't care whether code is "long" if it's written procedurally and/or with pure functions. If you haven't heard such opinions before, then you need to meet more programmers of varying disciplines.

> Variable names are human language btw. A programming language is a human language.

A programming language is for the benefit of both the human and the machine, though it's still mostly to the benefit of the machine. If it were solely a human language, then it would be closer if not identical to a language like English. And, if it were, it would be tremendously slow relative to traditional programming languages, and even generate more waste heat.

Re: My 20 year career is technical debt or deprecated

#575

Post by berkeshire »

The idea of leaving behind a lasting legacy of work is vanity squared. The ones who do selfless work for open-source do not necessarily do it for a place in history. The point of choosing a purely materialistic software career was to have the ego humbling of watching one's work get decimated or trivialized in due course.

Re: My 20 year career is technical debt or deprecated

#576

Post by za3faran »

dtech wrote: post #352
za3faran wrote: post #280

Earlier quoted context omitted.

Java's records are immutable.

Also still extremely hard to use due to basic they are, e.g. there is no "with"-er method or syntax yet to modify existing values.

Withers syntax is being evaluated/designed as far as I'm aware. You can still get some good work done with records in the meantime.

Re: My 20 year career is technical debt or deprecated

#577

Post by josephg »

tcfhgj wrote: post #571
josephg wrote: post #558

Earlier quoted context omitted.

Or pass an options object. Regardless, it’s a strictly worse api in the general case. And it’s on par with passing around an options object in the case you want to share the same options in multiple places. If the current api is either the same or worse compared to a pure function version in all cases, I’d prefer the pure function version thanks.

An Options object is a worse API, since it assumes an implicit dependency. > If the current api is [...] the same [...] compared to a pure function version in all cases, I’d prefer the pure function version thanks. Why?

> An Options object is a worse API, since it assumes an implicit dependency.

No, it would be an explicit dependency.

    // definition:
    function decodeText(input, [format | options])

    // use:
    decodeText(someBuffer, 'utf8')

    // or:
    const opts = {encoding: 'utf8', fatal: true, ignoreBOM: false}
    decodeText(someBuffer, opts)
    decodeText(somethingElse, opts)
> Why?

Because a pure function is idiomatic, concise and clear. Its easier to use, easier to document and easier to understand. The only benefit of a class is that it encapsulates its state behind an interface. That makes sense for a BTree or a database. But TextDecoder has no mutable state. It has no state at all except for its passed-in configuration.

Decoding text is a verb not a noun. In programming, verbs are translated to functions, not classes. You don't have an "adder object" to add things. You don't have to instantiate a JSON stringifier before calling JSON.stringify. If thats not obvious, you may have spent too long in OO languages.

Re: My 20 year career is technical debt or deprecated

#578

Post by PaulHoule »

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 had a job coding Java applets for higher ed when Java was still in beta.

A Java applet could be small and fast loading but that required careful scoping, design, and coding. In JDK 1.0 you didn’t have JAR files and no serialization built in the platform. I wrote a program that would let you edit finite element meshes and submit to a FORTRAN code running as a CGI and the serdes code was about as large as the rest of the program.

Re: My 20 year career is technical debt or deprecated

#579

Post by klibertp »

ravenstine wrote: post #574
tcfhgj wrote: post #573

Earlier quoted context omitted.

You wrote: > It wouldn't kill us to just write some documenting comments detailing the intention behind code Intention behind the code != Describe the code > Because code is never long and vague, and human language can never sum up complex ideas or code? No, code isn't vague, and hood code mostly it isn't long. Variable names are human language btw. A programming language is a human language.

> Intention behind the code != Describe the code Where are you getting this exclusivity from? Given your use of an equality operator, maybe you're thinking in code a bit too much. > No, code isn't vague, and [good] code mostly it isn't long. This isn't even remotely true. There are many dimensions to code that a human might subjectively use to determine whether code is "good." Code that is "clean" can often be a perf…

Mostly agree: the biggest factor in determining "readability" is simply familiarity of the reader with the particular syntax or style of programming. Learning many different languages allowed me to experience the evolution of code from "how do I even read this" to "well, it's clear and obvious what's going on" - without it changing one bit in the meantime. There's nothing you couldn't learn with enough effort, and the differences between learning time needed to get to mastery are in my experience small, save for a few outliers (IME: J, Forth)

At the same time I believe that there are a few objective metrics that seem to correlate with long term maintainability of a codebase. For example, the more contextual, relevant, and correct(!) information it contains, the easier it is to work with the code, especially once the original authors depart (and they will, sooner or later). Capturing that information and putting it in the code - in whatever way, including comments, diagrams (ascii art and graphical), particular tests and doctests, explicit pre and postconditions, other assertions, log calls - lowers the effort needed to maintain said code.

If the additional information threatens to obscure the the view on what's actually happening, you can refactor it the same way you'd refactor code. If you can introduce helper functions to kick details out of the way, you can also add footnotes and links to files with additional docs to get the level of detail manageable in the most often read code, while still providing enough information about that code.

What do you think? I came to this conclusion based on my experience with learning a very diverse set of programming styles and languages, experience with maintaining long-lived projects at work, and the "Programmer's Brain" book. The book has its moments, though for the most part it's just boring, but it did provide me with a few puzzle pieces I needed to make some sense out of the whole thing.

Re: My 20 year career is technical debt or deprecated

#580

Post by damethos »

putnambr wrote: post #454
gregmac wrote: post #413

Earlier quoted context omitted.

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

> WidgetService can either import `ItemClient` or roll its own

Can you clarify what is ItemClient in your context?

Post reply on HN