[flagged]
AI demands more engineering discipline. Not less
171–180 of 234 posts
Re: AI demands more engineering discipline. Not less
#172What worries me personally is the dopamine hit I seem to get from watching my ideas get built in front of me. There is a big temptation to just add feature after feature without really checking what the code actually looks like. So yes, more discipline is needed.
Re: AI demands more engineering discipline. Not less
#173Earlier quoted context omitted.
I'm sure this is gated by where you work (especially by how technically savvy your manager is), but the most effective contributors at my job tend to be the ones with near-zero (or sub-zero!) net LoC. LLMs are prolific and they love to add shit. Truly capable engineers are able to achieve more business outcomes with less code / fewer moving parts.
The most effective contributors at your job remove more code than they add? That doesn't sound effective that sounds like digging ditches to fill them. Every line of code removed is a line that was previously added.
Thought experiment: if you can solve a problem with 100 lines of dependency free code, or with 10,000 lines of code that depends on hundreds of things - which is better?
There's an obvious answer of course. And that is the direction that these effective senior engineers move towards.
Re: AI demands more engineering discipline. Not less
#174It is now significantly harder to figure out who understands the systems and is using AI effectively and who doesn't know shit and is just slinging LLM copypasta around. Before 2025, the underperformers/coasters were at least relatively identifiable by the paucity of their contributions. Now all of the sudden every single engineer is filing PRs, code reviews, technical design documents, and every other artifact under…
>This is mostly due to incredible pressure from the C-level for every engineer to be using as much AI as possible I think this is an important point. Software engineers always had the right instincts on how to approach AI for coding -- cautiously. Execs got too coked up on LinkedIn puff pieces from nobodies and adver-prophesizing CEOs selling their tokens and chips that they forced something unnatural upon their orgs…
I don’t know. I mean, I agree with you overall, but it seems like tons of engineers, especially here on HN, have been more than willing to go all-in on AI for at least the past year, with many dire warnings of “coding is a solved problem,” “if you’re not programming swarms of agents, you’re going to be left behind,” and so on.
This has not been my experience with my fellow engineers IRL on average, but I do feel like there is a significant contingent of us who are ready and raring to yield engineering in its entirety to the LLMs.
Re: AI demands more engineering discipline. Not less
#175Earlier quoted context omitted.
> The most effective contributors at your job remove more code than they add? Yes. > That doesn't sound effective that sounds like digging ditches to fill them. It sounds effective to me, like removing garbage from sidewalks so people can walk straight instead of walking around the trash. > Every line of code removed is a line that was previously added. Correct. Today I cleaned up if (a || b) return true; if (c) retu…
Written exactly like that, yours is obviously cleaner. But, if that original code had comments and traceability of each condition and return to a specific domain scenario, you would be doing a disservice by collapsing it to the one flat boolean expression. In that case, it may be better in its expanded form, and you should let an optimizing compiler do the collapsing.
There were no comments.
If there were comments for each conditional, it should still be refactored as
return a || b // comment 1
|| c // comment 2
// long comment 3
// on multiple lines
|| d;
> In that case, it may be better in its expanded form, and you should let an optimizing compiler do the collapsing.
This is nonsense. This optimization is not about compiler optimization for efficiency. It's an optimization for human readability and maintainability.
Re: AI demands more engineering discipline. Not less
#176> Those are not code problems. They are evaluation problems. > Code becomes precious when it is the only place knowledge lives. Reading AI code all day is _agonizing_. Just, a horrible way to live, and it melts people's brains at the moment you need them to be the most capable. Manual programming has this really productive and gratifying feedback loop, where you read the code, write the code, and fix it until it comp…
Are there any products out there that are capturing the prompts/sessions? I imagine you could do it in an adhoc way, asking Claude to write up a summary of the session as part of the commit message. But is there anything else that's more structured/higher level?
So many. The sibling comments, plus GitAI, plus empathic, plus many others
Re: AI demands more engineering discipline. Not less
#177Earlier quoted context omitted.
Written exactly like that, yours is obviously cleaner. But, if that original code had comments and traceability of each condition and return to a specific domain scenario, you would be doing a disservice by collapsing it to the one flat boolean expression. In that case, it may be better in its expanded form, and you should let an optimizing compiler do the collapsing.
There were no comments. If there were comments for each conditional, it should still be refactored as return a || b // comment 1 || c // comment 2 // long comment 3 // on multiple lines || d; Many years ago, "lines of code" was the classic example of nonsense management metrics. Today, there are somehow HN users who argue that lines of code is indeed a good metric and ask "But what if the code had comments?" as if th…
FWIW, I'm no advocate of "lines of code", or really any KPIs at all. All I'm saying is context matters.
Such branches could make sense if the conditions have to do with underlying domain concepts, but you expect the outcomes to be revised. It could just be a moment-in-time accident that they are all returning True right now.
This kind of tension is also where you often see indirection via configuration files or other auxiliary data structures. Or in the old days, things like bit fields instead of booleans, so that merging the conditions would encode different small integers to use as lookup table indices.
Re: AI demands more engineering discipline. Not less
#178Earlier quoted context omitted.
I'm sure this is gated by where you work (especially by how technically savvy your manager is), but the most effective contributors at my job tend to be the ones with near-zero (or sub-zero!) net LoC. LLMs are prolific and they love to add shit. Truly capable engineers are able to achieve more business outcomes with less code / fewer moving parts.
if you're trying to use sloc as a proxy for productivity in any way, shape or form you've already lost the game. i tend to find that the most productive teams make better decisions and work fewer hours. the quality of decisions is such a huge force multiplier that it renders actual hours worked almost an irrelevant variable.
> if you're trying to use sloc as a proxy for productivity in any way, shape or form you've already lost the game.
in fact, i've sent over 20 variable rename prs and am now topping the leaderboard!
Re: AI demands more engineering discipline. Not less
#179Earlier quoted context omitted.
Turning inefficient, unreadable code into efficient, readable code often results in an overall reduction in LoC. High-quality code and high-volume code are highly anti-correlated. Incidentally, low-quality code that is excessively long just so happens to be common complaint with AI-generated code.
Rewriting code to be more compact is orthogonal to productivity.
[deleted]
Re: AI demands more engineering discipline. Not less
#180Earlier quoted context omitted.
> Because they were added doesn't mean they were needed and even if the same person added and then removed them, it doesn't mean they are digging ditches to fill them. Huh? If LoC weren't needed then adding them was unnecessary and a waste of time. Someone who is known at an organization for removing unnecessary code screams inefficiency to me. It's paying one person to create a mess then another to clean it up.
> Huh? If they weren't needed then adding them was unnecessary and a waste of time. My previous reply already addressed this? I can't help but think you are being purposefully obtuse if you can't acknowledge the concept of developers creating known (and hopefully temporary) technical debt due to various forms of deadline related time pressure or changing requirements.
Old guard status games be like