Marketers ship code, salespeople answer technical questions without backup...
...and you dentist cuts you hair and your hairdresser pulls your teeth. Because everything is a trade what can and should be learned, except if it's related to writing and selling software.
To be fair, you did not say that marketers ship working and maintainable code, salespeople answer technical questions without backup the correct way. Therefore you might be right, thought.
Is this not the guy who is on the payroll of Anthropic? Not because he is wrong, but because there is so much marketing going on in this space nowadays.
Version A: find 100 LOC which can be reduced to 50 LOC without changing the functionality. Then ask the author to go through the PR making sure it's not bloated. Repeat.
Version B: find hidden bugs. Ask the author to fix them. Repeat.
Keep them occupied saving your face. I would also fine tune an own agent to automatise this kind of work for me.
> They bought Komoot, laid off 80% of the staff, but they still did a major redesign
This sounds like "doing a major redesign" would be something positive. I'm a paying customer since ages and use the app on daily basis. The new design adds nothing except confusion, at the same time they broke the app on my smartwatch. I'm pretty much thinking about switching apps because I don't see myself buying a new watch just because of this.
Some companies would be better off with less bored designers. This is exactly the same situation like a couple of years ago, when Spotify every week rearranged the GUI and every week I had to relearn how I can reach the same functionality. Back then I had to use the App Store to give feedback, but I see now I can do the same directly in the Komoot app. They're gonna have something to laugh about...
Bending Spoons has own teams taking care of the acquired companies. I read about it here a while ago. I am pretty sure the re-design was done by one of those teams. It's pretty close to the new design of MeetUp. I am talking about those ppl.
> Am I the only one who feels like this is obviated by Docker?
This whole discussion has the same vibes like digital photography 15 years ago. Back then some people spent more time on discussing the tech spec their cameras than takin photos. Now some people spend more time on discussing the pros and cons of different Python environment management solutions than building real things.
The last time I had to touch one of my dockerized environments was when Miniconda and Miniforge were merged. I said the agent "fix the dockerfile", and the third attempt worked. Another time, one dependency was updated and I had to switch to Poetry. Once again, I said the agent "refactor the repository to Poetry" and it worked. Maybe because all my Python package versions are frozen and I only update them when they break or when I need the functionality of the new version.
Whenever this topic pops up in real life, I always ask back what was the longest time they managed the same Python service in the cloud. In the most cases, the answer is never. The last time someone said one year. After a while this service was turned into two .py files.
I don't know. Maybe I'm just too far away from FAANG level sorcery. Everything is a hammer if all you have to deal with are nails.
On the first glance this seems to be a very bad idea. But re-readig this:
> Get answers about any cell in seconds: Navigate complex models instantly. Ask Claude about specific formulas, entire worksheets, or calculation flows across tabs. Every explanation includes cell-level citations so you can verify the logic.
this might just be an excellent tool for refactoring Excel sheets into something more robust and maintainable. And making a bunch of suits redundant.
Once my boss told me: “You can’t force people to do something they don’t want to do.” And this guy just don’t want to work well with you. Period.
I learned one approach that sometimes works: Figure out what they want and give them what they want. But with the condition they change their behavior. From your post, it sounds like this guy wants to be promoted.
If I were you, I would talk to him like this:
“Look, you are good technically. You should be promoted. But higher levels here mean more than just code. It means mentoring, working closer with peers, hiring people, training them, helping management. We have a career path in place, let’s make a plan for you.”
In big companies it’s even easier. Use the promotion track. Show him what’s expected. If he wants the title, he has to play the role.
Three things can happen:
He rises to it: He starts acting more professional, helps others, builds trust. You win, he wins, team wins.
He tries and fails: He’s exposed higher up. He has direct reports. He’s in meetings with management. He can’t hide his behavior anymore. Eventually, they’ll act.
He says “no thanks”: Then it’s clear. He just wants to stay where he is and make your life harder. At least now everyone sees it.
This puts the pressure where it belongs. On him, to live up to what he says he wants.
[Edit]: You can also tell him that if he wants the promotion, he has to start acting like someone at that level. That means following the principle: “There are no mistakes, only lessons we learn from.”
Tell him: "There was an outage. OK. Then step up. Take the lead, organize a post-mortem, and work with others to find real measures that prevent it in the future. Not to assign blame, but to help the organization improve."
Maybe you don’t even join the post-mortem, let him own it. Just make clear: this isn’t about finger-pointing, it’s about building a culture where problems lead to better systems.
I’m planning on making it clear we should do this. I’m expecting push-back. I’m just not going to entertain it and rely on my manager to handle scheduling while I take part in technical review. I’m exhausted of having to fight this guy to do what’s right.
It probably won’t be him who writes it but he’ll have to be involved at least as a code reviewer for the AIs. I’m sure he’s going to complain and try to make it look unnecessary. I’m mostly done trying to make things work with this guy. I’ll move up to my skip if I keep getting hassled like this.
I don’t really understand why there’s so much hate for LLMs here, especially when it comes to using them for coding. In my experience, the people who regularly complain about these tools often seem more interested in proving how clever they are than actually solving real problems. They also tend to choose obscure programming languages where it’s nearly impossible to hire developers, or they spend hours arguing over how to save $20 a month.
Over time, they usually get what they want: they become the smartest ones left in the room, because all the good people have already moved on. What’s left behind is a codebase no one wants to work on, and you can’t hire for it either.
But maybe I’ve just worked with the wrong teams.
EDIT: Maybe this is just about trust. If you can’t bring yourself to trust code written by other human beings, whether it’s a package, a library, or even your own teammates, then of course you’re not going to trust code from an LLM. But that’s not really about quality, it’s about control. And the irony is that people who insist on controlling every last detail usually end up with fragile systems nobody else wants to touch, and teams nobody else wants to join.
It has been discussed ad nauseum. It demolishes learning curve all of us with decade(s) of experience went through, to become seniors we are. Its not a function of age, not a function of time spent staring at some screen or churning our basic crud apps, its function of hard experience, frustration, hard won battles, grokking underlying technologies or algorithms.
Llms provide little of that, they make people lazy, juniors stay juniors forever, even degrading mentally in some aspects. People need struggle to grow, when you have somebody who had his hand held whole life they are useless human disconnected from reality, unable to self-sufficiently achieve anything significant. Too easy life destroys both humans and animals alike (many experiments have been done on that, with damning results).
There is much more like hallucinations, questionable added value of stuff that confidently looks OK but has underlying hard-to-debug bugs but above should be enough for a start.
I suggest actually reading those conversations, not just skimming through them, this has been stated countless times.
I regularly check in on using LLMs. But a key criteria for me is that an LLM needs to objectively make me more efficient, not subjectively.
Often I find myself cursing at the LLM for not understanding what I mean - which is expensive in lost time / cost of tokens.
It is easy to say: Then just don't use LLMs. But in reality, it is not too easy to break out of these loops of explaining, and it is extremely hard to assess when not to trust that the LLM will not be able to finish the task.
I also find that LLMs consistently don't follow guidelines. Eg. to never use coercions in TypeScript (It always gets in a rogue `as` somewhere) - to which I can not trust the output and needs to be extra vigilant reviewing.
I use LLMs for what they are good at. Sketching up a page in React/Tailwind, sketching up a small test suite - everything that can be deemed a translation task.
I don't use LLMs for tasks that are reasoning heavy: Data modelling, architecture, large complex refactors - things that require deep domain knowledge and reasoning.
> Often I find myself cursing at the LLM for not understanding what I mean...
Me too. But in all these cases, sooner or later, I realized I made a mistake not giving enough context and not building up the discussion carefully enough. And I was just rushing to the solution. In the agile world, one could say I gave the LLM not a well-defined story, but a one-liner. Who is to blame here?
I still remember training a junior hire who started off with:
“Sorry, I spent five days on this ticket. I thought it would only take two. Also, who’s going to do the QA?”
After 6 months or so, the same person was saying:
“I finished the project in three weeks. I estimated four. QA is done. Ready to go live.”
At that point, he was confident enough to own his work end-to-end, even shipping to production without someone else reviewing it. Interestingly, this colleague left two years ago, and I had to take over his codebase. It’s still running fine today, and I’ve spent maybe a single day maintaining it in the last two years.
Recently, I was talking with my manager about this. We agreed that building confidence and self-checking in a junior dev is very similar to how you need to work with LLMs.
Personally, whenever I generate code with an LLM, I check every line before committing. I still don’t trust it as much as the people I trained.
That is not really relevant, is it? The LLM is not a human.
The question is whether it is still af efficient to use LLMs after spending huge amounts of time giving the context - or if it is just as efficient to write the code yourself.
> I still remember training a junior hire who started off with
Working with LLMs is not training junior developers - treating it as such is yet another resource sink.
...and you dentist cuts you hair and your hairdresser pulls your teeth. Because everything is a trade what can and should be learned, except if it's related to writing and selling software.
To be fair, you did not say that marketers ship working and maintainable code, salespeople answer technical questions without backup the correct way. Therefore you might be right, thought.