161–170 of 178 posts
A risk with vibe coding is that it may make a good developer slightly faster, but it will make bad developers waaaay faster. Resulting in more bad code being produced. The question then is: do the bad developers improve by vibe coding, or are they stuck in a local optimum?
Earlier quoted context omitted.
Sometimes I feel like watching people dig a hole until it starts filling with groundwater. They then start bailing the water out with buckets. They're very busy doing that, so the actual digging work slowly grinds to almost zero. I stand at the edge of the pit, trying to talk to them about electrical pumps and drainage solutions and get yelled at: "I don't have time for your nonsense, can't you see I'm busy bailing w…
Yep. I feel like this every time a coworker pushes back on a code review “I’m just trying to get this to work”. Okay but this is the ninth time in a row, and now you’re building on top of all the other half-baked bits, and the confusion from every one of these layering on top of one another is forcing you to do more hacks on hacks on hacks. And then when you finally “get it to work” there will be no way to disentangl…
Or alternatively: “yeah it’s really simple, you just <dive into my madness inducing garbage pile”.
Earlier quoted context omitted.
> How does the saying go, something like “show me the incentives and I’ll show you the outcome?” I think you're trivializing this saying here. The incentives actually suggest you should raise wages of current employees more than new ones. Current ones are more valuable. Of course, the issue is time. What timeframe are we measuring the incentives at. You should pay current employees less iff either 1) time doesn't exi…
> The incentives actually suggest you should raise wages of current employees more than new ones. Current ones are more valuable. You should only do this if you have to in order to have better business outcomes. It may be better for the business to not do this, because the current employees will stay even if you don't pay them more, until they don't. So we have to find out what that point they will leave is by not pa…
> You should only do this if you have to in order to have better business outcomes.
> These are Chekhov's footguns
A "footgun" is a reference to (shorthand for) the idiom "shooting yourself in the foot." The idiom refers to a self-inflicted problem. Just as how someone may carelessly handle a gun and shoot themselves in the foot.
On the other hand, Checkhov's rifle is a foreshadowing device. There is no requirement that the owner shoots themselves or that even any harm to the protagonist is caused. The protagonist can use it to kill the antagonist, the antagonist can use it against the protagonist, and anyone can even use it as a footgun. It's just a subset or extension of the "rule" "every scene should advance the story".
But a footgun is a very different thing and I think the miscommunication may be driven by this misunderstanding.
[0] https://dictionary.cambridge.org/us/dictionary/english/shoot...
Earlier quoted context omitted.
For me it is difficult to give good code comments just when code is written. The problem is solved, the tricky parts if any are internalized. I dont mind reading code so just documenting what the code is doing does seldom bring value. The important thing is to document why the code does things in an non obvious way and unintuitive scenarios and edge cases etc. When revisiting code is the best time to add comments bec…
There is a hack for that: write the comments before and/or as you write the code. When things are still unclear, weird. Of course do a final pass on them to ensure that they are correct and useful in the end. This is one example of document as-you-go, instead of doing it after "the work" is done. I find it generally leads to better outcomes. Doing documenting only at the end is in many ways the worst way to do it.
> Because no one would write an HTTP fetching implementation covering all edge cases when we have a data fetching library in the project that already does that. > No one would implement a bunch of utility functions that we already have in a different module. > No one would change a global configuration when there’s a mechanism to do it on a module level. > No one would write a class when we’re using a functional appr…
Earlier quoted context omitted.
> The incentives actually suggest you should raise wages of current employees more than new ones. Current ones are more valuable. You should only do this if you have to in order to have better business outcomes. It may be better for the business to not do this, because the current employees will stay even if you don't pay them more, until they don't. So we have to find out what that point they will leave is by not pa…
> You should only do this if you have to in order to have better business outcomes. Correct. As I explained. > These are Chekhov's footguns I think you're confusing "Chekhov's rifle" with "footgun". A "footgun" is a reference to (shorthand for) the idiom "shooting yourself in the foot." The idiom refers to a self-inflicted problem. Just as how someone may carelessly handle a gun and shoot themselves in the foot. On t…
Implicit in the usage of the term footgun in a non-hypothetical context is that said footguns refer to actually existing issues or events. My point in mentioning Checkhov's rifle was to acknowledge this property of footguns: it’s not a matter of if but when they go off.
But seeing as how they will unless your process can eliminate them, it behooves us to apply some game theory to explain why collaborative development when footguns are involved is something between a Mexican standoff and Russian roulette: a circular firing squad.
We can’t blame the footguns at that point. That’s just the game. The only winning move is not to play.
Earlier quoted context omitted.
> You should only do this if you have to in order to have better business outcomes. Correct. As I explained. > These are Chekhov's footguns I think you're confusing "Chekhov's rifle" with "footgun". A "footgun" is a reference to (shorthand for) the idiom "shooting yourself in the foot." The idiom refers to a self-inflicted problem. Just as how someone may carelessly handle a gun and shoot themselves in the foot. On t…
I’m speaking metaphorically. I know what footguns are, though I am using my words in a literary sense, and I think you’re being more literal maybe? Implicit in the usage of the term footgun in a non-hypothetical context is that said footguns refer to actually existing issues or events. My point in mentioning Checkhov's rifle was to acknowledge this property of footguns: it’s not a matter of if but when they go off. B…
> I know what footguns are, though I am using my words in a literary sense, and I think you’re being more literal maybe?
I really don't know what you're going on about
Earlier quoted context omitted.
I’m speaking metaphorically. I know what footguns are, though I am using my words in a literary sense, and I think you’re being more literal maybe? Implicit in the usage of the term footgun in a non-hypothetical context is that said footguns refer to actually existing issues or events. My point in mentioning Checkhov's rifle was to acknowledge this property of footguns: it’s not a matter of if but when they go off. B…
> I know what footguns are, though I am using my words in a literary sense, and I think you’re being more literal maybe? This makes no sense to me. They are just different things... and do you think I'm talking about a literal gun? What about a footgun is literal lol I really don't know what you're going on about
I feel that we agree, as I originally stated in my first reply, so I apologize if you feel that I’ve wasted your time.
My goal was to explain why I think that people leave jobs for higher pay instead of fixing things and getting promoted internally, which I believe was what you mentioned, which is party due to dysfunctional workplaces with footguns without proper safeguards, and in the context of this thread above you, people who have the context may have left the company, temporarily or otherwise, and those who remain to do the work may use LLMs to compensate.
[0]> (of language) associated with literary works or other formal writing; having a marked style intended to create a particular emotional effect: the script was too literary.
- Oxford English Dictionary
Earlier quoted context omitted.
You can prevent quite a lot of these issues if you write rules for Cursor or your preferred IDE Linters can also help quite a bit. In the end, you either have your rules enforced programmatically or by a human in review. I think it’s a very different (and so far, for me, uncomfortable) way of working, but I think there can be benefits especially as tooling improves
Do those rules really work? I have added the rule to not not add comments and I still have to constantly remind the model to not add comments despite of it.
e.g. I had a lint rule enabled that the AI would always violate & have to iterate to fix, I added a lint rule to tell it not do to a certain thing, and most of the time it wrote code that passed the linter on the first try.
Earlier quoted context omitted.
You can prevent quite a lot of these issues if you write rules for Cursor or your preferred IDE Linters can also help quite a bit. In the end, you either have your rules enforced programmatically or by a human in review. I think it’s a very different (and so far, for me, uncomfortable) way of working, but I think there can be benefits especially as tooling improves
It seems like people who use AI for coding need to reinvent a lot of the same basic principles of software engineering before they gradually propagate into the mainstream agentic frameworks. Coding agents come with a lot of good behavior built in. Like "planning mode" where they create a strong picture of what's to be made before touching files. This has honestly improved my workflow at programming from wanting to ju…
A lot has to be re-done. Using an IDE like Cursor is really a skill in its own & you likely won't see a productivity boost using agents without moderate investment, and even then there are tradeoffs.
I think the real benefit comes in a few years when more engineering has been done and the tools are more polished. The way that I look at is that these tools are the worst they'll ever be.