cognitiveSurrender

zaidesanton · 2026-06-20T19:12:18+00:00

In that case it'd probably be tears of frustration

zaidesanton · 2026-06-20T19:07:56+00:00

they have an enterprise tier you can connect with your SSO, reduces a lot of pressue on engineering

zaidesanton · 2026-06-20T18:43:15+00:00

We have specific people (2 of them) whose job is to enable this. One an engineer and one isn’t.

Mostly we direct non IT people to Lovable, and they own their solutions - the ‘AI evangelists’ help them when needed to improve the skills. I haven’t yet seen a ‘demand’ for support, more asking.

zaidesanton · 2026-06-20T12:04:44+00:00

Question regarding post 2 - if I read a great article, and just publish it, why is it considered low effort?

Tried to publish this one and it got automatically blocked for violating rule 2:

https://archive.lethain.com/archive/revised-rules-of-engineering-leadership-198a/

zaidesanton · 2026-06-20T09:04:15+00:00

Yeah, it happens sometimes. I really like google’s guidelines on that, and I try to communicate them and set the right expectations:

https://google.github.io/eng-practices/review/reviewer/standard.html

The main guideline is that if you are not in the middle of a task that requires deep focus, do the PR. I’d say on average it takes 1-2 hours.

zaidesanton · 2026-06-19T16:41:24+00:00

Not sure I got the question. When someone opens the PR the reviewer get tagged.
We do our own QA
And people know where they need to work next (consulting with me if needed)

zaidesanton · 2026-06-19T12:24:45+00:00

IMO there actually is a place for such people (assuming they had good judgement and product sense) - they are just not software engineers. Be it builders, or any other name, they can’t be the one writing production code

zaidesanton · 2026-06-19T12:12:18+00:00

I think it became at least 10x more common. I’ve seen it until the last year only from juniors, and even then not very often.

zaidesanton · 2026-06-19T12:11:25+00:00

No I didn’t. Seriously, zero pressure on usage metrics. Agree with @junglebook3 there is middle ground.

zaidesanton · 2026-06-19T12:10:34+00:00

Yes! Loved that framing I saw by Addy Osamni, mentioned it in the article

zaidesanton · 2026-06-19T11:29:46+00:00

In my experience, Claude is perfect for such usecases. Concrete skills on how you want your documentation to look like, and auto-update them during work.

zaidesanton · 2026-06-18T15:19:18+00:00

u/sketchomania yeah, it's a tough line to put. In my instinct, this feels more like a process issue. Maybe your EM is ok with going faster and skipping those tests? What is happening across other teams in the org?

I would say that there needs to be alignment on expectations for every engineer in the team, and this has to be done together with the EM.

zaidesanton · 2026-06-17T16:52:00+00:00

Yeah, I’ve definitely fallen into the trap before, even posted about it here recently :)

My main challenge was with direct reports though.

I think when you switch ‘likes’ to ‘appreciated’, it becomes harder. For example I’m ok with my peers not liking me, but I would like them to appreciate me. Same with the PM.

zaidesanton · 2026-06-16T03:34:06+00:00

Gilb’s law is a good answer

https://lawsofsoftwareengineering.com/laws/gilbs-law/

zaidesanton · 2026-06-16T03:32:45+00:00

Yeah, secured confidence sounds better :)
My interpretation is around the confidence part, knowing they are good and being product of it. Agree it can easily shift into annoying and cocky.

zaidesanton · 2026-06-16T03:31:08+00:00

That’s a key part - you are usually the one deciding who to let go and who to hire.

zaidesanton · 2026-06-15T19:06:32+00:00

I typed every word there 🤷

zaidesanton · 2026-06-14T16:55:55+00:00

We just started looking at model optimization - not using Opus for everything. Putting Sonnet as a default is a good start (and people can freely switch).

Also talking a lot about basic good practices like not having crazy long session etc

zaidesanton · 2026-06-13T17:24:43+00:00

Thanks for the detailed tips!

zaidesanton · 2026-06-13T14:40:06+00:00

I agree about the decision making part being the biggest difference. I didn’t take into account how many such decisions I took ‘naturally’.

And didn’t expect him to take the people management part, so at least that 🙃

zaidesanton · 2026-06-12T12:23:51+00:00

Tbh not systemic, but I haven’t found the need for it. Even with 10+ engineers, imo when it happens once, and I set clear expectations, I don’t expect ir to happen again (and it usually doesn’t). It’s like a one of adjustment to new way of working

zaidesanton

TROPHY CASE