Hacker News Reader

Comment by nomel | Hacker News Reader

Code was malleable only to a developer with great code comprehension. In my experience, this was actually very rare. I think part of the reason is, you don't get any recognition for modifying a few lines of someone else's code compared to "I created this new library/app to solve this problem for our org!".

View on HN

> Code was malleable only to a developer with great code comprehension

This used to be what being a dev was, if I recall. It's been a few years.

Sure, but it was certainly a difference between those projects you authored and those you inherited, at least in time-to-productiveness.

The ability to understand and maintain inherited projects is more valuable than the ability to create new greenfield projects.

And often, it's not the code that is the issue. You understand the code perfectly fine and can edit it easily. The main issue is always finding out the "why" so you do not remove any Chesterton's fence while coding for a new change request.

In terms of value as an income, then for a consultant this is most likely true - for staff working in a megacorp not so much.

Thats very true, calling coding craftmansship or considering oneself an amazing coder but only for new projects is obviously wrong.

A great coder loves legacy old projects because theyre challenging, unpredictable, undocumented, and if you figure out, you are like a God.

Starting the perfect greenfield project and writing amazing code the first week is a skill every freshmen student at a CS college has. That's not a problem area, its a solved thing.

But do it for 10 years straight after 5 acquisitions, different infrastructure, different industry, language, culture? You are a RARE BREED.

Or even simpler put, never measure yourself with easy things, only with the hard ones since then the easy things are a joke.

> But do it for 10 years straight after 5 acquisitions, different infrastructure, different industry, language, culture? You are a RARE BREED.

Been there done that, the problem is you will not get rewarded by your superiors. Keeping old shit alive is useful to keep your skills sharp, but it's bad in a culture utterly dominated by "resume driven development".

There certainly is, but in my recollection, devs could tackle either. Again, it's been a while.

I think we romanticise the old days of coding now that agents are doing it.

Regarding the average developer as an imbecile was a cottage industry from Djikstra to FizzBuzz.

I romanticized even before, because there is a reason why society's view of developers shifted from geek losers to rich in the past 15 years. I remember when 15 years ago a girl told me that I'm different, because I'm not as looser as how she imagined developers.

Well, geeks certainly know how to turn their kind into losers (again).

Exactly, as I recall pre-AI days, 90% of the code was more of a slop of whatever AI writes nowadays

And non-slop parts were maybe some prominent open source projects.

Most bigtech company had an internal joke of "we couldn't ever open source X, not because it can't be done, but it would be too embarrassing"

Most devs never understood the code. I worked with 1000s, most wrote code and delivered some stuff maybe, but never understood anything.

Did the delivery work functionally as expected? If yes, then they understood what they need to understand to do that work on code. You don't need to understand the whole codebase, just the parts relevant to the work at hand.

Ive worked and work with people who I dont consider super talented but sure as hell they understand the code, maybe just some lines, maybe the method, maybe the class, maybe the module and further.

Unless you worked at the shittiest company in the world, lets try to not bring others down just because they weren't as amazing as we are. They might have other skills weve lacked.

E.g. like a journalist complaining that they colleagues didn't publish books... who cares? Thats not their job, they need to write clear good concluded articles. If they write their articles like books, nobody reads that shit.

Then blame the (worst) workmen, not the medium.

I wrote complete systems that run businesses today. I understood every single line of code.

I'm not sure your experience is the norm.

I'm really glad that wasn't my career experience. I worked with a lot of extremely sharp devs in a variety of places. Dull ones were simply not hired.

Many people here are saying "code was always malleable", "code was always clay". But how many actually do their work in live interactive REPLs, which I'd say is the truer analogy?

LiveCoding in CommonLisp.

https://www.youtube.com/watch?v=xzTH_ZqaFKI

https://news.ycombinator.com/item?id=50205569

Err. Along with FP, bottom-up design, and meta programming..

I disagree. Code can be/was more malleable if it's designed well, especially with pure FP. People kept on moving away from messy abstractions and OOP and more towards this idea of pure functions and composition, creating more robust and malleable software.

Now instead of aiming for robust, malleable code, people are throwing up their hands and saying, "It was always a mess, let's just keep throwing more tokens at it."

Yeah, people said "I'll use javascript and python because it'll help my velocity to forget about types" and then went back and reinvented types and functional programming in both. And now they're so confounded by the pile of confusion that they're yielding to LLMs.

If a dev just followed public trends, then I guess I can see how they came to the conclusion that this is the best way out, because their baseline level of comprehension is so far in the floor. It's like circling around the entrance of a maze for days until finally an AI merchant shows up near the door, and they say "well clearly, the only way to get out of this maze is to pay the merchant for his fancy roomba to carry me out" instead of carefully mapping your way through.

From a selfish perspective, that's fine by me. I've built up skills that I don't think will be replaced in the near-term, and in that same period most people will end up de-skilling. The only downside is that I've had to shrink my circle that I collaborate with even further.

How do you do business logic with less OOP? I find FP to be a mess for that

In what kind of applications do you mean business logic?

This is a one possible approach/explanation:

https://pragprog.com/titles/swdddf/domain-modeling-made-func...

People with poor comprehension have been changing code for years, and in great numbers. Doesn't mean it goes well, mind you.

Not just comprehension, but authority.

We tend to forget in tech-oriented forums that most of us are bound to those who pay our salaries, and for many developers that payment is to be focused on revenue-generating, or client-focused work.

Developing advanced comprehension and being able to use it for long-term system stability are unfortunately not always paired in the daily work.

The big trick always was to limit your scope. If you can't do that or if your tooling doesn't help you with that then very quickly you will run into the limits of what you can still keep in your head.

That sounds a bit extreme, to me, I think code was always malleable simply from good experienced devs. The "developer with great code comprehension" just did it better I guess but it wasn't a skill shared only by the holy Coder chosen by Destiny or something.

Also comprehension is one side, its "Consuming" code, but it doesnt say anything about theyre talent of producing great code.

The problem has always been that code is malleable for all including those that think that have great code comprehension but actually don't.

Revisionist history overrating how hard it was to modify code.

Reply on news.ycombinator.com