Tech Dive

in postgresql, each standalone sql statement is atomic by default in autocommit mode, so if you do not start an explicit transaction block, that statement behaves as its own transaction.

@SumitM_X yes, but the job description changed while we were playing foosball. lol.

Think what needs to be done for the day while you are in the cab to office… Reach office, dump those ideas into Claude AI… grab a coffee… play foosball while its working… come back, review, tweak a few things… Then go for lunch… take a walk while its still working in the background… come back, review again… maybe refine a bit more… Evening tea… push your changes… log off. Has life ever been this convenient for software engineers?

@arpit_bhayani yes and asking the right question is actually multiple different skills put together. like figuring out who has the problem, whether they will pay to solve it, whether solving it creates new problems later, etc.

The ability to ask the right question is more important than ever now. With AI generating slop and enabling you to build almost anything, having clarity on what to build, why to build it, who it is for, and what problem it actually solves is more important than ever. We are going to see a flurry of things people build that no one asked for. Critical thinking is the only real edge left - the real moat.

reviewing is still possible, the main thing is not to accept large chunks of code at once. if changes are small, spread across a few files, and built step by step then review stays easy even with ai help. another useful pattern is to have a dedicated file that explains the feature, its intent, logic and constraints so reviewers understand the why before reviewing the how.

there's no way to review all code produced by ai and there's no way you're actually reviewing all the code explanations

reviewing is still possible, the main thing is not to accept large chunks of code at once. if changes are small, spread across a few files, and built step by step then review stays easy even with ai help. another useful pattern is to have a dedicated file that explains the feature, its intent, logic and constraints so reviewers understand the why before reviewing the how.

what is the difference between an atomic operation and a transaction? are they the same?

@shl the question is whether contributing to a codebase means the same thing anymore. generating a feature with ai and merging it without understanding its impact is not really contribution, it just increases the codebase and adds maintenance cost.

Before, only engineers could contribute to a codebase Now, everyone can

good point and this also applies to success responses, not just errors. for example, saying email already registered during signup can be a problem because it tells someone which emails exist in your system. a safer way is to say that if an account exists you will receive an email.

@justinskycak a bit of it is fine but the problem starts when it replaces creating, thinking, or making your own decisions. all platforms are built to remove friction, so if you do not set limits, they will easily take all your attention.

Passive consumption will waste your life unless you intentionally defend yourself against it.

atomicity and transactions can feel the same at first, but they are not. atomicity is a property that means a unit of work either fully happens or does not happen at all. a transaction, on the other hand, is a group of operations that is treated as a single unit of work, meaning either all operations are done or none. so atomicity makes sure that in a transaction either all operations are done or they get rolled back.

deep work is your actual competitive advantage. if you can't go 4 hours without checking slack, you're cooked.

design taste matters, but design curiosity might matter more. engineers who think they lack taste just haven’t spent enough time noticing why something feels off. with ai, you can now describe a problem, generate multiple solutions, and refine your judgment through iteration. it is something you can learn much faster now than before.

I never realized how rare good design is in software. If you’ve good design taste, you’ve incredible edge with AI

agree. working on a large codebase does teach a lot especially when you focus on understanding the system. the lessons are less about the language or syntax, but more about how decisions were made, how over time it became complex, etc. so it is a great learning experience if you go beyond the surface level.

working on a large codebase for a long time teaches you invaluable lessons

@justinskycak that's true, if most of your work is about maintenance then basically then your progress is limited. for some time it might be needed, but if it remains this way perhaps you ain't evolving

Don't mistake administrative maintenance for meaningful production.

@Franc0Fernand0 nothing is really dead it is just that average skill is not enough anymore. if you are easy to replace people will treat you that way.

PHP is dead. C++ is dead. Java is dead. DSA is dead. Web development is dead. Software engineering is dead. You read posts like these every day, but the truth is that nothing is dead. You just need to get better at what you do. Keep learning, building, and growing.

what really happens when a db transaction fails midway? db transaction we already know, they execute multiple statements as a single unit of work that means if you have 100 queries that make changes to db all would execute all or none now suppose some error comes during your transaction, in that case some queries would have run and some were yet to run means some data is already present in write-ahead-log file and maybe even in db disk by now while rest of the changes never occurred so when transaction fails it gets marked as aborted in postgres now since transaction is marked as aborted there are few cases 👉 if data pages are already written to disk in that case those rows are physically present in db but they are invisible to other queries this is because of mvcc and later vacuum will clean them 👉 if changes are not written to disk and only in memory and write-ahead-log file in that case they may never reach disk and even if crash happens postgres will not replay them because there is no commit 👉 write-ahead-log file always has all the changes but during recovery postgres only replays committed transactions so basically during a transaction data can be present at three places at a time 1. memory where changes happen 2. write-ahead-log file 3. disk where actual data is stored so this is how rollback works in postgres it does not actually undo things physically it just marks transaction as aborted and mvcc makes sure those changes are not visible this is why it feels kind of magical even when thousands of operations are part of a single transaction.

i think the best way to use ai for code reviews is to be clear about how it should be used. it is better if we decide what ai should handle like checking code style suggesting tests and spotting possible security issues. and similarly create a simple checklist for humans that ai does not cover like how clear the design is how good the naming is and how different parts of the code are connected.

As human code reviews are becoming more and more a bottleneck, I am hearing from many different people that they are relying more on AI code reviews.

most productivity issues are actually prioritization issues in disguise