LinkedIn'dan yaxshi post topib oldim :)
https://www.linkedin.com/posts/zayniddin-atabaev_over-the-years-ive-come-to-realize-that-activity-7349872339901190145-WmQw
https://www.linkedin.com/posts/zayniddin-atabaev_over-the-years-ive-come-to-realize-that-activity-7349872339901190145-WmQw
Linkedin
Over the years, I’ve come to realize that one of the most underrated forms of developer productivity is being “mobile” — mentally…
Over the years, I’ve come to realize that one of the most underrated forms of developer productivity is being “mobile” — mentally and technically.
By mobile, I don’t just mean switching devices or working remotely. I mean the ability to spin up your environment…
By mobile, I don’t just mean switching devices or working remotely. I mean the ability to spin up your environment…
🔥3
As a backend developer, I often focus on shipping features, building APIs, optimizing queries…
But when something breaks in production — and it will — the real question becomes:
“Do I have enough visibility to know what happened?”
In my experience, three things have saved me time and again when something goes wrong:
🔹 Logging — not just errors, but meaningful events with context (userId, action, payload)
🔹 Storing state change history — for example, keeping a record of every transaction status transition (INITIATED → PENDING → COMPLETED → FAILED)
🔹 Setting up alerts — not for every blip, but for real anomalies (e.g., job queues stuck, DB connection resets, invalid state transitions)
When an issue hits production — a bug, a dropped webhook, or a corrupted state — your recovery speed is directly tied to how much insight you’ve built in advance.
Because in those moments:
⚠️ Without observability, we’re blind.
🛡 With the right data trail, we become fast, precise, and calm.
In your codebase, every log and tracked event is an investment in your future self.
©️ LinkedIn
But when something breaks in production — and it will — the real question becomes:
“Do I have enough visibility to know what happened?”
In my experience, three things have saved me time and again when something goes wrong:
🔹 Logging — not just errors, but meaningful events with context (userId, action, payload)
🔹 Storing state change history — for example, keeping a record of every transaction status transition (INITIATED → PENDING → COMPLETED → FAILED)
🔹 Setting up alerts — not for every blip, but for real anomalies (e.g., job queues stuck, DB connection resets, invalid state transitions)
When an issue hits production — a bug, a dropped webhook, or a corrupted state — your recovery speed is directly tied to how much insight you’ve built in advance.
Because in those moments:
⚠️ Without observability, we’re blind.
🛡 With the right data trail, we become fast, precise, and calm.
In your codebase, every log and tracked event is an investment in your future self.
©️ LinkedIn
Linkedin
As a backend developer, I often focus on shipping features, building APIs, optimizing queries… | Zayniddin Otabaev
As a backend developer, I often focus on shipping features, building APIs, optimizing queries…
But when something breaks in production — and it will — the real question becomes:
“Do I have enough visibility to know what happened?”
In my experience, three…
But when something breaks in production — and it will — the real question becomes:
“Do I have enough visibility to know what happened?”
In my experience, three…
🔥2👍1
Googledan "Bitchat" deb qidirib ko'rishlarizni maslahat beraman, qiziq narsalar bo'lyabdi ekan :)
I've come to believe that “senior developer” isn’t about years of experience, certificates, or job titles.
It’s about how you show up when things get hard.
It’s in the way you:
● Take ownership of broken systems without waiting to be asked
● Volunteer for the tasks no one else wants, because they’re unclear, complex, or high-risk
● Communicate openly when you’re stuck — and ask for help without ego
● Stay calm during incidents and bring clarity, not more chaos
● Think about the impact of your code, not just the syntax
● Mentor others quietly, by leading with action
To me, being “senior” is more about how you behave when you’re under pressure, than what you’ve achieved when things are going smoothly.
It’s courage. It’s clarity.
And it’s a constant effort — not a checkbox.
©️ LinkedIn
It’s about how you show up when things get hard.
It’s in the way you:
● Take ownership of broken systems without waiting to be asked
● Volunteer for the tasks no one else wants, because they’re unclear, complex, or high-risk
● Communicate openly when you’re stuck — and ask for help without ego
● Stay calm during incidents and bring clarity, not more chaos
● Think about the impact of your code, not just the syntax
● Mentor others quietly, by leading with action
To me, being “senior” is more about how you behave when you’re under pressure, than what you’ve achieved when things are going smoothly.
It’s courage. It’s clarity.
And it’s a constant effort — not a checkbox.
©️ LinkedIn
Linkedin
I've come to believe that “senior developer” isn’t about years of experience, certificates, or job titles. | Zayniddin Otabaev
I've come to believe that “senior developer” isn’t about years of experience, certificates, or job titles.
It’s about how you show up when things get hard.
It’s in the way you:
● Take ownership of broken systems without waiting to be asked
● Volunteer for…
It’s about how you show up when things get hard.
It’s in the way you:
● Take ownership of broken systems without waiting to be asked
● Volunteer for…
🔥2
I once rewrote a feature for the third time!!!
Not because of bugs.
Not because of bad code.
But because no one spoke up.
The spec was vague.
The use case was unclear. The “product owner” wasn’t really owning the product.
And I didn’t ask enough questions.
Neither did anyone else.
So I built what I thought they meant.
Then rebuilt it after a “quick feedback loop.”
Then rebuilt it again when it turned out the stakeholders had different expectations all along.
That experience taught me something I’ll never forget:
Silence in a team isn’t peace. It’s misalignment waiting to explode.
Now I try to:
- Ask the “dumb” questions early
- Pull clarity out of ambiguity
- Push for written decisions
- Speak up when something feels fuzzy
- Encourage others to do the same
Because clear communication today saves weeks of rework tomorrow.
©️ LinkedIn
Not because of bugs.
Not because of bad code.
But because no one spoke up.
The spec was vague.
The use case was unclear. The “product owner” wasn’t really owning the product.
And I didn’t ask enough questions.
Neither did anyone else.
So I built what I thought they meant.
Then rebuilt it after a “quick feedback loop.”
Then rebuilt it again when it turned out the stakeholders had different expectations all along.
That experience taught me something I’ll never forget:
Silence in a team isn’t peace. It’s misalignment waiting to explode.
Now I try to:
- Ask the “dumb” questions early
- Pull clarity out of ambiguity
- Push for written decisions
- Speak up when something feels fuzzy
- Encourage others to do the same
Because clear communication today saves weeks of rework tomorrow.
©️ LinkedIn
Linkedin
I once rewrote a feature for the third time. | Zayniddin Otabaev
I once rewrote a feature for the third time.
Not because of bugs.
Not because of bad code.
But because no one spoke up.
The spec was vague.
The use case was unclear.
The “product owner” wasn’t really owning the product.
And I didn’t ask enough questions.…
Not because of bugs.
Not because of bad code.
But because no one spoke up.
The spec was vague.
The use case was unclear.
The “product owner” wasn’t really owning the product.
And I didn’t ask enough questions.…
Some days I write 0 lines of code and still feel productive.
Other days I write 500 lines and feel like I did nothing.
Being busy is not the same as being effective.
When I started out, I thought output meant progress.
Now I know that real impact looks more like this:
- Finishing a critical feature end to end
- Unblocking a teammate who was stuck
- Asking the hard question no one asked
- Spotting a risk before it turns into a bug
- Saying no to work that doesn't move the needle
It’s easy to measure how much you do.
But it’s hard to measure how much you change.
And that’s the part that matters.
©️ LinkedIn
Other days I write 500 lines and feel like I did nothing.
Being busy is not the same as being effective.
When I started out, I thought output meant progress.
Now I know that real impact looks more like this:
- Finishing a critical feature end to end
- Unblocking a teammate who was stuck
- Asking the hard question no one asked
- Spotting a risk before it turns into a bug
- Saying no to work that doesn't move the needle
It’s easy to measure how much you do.
But it’s hard to measure how much you change.
And that’s the part that matters.
©️ LinkedIn
Linkedin
Some days I write 0 lines of code and still feel productive. | Zayniddin Otabaev
Some days I write 0 lines of code and still feel productive.
Other days I write 500 lines and feel like I did nothing.
Being busy is not the same as being effective.
When I started out, I thought output meant progress.
Now I know that real impact looks more…
Other days I write 500 lines and feel like I did nothing.
Being busy is not the same as being effective.
When I started out, I thought output meant progress.
Now I know that real impact looks more…
🔥2
If no one’s reviewing your code, that’s not trust. That’s risk.
Even senior developers need feedback.
Even experienced engineers miss things.
Even well-tested code can go wrong if it’s built on bad assumptions.
Code reviews aren’t just about syntax or formatting. They catch:
● Gaps in business logic
● Missed edge cases
● Overcomplicated solutions
● Misaligned decisions that could impact others
Reviews protect the system, not your ego.
And if your team avoids reviewing your work because you're "senior," it might be time to ask: am I really leading - or just moving fast alone?
© LinkedIn
Even senior developers need feedback.
Even experienced engineers miss things.
Even well-tested code can go wrong if it’s built on bad assumptions.
Code reviews aren’t just about syntax or formatting. They catch:
● Gaps in business logic
● Missed edge cases
● Overcomplicated solutions
● Misaligned decisions that could impact others
Reviews protect the system, not your ego.
And if your team avoids reviewing your work because you're "senior," it might be time to ask: am I really leading - or just moving fast alone?
Linkedin
If no one’s reviewing your code, that’s not TRUST! | Zayniddin Otabaev
If no one’s reviewing your code, that’s not TRUST! That’s RISK!
Even senior developers need feedback.
Even experienced engineers miss things.
Even well-tested code can go wrong if it’s built on bad assumptions.
Code reviews aren’t just about syntax or formatting.…
Even senior developers need feedback.
Even experienced engineers miss things.
Even well-tested code can go wrong if it’s built on bad assumptions.
Code reviews aren’t just about syntax or formatting.…
The worst bugs I’ve seen weren’t caused by bad code.
They were caused by assumptions.
- Assuming a status could never be null
- Assuming a third-party API would always respond
- Assuming a queue job wouldn’t retry at the wrong time
- Assuming a user would never submit the same form twice
- Assuming “this should never happen” actually means it won’t
Clean code doesn’t protect you from flawed thinking.
Tests won’t help if you test the wrong scenario.
And documentation rarely keeps up with real-world behavior.
The deeper I go in backend work, the more I value this:
Don’t code based on what you assume.
Code based on what the system might do - especially when things go wrong.
Because when assumptions fail, users pay.
©️ LinkedIn
They were caused by assumptions.
- Assuming a status could never be null
- Assuming a third-party API would always respond
- Assuming a queue job wouldn’t retry at the wrong time
- Assuming a user would never submit the same form twice
- Assuming “this should never happen” actually means it won’t
Clean code doesn’t protect you from flawed thinking.
Tests won’t help if you test the wrong scenario.
And documentation rarely keeps up with real-world behavior.
The deeper I go in backend work, the more I value this:
Don’t code based on what you assume.
Code based on what the system might do - especially when things go wrong.
Because when assumptions fail, users pay.
©️ LinkedIn
Linkedin
The worst bugs I’ve seen weren’t caused by bad code. | Zayniddin Otabaev
The worst bugs I’ve seen weren’t caused by bad code.
They were caused by assumptions.
- Assuming a status could never be null
- Assuming a third-party API would always respond
- Assuming a queue job wouldn’t retry at the wrong time
- Assuming a user would…
They were caused by assumptions.
- Assuming a status could never be null
- Assuming a third-party API would always respond
- Assuming a queue job wouldn’t retry at the wrong time
- Assuming a user would…
Every messy legacy system was once someone's "best idea at the time".
It probably solved a real problem.
It probably worked under different constraints.
It might’ve even been impressive - for its moment.
Years later, we inherit it.
We complain about the code.
We rewrite it, rearchitect it, modernize it.
And one day, our new system becomes the next legacy.
That’s the cycle. And it’s normal.
Legacy isn’t failure.
It’s just time, business pressure, and change - layered into code.
©️ LinkedIn
It probably solved a real problem.
It probably worked under different constraints.
It might’ve even been impressive - for its moment.
Years later, we inherit it.
We complain about the code.
We rewrite it, rearchitect it, modernize it.
And one day, our new system becomes the next legacy.
That’s the cycle. And it’s normal.
Legacy isn’t failure.
It’s just time, business pressure, and change - layered into code.
©️ LinkedIn
Linkedin
Every messy legacy system was once someone's “best idea at the time.” | Zayniddin Otabaev
Every messy legacy system was once someone's “best idea at the time.”
It probably solved a real problem.
It probably worked under different constraints.
It might’ve even been impressive — for its moment.
Years later, we inherit it.
We complain about…
It probably solved a real problem.
It probably worked under different constraints.
It might’ve even been impressive — for its moment.
Years later, we inherit it.
We complain about…
Building APIs is easy.
Designing them is not.
Anyone can expose a controller and return some JSON.
But building an API that survives long-term use - that’s different.
Here are a few lessons I learned the hard way:
● Never skip pagination - you'll regret it once the dataset grows
● Plan for versioning from day one - breaking changes are expensive
● Be strict about request/response schemas - even for internal clients
● Add idempotency for critical POST requests - retries will happen
● Design with unknown clients in mind - today it's your frontend, tomorrow it's a third party
● Think in use cases, not database tables - your API is not your ORM
Good APIs are more than HTTP wrappers around services.
They’re contracts. They shape how others build on top of your work.
Build them like they'll outlive your current stack.
Because they often do.
©️ LinkedIn
Designing them is not.
Anyone can expose a controller and return some JSON.
But building an API that survives long-term use - that’s different.
Here are a few lessons I learned the hard way:
● Never skip pagination - you'll regret it once the dataset grows
● Plan for versioning from day one - breaking changes are expensive
● Be strict about request/response schemas - even for internal clients
● Add idempotency for critical POST requests - retries will happen
● Design with unknown clients in mind - today it's your frontend, tomorrow it's a third party
● Think in use cases, not database tables - your API is not your ORM
Good APIs are more than HTTP wrappers around services.
They’re contracts. They shape how others build on top of your work.
Build them like they'll outlive your current stack.
Because they often do.
©️ LinkedIn
Linkedin
Building APIs is easy. | Zayniddin Otabaev
Building APIs is easy.
Designing them is not.
Anyone can expose a controller and return some JSON.
But building an API that survives long-term use - that’s different.
Here are a few lessons I learned the hard way:
● Never skip pagination - you'll regret…
Designing them is not.
Anyone can expose a controller and return some JSON.
But building an API that survives long-term use - that’s different.
Here are a few lessons I learned the hard way:
● Never skip pagination - you'll regret…
👍1🔥1
https://arktype.io/ ishlatib ko'ryapman, menga yoqyapti🙂
ArkType
TypeScript's 1:1 validator, optimized from editor to runtime