71–80 of 103 posts
Not to be that curmudgeon (who am I kidding), but it's made reviewing code very much less enjoyable, and I review more changes than I write. Engineers merrily sending fixes they barely understand (or, worse, don't think they need to understand) for the rest of us to handle, and somehow lines-of-code has become a positive metric again. How convenient!
Earlier quoted context omitted.
I think you just have to give up ownership of the _code_ and focus on ownership of the _product_.
I don't care about the product as much as I care about the code.
Tim Bryce, one of the foremost experts on software methodology, hated programmers and considered them deeply sad individuals who had to compensate for their mediocre intelligence and narrow thinking by gatekeeping technology and holding the rest of the company hostage to them. And, he said upper management in corporate America agreed with him.
If you place a lot of value in being a good programmer, then to the real movers and shakers in society you are at best a tool they can use to get even richer. A tool that will soon be replaced by a machine. The time has come for programmers to level up their soft skills and social standing, and focus their intelligence on the business rather than the code. It sucks but that's the reality of the AI era.
These kind of pain points usually indicated too much of or a wrong architecture. Being able to fee these kind of things when the clanker does the work is a thing we must think about.
Earlier quoted context omitted.
How much of "good engineering practices" exist because we're trying to make it easy for humans to work with the code? Pick your favorite GoF design pattern. Is that they best way to do it for the computer or the best way to do it for the developer? I'm just making this up now, maybe it's not the greatest example; but, let's consider the "visitor" pattern. There's some framework that does a big loop and calls the visi…
LLMs have limited working memory, like humans, and most of the practices that increase human programming effectiveness increase LLM effectiveness too. In fact more so, because LLMs are goldfish that retain no mental model between runs, so the docs had better be good, abstractions tight, and coding practices consistent such that code makes sense locally and globally.
Why is this name bad? Because an llm will get confused by it and di the wrong thing half the time.
Not to be that curmudgeon (who am I kidding), but it's made reviewing code very much less enjoyable, and I review more changes than I write. Engineers merrily sending fixes they barely understand (or, worse, don't think they need to understand) for the rest of us to handle, and somehow lines-of-code has become a positive metric again. How convenient!
It has always been my opinion (and born out by our statistics internally, when counting self-review in the form of manual testing and automated test writing) that reviewing code (to the level of catching defects) often takes more time than actually building the solution. So I have a pretty big concern that the majority of AI code generation ends up adding time to tasks than it saves because it's optimizing the cheap…
Earlier quoted context omitted.
It has always been my opinion (and born out by our statistics internally, when counting self-review in the form of manual testing and automated test writing) that reviewing code (to the level of catching defects) often takes more time than actually building the solution. So I have a pretty big concern that the majority of AI code generation ends up adding time to tasks than it saves because it's optimizing the cheap…
as much as you or i may be against it, inevitably AI coding will move away from human review and toward more automated means measuring program correctness this was already happening even before AI - human review is limited, linting is limited, type checking is limited, automated testing is limited if all of these things were perfect at catching errors then we would not need tracing and observability of production sys…
Coding with AI is for those kids who were supposed to “stop playing games and clean their room right this minute”, but instead they shove all the crap in their closet and go back to playing games.
Not to be that curmudgeon (who am I kidding), but it's made reviewing code very much less enjoyable, and I review more changes than I write. Engineers merrily sending fixes they barely understand (or, worse, don't think they need to understand) for the rest of us to handle, and somehow lines-of-code has become a positive metric again. How convenient!
It has always been my opinion (and born out by our statistics internally, when counting self-review in the form of manual testing and automated test writing) that reviewing code (to the level of catching defects) often takes more time than actually building the solution. So I have a pretty big concern that the majority of AI code generation ends up adding time to tasks than it saves because it's optimizing the cheap…
I suppose, in exactly the same way instant / frozen food makes cooking more enjoyable. If it was just a chore that you had to do, and now it's faster, sure, grab that cup-o-noodles. Knock yourself out. Just don't expect to run a successful restaurant based on it.