This post hits on something crucial - the difference between performative code review and substantive collaboration. The "theatre" metaphor is spot-on.
The core issue Saša identifies - PRs that are "unreviewable" getting rubber-stamped with "LGTM". Teams go through the motions without the actual substance.
The storytelling approach through commits is brilliant, but it only works if you solve the human factors too. Even perfectly crafted PRs with great commit narratives get surface-level reviews. The friction kills engagement.
A few complementary approaches I've seen work: pair reviewing for complex changes that are hard to break down, AI pre-screening for basic issues so humans can focus on architecture/business logic, and synchronous review sessions when async back-and-forth is just burning time.
The key insight: good PR structure needs to be paired with removing tooling friction. When review is painful, people default to "LGTM" regardless of how well the story is told.
I'm assuming you're thinking about whether or not to allow the interviewee to use AI to answer code-related questions or problems.
I'll be honest. This is a huge debate now, given the shift of utilizing AI. However, I believe that the interviews should be a direct reflection of what the employee will be doing at the company. If that company uses AI in their workflows, then why shouldn't it be allowed in interviews? You need to see the way the user utilizes AI to solve problems or understand their thought processes.
I like that title more now that I'm thinking about. The credit will always go to the one doing the work, and agents, programs, or systems still need the human touch.
Good callout. Do you feel like when failing, even if the issue was inherently the human's fault, blaming it on AI makes it a lot easier than admitting to mistakes?
You make a good point: Saying you "Googled" something does not give it as much credit since we know it's not Google, but all the other websites, publications, and sources that provided the info. You'd probably credit the website itself.
I agree with the claim that the credit essentially should go to the one doing the "heavy lifting" aka training the LLM to even create the output.
First things first, it's ok to feel this. Never invalidate your feelings. You clearly have been through a lot and it will affect your daily tasks.
Coding is hard, no matter how small or big the project, and it requires a certain type of brain power and capability.
Start by counting your wins. You have somehow made it through hardships and still managed to create something successful - that's one. (a big one)
take it day by day. But know you're not alone. Don't forget to take time for yourself :)
It's a huge search engine, or basically another "Google" but with more insights and ideas. People I know usually go to GPT to clarify ideas, thoughts, or help with more mundane things they want done quickly.
Not sure why Figma needed to step out of their way to do something like this, but "dev mode" is not as serious of a case..makes me a bit concerned where their heads are
The truth is, while you had past jobs you hated or regretted it, you got something out of it. You learned to deal with difficult people, you learned to manage hard situations, you navigated through tumultuous times, you learned a ton about growing, and you found out what you were capable of even in the darkest times.
If anything, this can be super positive. You can also just say your past roles "were a good start to your career but didn't fit my future goals as much as this role does" and then jump in to what you want to do in your future and how this role fits.
Education is incredibly important. Giving your kids al the freedom with AI without really showing its proper use is a big mistake especially at this day and age.
Teaching your kids about how AI is a resource, a tool, something revolutionary, or similar is the best approach.
The storytelling approach through commits is brilliant, but it only works if you solve the human factors too. Even perfectly crafted PRs with great commit narratives get surface-level reviews. The friction kills engagement.
A few complementary approaches I've seen work: pair reviewing for complex changes that are hard to break down, AI pre-screening for basic issues so humans can focus on architecture/business logic, and synchronous review sessions when async back-and-forth is just burning time.
The key insight: good PR structure needs to be paired with removing tooling friction. When review is painful, people default to "LGTM" regardless of how well the story is told.