Tech Dive

helping engineers understand how systems scale, fail & recover in production.

[Tech Dive @techhdive]

there's no metric that tells you whether a piece of code is perfect.

for me, a good sign is when i can understand a feature without constantly jumping around the codebase trying to figure out what's going on.

if it's easy to follow, easy to change and adding a new requirement doesn't turn into a whole thing, you're probably doing fine.

[Tech Dive @techhdive]

i think this happens with a lot of productivity tools.

they don't always reduce the amount of work. a lot of the time they just raise the bar for what's considered normal output.

what used to take a week now takes a day and before long everyone is expected to do it in a day.

and once something becomes easier, people start asking for more of it. so the time you save often gets replaced by new tasks, bigger projects or higher expectations.

[djay @winterwaltzzz]

AI was supposed to reduce my work but it's making me work twice as hard

[Tech Dive @techhdive]

well said. another thing is that when you sit with a problem longer and think through different approaches, you also start to understand why some solutions aren't a good fit for that particular situation.

over time that builds a lot of pattern recognition. from the outside it can look like some people just know everything, but a lot of it comes from putting in the work and seeing enough problems that certain patterns start to stand out much faster.

[Tech Dive @techhdive]

the biggest difference for me is that i don't spend nearly as much time searching through random websites anymore.

especially when you hit some weird error. instead of opening a bunch of tabs and digging through stack overflow posts, you can usually get pointed in the right direction pretty quickly.

that alone saves a lot of time.

[Tech Dive @techhdive]

best time to do focused work in the office is before everyone arrives or after everyone leaves.

[Tech Dive @techhdive]

i'd probably take it.

for me, the biggest benefit of remote work is uninterrupted time.

in the office, there's always something breaking your focus. people stopping by, meetings, lunch, coffee, random conversations.

all of that is fine, but if you're trying to spend a few hours deeply focused on something, it's much easier to do from home.

[Tech Dive @techhdive]

@Prathkum lot of this just feels like marketing to me.

make a bold claim about developers disappearing, get people arguing about it for a week and now everyone is talking about your product.

fear gets people's attention pretty quickly.

[Tech Dive @techhdive]

what i've seen in myself is that a surprising amount of what feels like a lack of motivation is actually poor sleep, no exercise and spending too much time indoors.

[Tech Dive @techhdive]

in corporates some people will throw you under the bus just for a little visibility from someone who doesn't even care about them

[Tech Dive @techhdive]

haha. but actually meetings are expensive because they break your focus.

you can be right in middle of figuring something out, jump on a call and then spend the next 20 minutes trying to get your head back into the problem afterwards.

personally, i think every meeting should have a clear reason for existing. not just an agenda. everyone has an agenda.

a actual outcome. it could a decision that needs to be made or something that should be different by the end of meeting.

[Tech Dive @techhdive]

haha. but actually meetings are expensive because they break your focus.

you can be right in middle of figuring something out, jump on a call and then spend the next 20 minutes trying to get your head back into the problem afterwards.

personally, i think every meeting should have a clear reason for existing. not just an agenda. everyone has an agenda.

a actual outcome. it could a decision that needs to be made or something that should be different by the end of meeting.

[Tech Dive @techhdive]

haha. but actually meetings are expensive because they break your focus.

you can be right in middle of figuring something out, jump on a call and then spend the next 20 minutes trying to get your head back into the problem afterwards.

personally, i think every meeting should have a clear reason for existing. not just an agenda. everyone has an agenda.

a actual outcome. it could a decision that needs to be made or something that should be different by the end of meeting.

[Tech Dive @techhdive]

discord servers can have millions of members.

now if a popular channel where thousands of people are opening the same messages at roughly the same time.

the naive approach is to let every request hit the database on its own. if 1000 users need the same data, that's potentially 1000 identical database reads.

discord talked about running into this with hot channels.

the interesting part is that the solution wasn't just caching. they also used request coalescing.

so if a bunch of requests for the same data show up at the same time, only one database fetch is made. everyone else just waits for that result instead of triggering their own query.

it's mainly to stop a sudden burst of identical requests from hammering the database.

this made sure they don't run the same query a thousand times to get the same result.

[Tech Dive @techhdive]

this only works if people are actually given the freedom to own the outcome.

a lot of companies say they want ownership, but every meaningful decision has to go through multiple reviews and approvals.

if you want someone to be accountable for the result, you have to let them make decisions along the way.

it's hard to own an outcome when you're executing someone else's plan.

[Tech Dive @techhdive]

@Venkydotdev haha

[Tech Dive @techhdive]

@ajay_2512x great man. are these lld rounds usually language specific or can you just use whatever language you're comfortable with?

[Tech Dive @techhdive]

this is exactly how great engineers are built.

a lot of people want to jump straight to architecture, system design and big technical decisions.

but the engineers who do these things well have spent years building a understanding of the fundamentals first.

once the basics become second nature, you stop spending mental energy on them and can focus on higher level tradeoffs and design decisions instead.

[Tech Dive @techhdive]

yeah, that's the right way to use it.

the more specific you are about what you want, the better the result tends to be.

tell it what modules or files it should touch, what logic you think makes sense, what constraints it should follow and what you don't want it changing.

i also like telling it: if anything is ambiguous, ask questions instead of making assumptions.

a lot of it comes down to putting in the effort to figure out what you actually want before asking the AI to build it.

and at the end, review the code and test it yourself.

[Tech Dive @techhdive]

true. the main thing is getting the core problem right and making that part really good.

once that's working well, then it makes sense to add other stuff that actually improves the product.

a lot of products end up with tons of features, but the main thing people came there for still isn't that great.

at the end of the day, people are paying for the problem you solve. the features are there to make that experience better.