Oh, thank god, it had been a week since we last saw a post about AI killing something. It’s subscriptions this time, all users will be vibe coding apps on their spare time.
The prolific inventor’s dilemma. But to be fair developers have been making whatever they want since the beginning. Sometimes there doesn’t have to be a ‘why?’.
0% interest to defend Big Don’t Be Evil, but success rates for most businesses, new or existing, are low. Succeeding at 10% of their ventures isn’t that bad, considering they add up to the trillions of dollars of valuation for big G.
Yes. None of this early stuff should be monetized and that Entire business model is all about monetizing something that doesn't need it.
I have hooks in Claude to auto-generate the work summary and read the last work summary on start. Now if I could only get Claude to quit/restart on its own or have it thoroughly flush its resources (even Anthropic says restarting is better), we'd be getting somewhere. I do wish there were automatic hooks that fire all the time (like a heart monitor) where I could query "if context is below 15%" do this: stop all work, write work summary, commit and push all changes, release all resources, read last work summary, continue the work.
I’m testing this as well, but I’ve no idea people are getting good results out of Claude. What a waste of money… it’s incredible. It will get stuck on everything: basic string substitution, trying to install Python dependencies in a Node project, finding usages of something it’s trying to edit, and on and on.
I’ve never been asked for coverage as a metric or target, at least not by managers. Most of the… drudge that you describe seems to come from fellow developers. These are self-inflicted wounds by the “journeyman idealists”, making us all perpetual beginners.
(That said, I do like unit tests and I think code reviews can be useful for sparing if you have a good vibe and trust in the team.)
I have seen coworkers, who are otherwise very nice people, become rather nasty when given some authority over other's code in the form of code reviews. The code review turns into "this is how I would have written it, rewrite it."
What we did before code reviews: we would get together with our fellow engineers in front of a whiteboard and knock out the structure of the code one was tasked with. We'd argue whether caching is necessary or if the framework provides it for us. We'd talk about concurrency issues and whether to use semaphores or locks…
Once the plan looked good, an engineer was trusted enough to go off and implement it.
Unit tests are fine. Before unit tests we had coworkers (QA) that did full test suites for integration, functional testing. At the more "unit level", robust param checking (with assertions, logging) happened early within the functions that could fail. (Obvious example: checking for zero in a function that might use that value to divide. Its a kind of unit test in situ.)
Of course when management uses unit tests as some kind of replacement for actual integration and functional testing they become an end unto themselves (bonus: the company is also able to lay off QA).
To my dismay, I’ve never worked in a place like the first one you’ve described. Managers have certainly been confident enough in me to just let me ship stuff I built alone, or obviously that a team built without the usual red tape. Your model is very intriguing, I’ll try to implement something similar if I’m ever again able.
It’s true that code reviewers can become feral and the smallest detail a source of contention. I’ve had otherwise good team leads completely rewrite my code after accepting a review. It’s okay, maybe it wasn’t that good. Egos hurt and get hurt.
About QA: well, companies — I hope — eventually pay the price. Apple’s image of software quality now contrasted with a company that lost the trust of power users. QA and unit tests are complementary. If anything, it’s acceptance and integration tests that hurt QA, but I’ve never seen these 2 done properly anywhere.
reply