While this is a legitimate set of rules to follow for maintaining code sanity and a solid mental model of how a codebase may grow, it’s always challenging to stick to them in a workplace where expectations around delivery speed have changed drastically with the onset of AI. The sweet spot lies in striking a balance between staying connected to the codebase and not becoming a limiting factor for the team at the same time.
That's kind of what I figured, sadly. I haven't experienced it personally yet since I got let go from my last job about 14 months ago, but it makes so much sense given how management is so willing to sacrifice quality for speed.
Another frustrating thing that has emerged from this is where managers “vibe code” half-baked ideas for a couple of hours and then hand it off as if they’ve meaningfully contributed to the implementation. Suddenly you’re expected to reverse engineer incoherent prompts, inconsistent code, and random abstractions that nobody fully understands.
In their mind they’ve already done the “architectural heavy lifting” and accelerated the team.
More often than not it just adds cognitive overhead where you spend more time deciphering and cleaning up garbage than actually building the thing properly from scratch.
Vouching for this comment because my friend confided in me a week ago that her manager also does this and is like “oh yeah, here’s 80% done, you just do the rest so we can ship it” when a large part of it is slop that needs to be rewritten, due to not enough guidance and pushback during generation.
Writing tests against a bad implementation usually doesn't work well. In this scenario I would have an LLM look at the changes in the branch and try to create a markdown document of the changes, why it thinks they were made, etc. and then review that doc with the manager and do a new implementation from scratch after aligning.
Unless the tests are written against logic that is in of itself subtly wrong and even the structure of code and what methods there are is wrong - so even your unit tests would have to be rewritten because the units are structured badly.
It’s a valid direction to look in, it just doesn’t address the root issue of throwing slop across the wall and also having unrealistic expectations due to not knowing any better.
Yep. It’s very healthy to be suspicious of code. Any code. Whether generated or not. That’s where the bugs are.
If there’s one thing that’s disturbing with AI proponent is how trusting they are of code. One change in the business domain and most of the code may have turn from useful to actively harmful. Which you have to rewrite. Good luck doing that well if you’re not really familiar with the code.
I am lucky to have never worked in a team where my manager wouldn't expect strong push back in this scenario. Many of the corporate environments described on here seem dystopian, this included.
To make a bit of a counter argument here - it's really hard to stick to 100% quality at speed 1.0, when your opponent argues for 90% at 2.5. That's the story the AI fast-movers are telling, and from a business perspective, it's hard to counter it (regardless of whether that speed increase actually materialises).
It gives you clean text summaries of YouTube videos. There are obviously other tools that do this, but I wanted something that is aligned with actual principles of learning and retention, not just quick TLDRs.
Also added a feature called Related Videos. It extracts the key themes from a video and recommends the top 3 related videos, essentially creating a small “knowledge web” of sorts around the topic. Similar to youtube recommendations, but you don't watch you click and read.
You can do YouTube search directly inside the product. When you click a video, it generates a summary. So you’re still browsing YouTube, but click turns a video into something you can actually consume. Personally found it better way to consume youtube, quicker for me to get through the content I want to consume than have those 10+ Youtube tabs sitting in my browser forever.
There’s also a public library feature I added where you can make your summary public. It’s kind of fun to see what other people are learning.
Still early, but iterating on it, scratching my own itch.
Searching for what to solve becomes far more important than how to solve it. Which niche you serve, how underserved the problem is, how quickly you build a solution, and how fast you iterate based on user feedback become the real differentiators. As a problem gains popularity, competitors will enter at an increasing pace, and the product’s price will be competed down to the bare minimum. At that point, the only real advantage for a builder is to be a serial builder for deep niches, spotting them faster than others and delivering quality product to users before anyone else.
Excellence in anything is a byproduct of having fun. Fun is a byproduct of understanding. Understanding is a byproduct of going slow. Going slow is a byproduct of curiosity. Curiosity is a byproduct of saying "I don’t know," of shunning beliefs and attending to what is in front, with zero baggage or impositions of your own—shunning the ego in the moment, moment by moment. Excellence comes when each piece is as equal as any other, when preference is shunned, when space is created to allow what is in the moment, without resistance, without insistence.
This is relatable. Once one gets over the frustration of failing and making mistakes (thousands of times in some cases), it becomes fun and easier to stay curious.
I've seen a lot of people play cricket and soccer all their lives, they had a metric ton of fun, and im sure I will not put them close to the word excellent in any aspect of their lives. Im not sure any of the statements you made are agreeable in fact.
I don't think GP is saying that if something is fun you will become excellent at it. Rather, of you want to excel in anything it is a huge advantage if you enjoy doing it, so try to keep it fun.
This book has stayed with me for years. It's a quiet, deeply reflective journey about self-discovery, the search for meaning. What resonated most was this idea that true understanding can't be taught—it must be lived and experienced.
It’s a short read, but one that invites you to slow down. Each time I return to it, I take away something new depending on where I am in life.
I'm a Product Manager turned Coder, I had a strong stint as a PM for 7+ years, at my last company (YC S21) I scaled the DAU from 10k to 250k+ & MAU to 1 million+.
Now I'm looking to get to the fundamentals of building. That's why I have been learning backend development for the past 1 year, you can view my resume for more details on my coding projects and my achievements from 7+ years of PM career.
Can bring a good balance of user centric mindset to feature development. Since I'm sort of rebooting my career here, I'm looking at SD-1 level roles at the moment. Would love to chat about this.
Start by questioning every aspect of your life, your actions, your intentions, your thoughts - why are they the way they are? Books and mental models are mere tools that won't get you anywhere, they just add to the conditioning and the "burden" of knowledge. To find your own philosophy of life you have to start by unconditioning your mind so you can become sensitive to the reality as it is and not what the world around you has taught you.
Just finished it last week, it made me revisit the idea of "What it means to have meaning in life?" and how personal that is, and have a wholesome view of my personality without any prejudice.
