Not sure if I read this the same way you did. At least, this didn't read at all to me as "talking shit," but rather sharing their professional opinion on the (un)likely success of the project. Keeping thoughts to yourself isn't professional, it's avoidant. Especially when it has the chance to directly affect you.
Zero technical debt certainly is... ambitious. Sure, if we knew _what_ to build the first time around this would be possible. From my experience, the majority of technical debt is sourced from product requirement changes coupled with tight deadlines. I think even the most ardent follower of Tiger Style is going to find this nigh impossible.
I would even say that from a project management perspective, zero technical debt is undesirable. It means you have invested resources into perfecting something that, almost by definition, could have waited a while, instead of improving some more important metric such as user experience. (I do understand tech debt makes it harder to work with the codebase, impacting all metrics, I just don’t think zero tech debt is a good target.)
> perfecting something that, almost by definition, could have waited a while
No technical debt is not the same thing as “perfection”. Good enough doesn’t mean perfect.
Would it be ok to submit an essay with only 90% of the underlined spelling mistakes fixed? Do you paint your outdoor table but leave the underside for later?
Do it once, do it right. That doesn’t mean perfect, it means not cutting corners.
There are contexts where quick and dirty and (hopefully) come back later are warranted. Far more often it is just an excuse for shoddy work. You used the word “perfection” as the contrast to “technical debt”. Granted, technical debt is not a well defined term, but I am simply highlighting that “free from technical debt” in no way implies anything like perfect. It just implies well made.
Technical debt is not a current defect. It just means that for the sake of having something quickly done today, you accept that the cost of changing stuff tomorrow will be greater than normal. If you never have to change something (switching jobs, consultancy project you don’t care about,…) then it may be a great trade off.
Ironically, some of the worst tech debt I’ve ever dealt with has been because the initial implementation was an overengineered disaster by an dev who thought they were solving all possible problems before we really understood what all possible problems are.
“Zero tech debt” is an impossibility. The most elegant solutions incur some kind of tech debt, it’s just less than others. More realistic than “zero tech debt” is a continuing dedication to addressing tech debt combined with using implementations that minimize “one way doors”.
I think the difference here is that Penn and Teller are just as much historians of magic as they are magicians themselves. Accepting the honor is also accepting that the history is still relevant and worth celebrating. Making this into an ego thing misses the point a bit, I think.
My rule with Cursor is that unless I know exactly what I want it to do, I have it stay out of my way. If I have a general idea, I may turn on auto-complete. I reserve the agent for things like tests, UX, and rote programming that saves me time.
When I do use the agent, I inspect its output ruthlessly. The idea that pages of code can be written before being inspected is horrifying to me.
This game's dictionary is similar to Scrabble; it includes as many valid words as possible, even when they are obscure. It turns out that "asse" is a kind of fox:
It's a sticky wicket with these obscure words. I've made other word games before, and people get upset when oddball-but-valid words are rejected. It feels more fair to be permissive, but that's just me.
It's rather telling that you group substance abuse together with rather common and generally benign human conditions such as anxiety and neuroticism, and I find that your rather heavy-handed generalizations of people's capacity to help others based on their conditions and indeed their trauma dilutes your point.
It's as if you wish us to say, "I've figured everything out, let me show you the way." I don't find that particularly reassuring, and it's not exactly the kind of humility that I think you want to convey.
If your bar to helping others is ending all suffering within yourself, then I'm afraid we're all going to be living a very lonely existence if we followed your lead.
Now, I think your larger point is that folks in crisis should tend to that crisis, which I think anyone who has taken a plane ride would understand. Apply the mask on yourself first. But to extend that analogy, you can have a broken hand, or even a broken heart and still be able to help your neighbor.
You are right that he is making some heavy-handed generalizations, but then again, he is replying to the OP making a very populist generalization about people with wealth as well, as if he has figured everything out - and OP isn't getting any flack for that. It may be the difference between American culture / "the new rich" vs. European culture, but my experience with people with great material wealth is very different and not easily generalizable.
> If your bar to helping others is ending all suffering within yourself, then I'm afraid we're all going to be living a very lonely existence if we followed your lead.
Logically that does not make any sense. If everyone is able to relieve themselves of their own suffering (no one else can anyway, in an ultimate sense), which includes loneliness, then there would be no more suffering. This is a Buddhist mindset that seems kind of harsh at first, but it's a reality people benefit from once they accept it: you must become your own savior. And once you are in good place, even just mentally, it becomes very natural and easy to help out others.
Problems only start when people reject this idea, and think they have all the answers to all the problems, and start enforcing their beliefs on others using violence - which is a trend we're seeing more & more these days.
> but my experience with people with great material wealth is very different and not easily generalizable.
Same here, just FYI. There's a reason that I couched it in terms of "I have seen..."
I know multimillionaire high-school dropouts, and dirt-poor people with multiple advanced degrees from Ivy-league universities.
But the community of which I'm a member, stresses the importance of getting our own house in order, before looking to others, so people with means can do a lot of good (or harm).
Ah yes the Jordan Peterson movement. A very individualistic take on life. It's also hypercritical in that an opinion doesn't matter unless you are already in order. Who defines order and out of order though? Well he does.. or really only one thing could. Wealth. People forget that you can be part of a community and find yourself without it being a cult.
Who? Not familiar with that... looks it up ... Oh. No. Not that. Actually, about as far from that, as you can get.
Cult, schmult. Been called worse. Whatever creams your Twinkie. Our Fellowship basically has nothing to do with wealth, personal philosophy, or social standing. It's about helping each other out of some bad situations, and it's fairly common to have people from all walks of life, rubbing shoulders.
> Either way you are going to throw it all away once you have settled on what should be the final iteration anyhow.
I think this needs to be highlighted, because while I completely agree, I think it's often implicit, taken for granted, and neglected. Far, far too often I've seen code bases bloat because this never takes place. The sentiment at a lot of places seems to be, if the tests pass, ship it. Arguably, it may even be the right decision.
I find myself agreeing with much of your point, but I feel the need to nitpick a bit of your comment myself :)
I don't think your code base needs to be very large, or very legacy in order for comments to be valuable or even the best way forward. If the decision exists between a somewhat large refactor or a one-off comment to account for an edge case, I'm likely to take the latter approach every time. Refactors introduce risk, add time, and can easily introduce accidental complexity (ie: an overengineered solution). Now once that edge case becomes more common, or if you find yourself adding different permutations, yeah I agree that an incremental refactor is probably warranted.
That said, perhaps that comment could — and certainly one should at least supplement it — be replaced with a unit test, but I don't think its presence harms anything.
reply