Along the way, I collected a pile of notes with, let's say, my best practices. Half of them learned the easy way (reading docs), half learned the hard way (staring at a CloudWatch, Grafana at 2am wondering why one partition is on fire while the rest of the table is bored).

This is the cleaned-up version of my notes. Just the things I actually needed to know. I assume if you are reading this, you are already familiar with the basic DynamoDB concepts, so we will not stop there.

eventual vs strong consistency

By default, DynamoDB gives you eventual consistency. You write, and a moment later every replica has the update. Almost always fast enough, almost always correct enough, cheap too.

If “almost” isn’t good enough for you, there’s ConsistentRead: true. Add that to a GetItem, Query, or Scan (!! do not use Scan on production, it is bad, it is expensive), and DynamoDB routes your read through the primary replica that’s guaranteed to have every successful write applied. You get the freshest possible data.

Of course, it costs more to you. Literally, double the RCUs, and it can be slower because there’s coordination happening across nodes instead of just reading whatever replica is closest. And it’s not available everywhere. Base tables and LSIs support it, GSIs don’t. If your access pattern needs strong consistency, that alone might decide whether you reach for an LSI or a GSI.

My rule of thumb: default to eventual, and only reach for strong consistency when the alternative is a genuinely bad user experience.

LSI vs GSI

This is the one that trips people up the most, because on paper LSIs and GSIs look like siblings. In practice they behave very differently, and one of them is way less forgiving.

LSI (Local Secondary Index)

• Same partition key as the base table, different sort key. That’s the whole point. It lets you resort items within a partition to support another data access pattern.

• Can be strongly consistent. GSIs can never do this, at least now (July 2026).

• Must be created at table creation time. You cannot bolt one on later, and you cannot delete one once it exists. Get this wrong on day one and you’re rebuilding the table.

• Shares the base table’s provisioned throughput. No separate capacity to manage, but also no isolation. A hot LSI can starve your base table.

• Everything sharing a partition key (the “item collection”) is capped at 10GB total, across the base table and all its LSIs combined. This is easy to forget until you hit it.

GSI (Global Secondary Index)

• Independent partition key and sort key. You can query across the entire table, not just within a partition.

• Add or remove them whenever you want.

• Own provisioned throughput, separate from the base table.

• Eventually consistent only.

So the real decision isn’t “which is more powerful”. GSIs almost always win on flexibility. If you’re not 100% sure, use a GSI. You can always add another one next sprint. You can’t undo an LSI.

partition keys

DynamoDB spreads your data across partitions based on the hash of your partition key. If your key distributes evenly, life is good. Throughput scales roughly linearly and nothing gets hot. If it doesn’t, one partition eats all the traffic while its neighbors sit idle, and you throttle even though your table-level metrics look fine.

So, always aim for a pattern where your partition key is random enough and spreads writes/reads across shards (e.g., based on a random user_id, order_id, or a combination of the two).

DynamoDB does have your back to some extent. Adaptive capacity automatically borrows RCUs/WCUs from cooler partitions to help a temporarily hot one. It’s a real safety net, not marketing copy. But adaptive capacity is for temporary hot spots. If one key is permanently the busiest thing in your system (think: one massive celebrity user), no amount of borrowing saves you. You need a synthetic key strategy, like sharding that one key into KEY#0 through KEY#9 and fanning reads back out on the query side.

TTL

Set an expiry timestamp attribute on an item, and DynamoDB will delete it for you once it passes. You don't need a cron job or a batch cleanup script. No cost of storing temporary state forever. If you've got Streams enabled, those TTL deletions still show up in the stream. Just note the retention is a fixed 24 hours, not configurable so you can react to expirations just like any other write. If you need to hold onto that history longer, Kinesis Data Streams for DynamoDB is a separate, opt-in option that lets you configure retention anywhere from 24 hours up to 365 days.

the limits that will eventually find you

A few numbers worth knowing:

• 400KB per item hard cap. There are no exceptions.

• ~10GB per partition, and DynamoDB just keeps adding partitions as you grow. There is no upper bound on total table size.

• 3,000 RCUs or 1,000 WCUs per partition per second (that’s reads of 4KB and writes of 1KB as the unit). Blow past this on a single partition and you’re throttled and retrying, regardless of how much capacity the table as a whole has.

That last one is the sneaky part. Your table-level provisioned or on-demand capacity can look enormous, but if all your traffic funnels into one partition key, you’ll hit that per-partition ceiling long before you hit the table’s.

what it actually costs

Roughly (and prices drift per AWS region, so treat this as a mental model, not an invoice):

• ~$1 per million WCUs

• ~$0.25 per million RCUs

• ~$0.25/GB-month for storage

Reads are cheap, writes are the expensive lever, and storage is basically a rounding error unless you’re hoarding data you should’ve TTL’d away.

single-table design

This is the part that feels wrong the first time you do it and then feels obvious forever after. Instead of one table per entity type, you throw everything users, orders, conversations, whatever into one table, and you model your access patterns through the keys themselves.

The pattern that’s served me well:

• Use boring, generic attribute names: PK, SK, GSI1PK, GSI1SK etc. The table shouldn’t know or care that it’s storing “orders”. The semantics live in the values, not the schema.

• Encode meaning into the key strings themselves. Something like:
  PK = U#<USER_ID>
  SK = C#<CHAT_ID> assuming that chat_id is a UUIDv7. Because UUIDv7 is time-ordered, sorting by chat_id gives us chronological ordering by creation time.
  GSI1PK = O#<USER_ID>#<ORDER_ID>

• Now a single table can answer “give me this user’s chats” and “give me this order’s chats” without needing separate tables or a join because there is no join in DynamoDB, and pretending otherwise is how people end up fighting the database instead of using it.

• Lean on sort-key ordering. The sort key isn’t just a filter. It physically determines how items are laid out within a partition. That means clever SK design gives you cheap, efficient pagination almost for free, instead of bolting on offset-based pagination that gets slower the deeper you go.

The mental shift is: stop designing your table around your entities, and start designing it around your queries/access patterns. Write down every access pattern first. The keys fall out of that list, not the other way around.

summary

Default to eventual consistency, reach for strong only when staleness actually breaks something. Use GSIs unless you specifically need LSI’s strong-consistency guarantee, because LSIs are permanent decisions. Design your partition key for even distribution before you design anything else. Let Streams and TTL do the event-driven and cleanup work for you instead of writing it yourself. And when you’re modeling the table, design around your access patterns, not your entities.

Nothing here is exotic. It’s just the stuff that only really sinks in after your first throttling incident.

If this was useful, send it to someone prepping for a system design interview or learning databases. Drop your own rules in the comments. Curious what I’m missing.

Thanks for reading,
Adlet Balzhanov

Connect with me on LinkedIn, just use the button below. I read every message. Cheers!

My LinkedIn

Rule 1 – System design is all tradeoffs. There’s no perfect choice, just better or worse ones.

Rule 2 – Good design starts with the right questions:

• Read-heavy system or write-heavy?

• What guarantees do we actually need? (e.g. exactly-once execution within 24h?)

• How fresh does the data need to be? Is replication lag acceptable?

• Steady traffic or bursty?

• What’s the recovery expectation when things go wrong?

• Do we need to keep the data forever?

Rule 3 – Environment matters. Before your interview, ask your recruiter which whiteboard tool they are using and spend time in it beforehand. Fumbling with the UI is unnecessary cognitive load on top of an already hard problem.

Rule 4 – Before listing your non-functional requirements, ask about scale. It’ll shape everything.

Rule 5 – When thinking about storage, always walk through the spectrum where to store the data: server in-memory → Redis → persistent DB → blob storage (S3). Run the numbers based on your non-functional requirements list.

Rule 6 – Durability isn’t just “3 replicas.” You also need to verify each copy is actually correct (e.g. checksums with SHA-256).

Rule 7 – Start simple. OpenAI scaled ChatGPT to 800M monthly users on Postgres: 1 primary, 50 read replicas. The moment you cross a network boundary, latency gets real, partial failures become possible, retries get dangerous.

Rule 8 – Don’t ignore the client side. Batching, chunking, compression. This stuff meaningfully cuts backend load and improves scalability.

Rule 9 – Some processes can't be atomic. Payments are the clearest example. Authorization, capture, settlement, refund, dispute. Each step can fail independently and may need retries or compensation. That’s the Saga pattern and why tools like Temporal exist.

Rule 10 – Read path: optimize for speed. Write path: optimize for correctness.

If this was useful, send it to someone prepping for a system design interview. Drop your own rules in the comments. Curious what I’m missing.

Thanks for reading,
Adlet Balzhanov

Connect with me on LinkedIn, just use the button below. I read every message. Cheers!

My LinkedIn

You start at the bottom, improve your skills, work harder than everyone else, and slowly climb upward through merit. The assumption underneath most career advice is: become exceptional enough, and the system will eventually recognize you.

But in technology, careers are often shaped less by individual talent than by the speed of the system around you.

A growing company is not a ladder.

It is an escalator.

A few years ago, I watched an engineer become a Director of Engineering at a company worth over $10 billion before turning 27.

This week’s newsletter is sponsored by one of the fastest-growing GenAI video companies Higgsfield AI.

While coding agents transformed software engineering, Higgsfield is doing the same for filmmaking, marketing, and content production with Supercomputer — a long-running creative agent capable of generating entire campaigns, films, and viral media systems autonomously.

The scale already looks unreal:

• $300M annualized revenue run rate

• 24M users across 240+ countries

• 750M+ videos and images generated

• 6M generations per day

• 5B+ social reach through (Instagram: higgsfield.ai)

• Fortune 500 customers

• $5M+ paid directly to creators

Higgsfield’s proprietary harness combines persistent memory, multi-agent orchestration, parallel execution, co-located GPU infrastructure, and frontier video models including Veo, Kling, GPT Image 2, Seedance 2.0, and their own Soul Cinematic stack.

The proof is already here: an 80-minute AI-generated feature film premiering at Cannes.

They’re hiring engineers, researchers, designers, and operators to build the frontier of creative AI:

Higgsfield Careers

Thanks to Higgsfield AI for sponsoring, let’s get back to this week’s thought!

Well,

A few years ago, I watched an engineer become a Director of Engineering at a company worth over $10 billion before turning 27.

They were good, smart, reliable, technically sharp. But not extraordinary in the way the industry romanticizes. They were not publishing breakthrough papers or reinventing distributed systems. Nobody would have described them as the best engineer in the building.

They joined at the right moment.

When they arrived, the company was small enough that everyone still fit into a single all-hands meeting. Four years later, the company had thousands of employees, multiple offices, and management layers that did not exist when they joined.

The company needed leaders faster than the market could produce them.

So it promoted the people who were already there.

At the same time, I knew engineers at large prestigious companies who were to be honest far more capable. People with frightening technical depth. Engineers who could debug impossible failures, reason across enormous distributed systems, and make hard problems look routine.

Many of them barely moved. I mean, of course, they became Senior/Staff engineers or Engineering Managers but …

This sounds unfair until you understand the mechanism.

In slow-growing companies, promotions become scarce resources. For one person to rise, another often has to move aside. Managers defend headcount because headcount becomes status, influence, and survival.

The organization stops expanding outward.

So ambition turns inward.

That is why Big Tech companies become political even when the people inside them are reasonable. Scarcity changes behavior. When organizations stop creating opportunity organically, employees begin competing over the existing supply instead.

Over time, the company starts rewarding people who are most legible to the system rather than most useful to it. Engineers optimize for visibility instead of velocity. Meetings become more important. Narrative becomes more important. Over-alignment becomes more important. Keeping every cross team in the loop becomes more important.

No no no … People there are not vicious by design or irrational.

Just growth changes the geometry entirely.

When a company doubles every year, bureaucracy cannot stabilize fast enough to defend itself. Entire teams must be created before experienced managers exist to run them. Leadership gaps appear everywhere simultaneously. The organization becomes structurally incapable of preserving old hierarchies because reality is changing faster than hierarchy can adapt.

This creates one of the strangest dynamics in technology:

Fast-growing companies often accelerate careers faster than competence itself develops.

Engineers dislike admitting this because engineering culture is deeply attached to meritocracy. We want outcomes to feel proportional to skill. Write better code, think more clearly, make better decisions, and eventually the market should reward you fairly.

Sometimes it does.

But markets reward leverage more consistently than virtue.

And growth is leverage.

The difference is that high-growth environments continuously manufacture new surface area for ambition.

Big corp environments manufacture competition over existing surface area.

Most people in technology underestimate how much this single variable shapes careers. They optimize for prestige, compensation, or technical purity while ignoring whether the system around them is expanding fast enough to create opportunity faster than bureaucracy can contain it.

This does not mean growth is everything. Hypergrowth also creates inflated titles, fragile leaders, and people who mistake organizational momentum for personal greatness. Some only discover this after the escalator stops moving.

But even this reinforces the same principle.

Systems shape outcomes more powerfully than individuals want to admit.

The most important question in your career may not be:

“Am I working hard enough?”

It may be:

“Is the floor beneath me moving?”

If you found this helpful, please like or share it with a friend and consider subscribing if you haven’t already.

Thanks for reading,
Adlet Balzhanov

Connect with me on LinkedIn, just use the button below. I read every message. Cheers!

My LinkedIn

And then we sit down to write.

The document fills up quickly. A few hedges, a few qualifiers, a sentence that sounds professional but doesn’t quite say anything. You’ve probably written something like:

We might want to consider potentially optimizing the query performance in some cases.

What it usually means is:

This query is slow.

Somewhere along the way, the point gets diluted because writing doesn’t feel as strict as code. It should. The same instincts apply.

Zinsser’s argument in On Writing Well is straightforward: most writing is cluttered. It carries more than it needs to. Words accumulate the way unused code does. Nothing breaks, but everything becomes harder to follow.

The fix is well known to engineers. Remove what doesn’t contribute.

You can see it in small edits:

The system is, in a sense, experiencing a bit of a latency issue.

becomes

The system is experiencing latency.

Nothing important was lost. It just stopped making the reader work.

But editing only gets you so far. Most of the time, unclear writing points to unclear thinking. The page is just where that shows up.

This is especially obvious in design docs. You’ll read an explanation that sounds reasonable, but doesn’t quite hold your attention:

This solution provides better scalability and flexibility for future use cases.

It’s hard to argue with, but it’s also hard to evaluate.

Compare that to:

We chose this because write throughput is our bottleneck, and this reduces write amplification by 40%.

Now the reader has something concrete to react to. The difference is clarity of thought.

One habit that helps more than expected is reading your work out loud. On the screen, a sentence can look fine. When you hear it, the problems stand out. You notice where it drags or repeats itself, where it feels longer than it needs to be. If you run out of breath halfway through, the sentence is probably doing too much.

It also exposes tone. Sentences that sounded polished can come across as distant or mechanical. Good writing doesn’t need to sound casual, but it should sound like something a person could actually say.

Precision helps here. Weak verbs tend to hide what’s really happening:

The script quickly ran through the data and made improvements.

That leaves a lot open.

The script processed the data and reduced errors by 18%.

Now the action is clear, and the outcome is measurable.

You don’t need to invent a new style each time you write. Just like in code, there are patterns that already work. If you’ve read something that held your attention, it’s worth looking at how it was put together, how it moves from one idea to the next, how it avoids losing momentum.

What matters more is resisting the drift toward vague, overly careful language. It shows up most clearly in post-mortems:

An issue was encountered where the system experienced a degradation in performance.

It’s technically fine, but it keeps the reader at a distance.

The system slowed down.

Shorter, but also clearer and more direct.

Vague writing is rarely accidental. It’s often a way of avoiding a clear statement when the clear statement would be uncomfortable.

That’s really the thread running through all of this. Say what happened. Say what you mean. Remove what doesn’t help.

Good code does this without drawing attention to itself. You read it and understand the system without effort. Good writing works the same way. When it’s doing its job, you don’t notice the sentences. You follow the idea.

The reader can always tell when the writer did the hard thinking, and when they didn’t.

If you already care about clean code, the instinct is there.

Apply it to your writing.

If you found this helpful, please like or share it with a friend and consider subscribing if you haven’t already.

Thanks for reading,
Adlet Balzhanov

Connect with me on LinkedIn, just use the button below. I read every message. Cheers!

My LinkedIn

When the SQL vs. NoSQL question comes up, that’s how you avoid sounding like you’re quoting a 2015 blog post.

The SQL vs NoSQL debate still shows up in interviews like it is some deep philosophical divide. It is not. Most mainstream databases today all can handle serious traffic, flexible schemas, transactions, replication, all of it. The hard part is living with the consequences of your choice for the next five years.

I have watched teams blame “scale” for issues that were just bad access patterns. Full table scans in hot paths. No indexes on fields that get hammered every second. Migrations run in the middle of peak traffic because nobody thought through locking behavior. Then someone says maybe we need a new database.

Swapping the engine does not magically fix weak thinking. It just gives you a new set of sharp edges.

The better answers start with workload. What are you actually doing every day? Reading rows by primary key with strict consistency because money is involved? Relational databases are very good at that. Writing massive append-only events where a little staleness does not hurt anyone? There are tools that lean into that pattern. Running complex joins across entities with evolving business logic? SQL is still ridiculously effective.

The difference is not in the tool list. It is in whether you can explain the failure modes without hand-waving.

What happens when replication lag spikes and your checkout flow reads stale data? What happens when a schema migration needs to backfill hundreds of millions of rows and your I/O graph looks like a heart attack? What happens when the one engineer who understands your distributed consensus setup leaves the company?

I have seen small teams pick distributed databases because they want to look “future proof.” What they get instead is more moving parts, more cognitive load, and longer onboarding. Engineers avoid touching the data layer because it feels risky. Features take longer. Roadmaps stretch. The database did not limit them. The complexity did.

On the other hand, I have seen teams run a single relational database far longer than outsiders thought reasonable. They invested in modeling. They added the right indexes. They understood isolation levels and locking. When they finally hit real limits, it was obvious and measurable, not hypothetical. That is when adding something specialized made sense.

Most scaling problems are modeling problems wearing a database costume.

Being boring with infrastructure is often the grown-up move. If your biggest uncertainty is product direction, you do not need distributed consensus in your life. You need clarity. Every extra datastore is another thing that can wake someone up at 2 a.m. and another system a new hire has to mentally parse.

When senior engineers ask about SQL vs NoSQL, they are not testing trivia. They are checking whether you understand tradeoffs in a way that connects to business risk and team capacity. They want to hear that you know what breaks, who gets paged, and how much that pain costs.

Modern databases are all good enough. The real differentiator is whether your thinking is sharp enough to match the workload and honest enough to admit when simple is the right call.

Show that you can think beyond the “NoSQL for scale, SQL for transactions” mindset.

If you found this helpful, please like or share it with a friend and consider subscribing if you haven’t already.

Thanks for reading,
Adlet Balzhanov

Connect with me on LinkedIn, just use the button below. I read every message. Cheers!

My LinkedIn

The "Now What?" trap

Many engineers very early in their careers think they should become Engineering Managers at any cost. They take on any task or do any favor just to get this role. Meanwhile, along the way, they don’t even think about questions like: “What is a day in the life of an Engineering Manager like?”, “Am I okay with having eight different 30-minute meetings each day?”, “Do I prefer focusing more on technology or on people?”

Moving into an Engineering Manager role from an individual contributor position is not a promotion, believe me, it’s a career change. Whether you get it at 25, 30, or 35 years old doesn’t matter. You still have a career ahead of you until 60, let’s say.

Invest in Life Outside of Work

Fulfillment comes from relationships and community, not just career progression. I would apply the same effort to life progression (hobbies, friendships, romantic relationships etc) as professional roadmaps and goals. I would definitely summarize this by saying that getting along with someone at a younger age is much easier than later in life.

Ride the "Escalator" of High Growth

Prefer roles in fast growing companies where the “ladder” acts like an escalator. Even if you do the same work, the escalator will carry you upward and lead to promotions and salary increases. Because the company is growing, it needs to create new roles and promote people. You don’t need to climb the ladder by investing heavily in politics.

Don’t Be the Best, Be the Only

Many engineers focus too deeply on a single programming language/framework/technology memorizing documentation and following every tweet related to that specific skill. Yes, if you go deep enough, even down to the internals, you can become highly valuable in that area. However, I would always choose to be a unique combination of abilities. Say, 30% data structures, 40% invested in getting to know the people in your organization, 20% database internals, 10% writing skills, and so on.

In short, early career decisions don’t need to be rushed or optimized for titles alone. Treat your career as a long game: choose growth environments, build a life outside of work, and be intentional about what kind of work actually energizes you.

If you found this helpful, please like or share it with a friend and consider subscribing if you haven’t already.

Thanks for reading,
Adlet Balzhanov

Connect with me on LinkedIn, just use the button below. I read every message. Cheers!

My LinkedIn

Prefacing with “This might be a dumb question…”, it immediately disarms the room. The person responding to you gets a clean ego boost, a chance to explain something they know well. People love that. Far from thinking you’re dumb, they walk away feeling a little smarter for having answered you. You get the answer, they get the high. That is pure upside.

Plenty of times I’ve seen this play out. The person asking the so-called “rookie” question never loses status. The trick works because it satisfies the quiet tension that lives in most rooms. People want to help, but they also want to feel important. Give them the opportunity to feel both.

There’s a pattern I’ve noticed across senior engineers, sharp operators, and good PMs: the best ones ask questions that sound simple. They do it with full awareness because they know exactly how it lands.

Some people think asking questions is a vulnerability. It isn’t. It is an invitation for others to perform intelligence in front of you. That is how you build social capital. You are giving someone a small, controlled stage. You are saying, without saying it: go ahead, teach me something. Most people cannot resist that offer.

The language matters. When you frame it as “Sorry if this is a dumb/rookie question, but…” question, you trigger a protective reflex. The responder will almost always correct you: “It’s not a dumb question…” What they’re really saying is, you’re fine I got this. They feel helpful and competent. And now they like you a little more. You made them feel good in front of other smart people. Well, that’s a career skill.

Tech is full of people who are allergic to ego on the surface but still desperately want to feel useful and sharp. Feed that desire in a way that costs you nothing. You do not look smaller for doing it.

The risk of not asking is higher than the risk of asking. The right one, framed with humility, can make the person next to you feel brilliant. And that’s the kind of person people want in the room again.

So the next time you hesitate, say it anyway: “Sorry if this is a dumb/rookie question…” Watch what happens.

Thanks for reading,
Adlet Balzhanov

Connect with me on LinkedIn, just use the button below. I read every message. Cheers!

My LinkedIn

In many tech companies, “Senior Engineer” is almost a dead-end title. The problem is that after you hit that level, there may be no obvious path ahead or minimal reward (e.g. 10% salary increase, 100% more responsibility for Staff+). More responsibility lands on your desk but the salary bump looks like a rounding error.

Over time a routine sets in. You can still build features and fix bugs, but the creative excitement is gone. This isn’t classic burnout, it’s boredom. If burnout is an all-nighter run on empty, boredom is driving a familiar road you’ve traveled a thousand times.

Seek New Challenges (New Companies)

So what do you do? One obvious move is to inject novelty into your routine by interviewing at companies you think you can’t get into. FAANG, a top trading, whatever feels scary. Doing that forces you to refresh and extend your skills, often faster than any project at your day job. Even failing is fuel. You come back sharper and hungrier. Suddenly that curveball design question reminds you why coding was fun, and a few intense prep sessions can make even routine tasks feel like puzzles again.

Change Your Role

Another tactic is to side-step the routine instead of head-butting it. Talk to your boss about trying something new. For example, move into a engineering manager role. Then your focus shifts from writing code to coordinating teams, and that fresh viewpoint can feel unexpectedly alive. You could even try a product or dev-rel role. Those switches remind you that the industry is bigger than one codebase.

Start a Side Project

Lastly, engineer your own spark outside 9-to-5 hours. Start a side project, a blog, an app, even an open-source library. Yes, it’s extra work, but it’s on your terms. When you code for something you care about, the job’s drudgery turns back into discovery, and many devs report that weekend projects or blogging rekindle the craft inside them. These passion projects often change how you see the day job. Suddenly those office tasks fit into a bigger picture you care about. At the very least, you’ll pick up new skills and meet interesting people. Often both. While remembering why you loved building things in the first place.

The Bottom Line

All of this boils down to one insight. Tech careers aren’t conveyor belts. Nobody is going to gift you a promotion just because you’ve been patient. If you’re stale, it’s on you to inject change, the industry won’t do it for you.

If you liked this post, hit the like button. It’s the best feedback I could get. Share other ways in the comments to escape the tech burnout trap.

Thanks for reading,
Adlet

Connect with me on LinkedIn, just use the button below. I read every message. Cheers!

My LinkedIn

I’ve seen that what sounds casual often has more payoff than a formal presentation. Eating with people from other departments shows you what is really happening inside the company. New projects, hidden problems, and the stories that never reach Slack. During lunch I have observed that people rarely share the same metrics they track at work. That knowledge is currency. Over time, you become the person who connects the dots between groups, and people notice that.

This isn’t about pretending to be a social butterfly. Shared meals build trust over time. A few questions about someone’s weekend can turn into offers to help or collaborate months later. Leadership often reaches for names they already know when a new initiative or role opens up. If you’ve been in those lunchtime conversations, you’re on the shortlist. How? By being present in others lives.

Over the years, I’ve observed a pattern, people who bring others into the loop are often the ones with looped-in opportunities. You might share a lunch taco with someone and later find yourselves helping each other fix a bug or pitching in on a cross-team sprint. These small gestures, grabbing sandwich with someone from marketing or ops, make you visible in ways formal updates never do.

There’s a deeper lesson — real connections grow from genuine curiosity. When you ask questions at lunch, you learn what drives your peers, not what their job title is. Those conversations often turn into the trust currency of any org. People remember who asked about their weekend or who offered a solution during crunch week. By doing this habitually, you become known as someone who understands more than your own code. You become that connector with a clear line of sight across the org chart.

The writing on the wall is clear, careers don’t grow in isolation. They grow when you build bridges. Sometimes over a plate of sushi at midday. And that small social investment delivers a huge ROI. Informal lunches might feel like a break, but they can deliver your next big break.

Take the pattern to its logical conclusion. Schedule a lunch with someone you do not yet know, one day a month. Treat it as an experiment in curiosity. The payoff is a network of allies who will remember the gesture long after you leave that table.

If you liked this post, hit the like button. It’s the best feedback I could get.

Until next time,
Adlet

Connect with me on LinkedIn, just use the button below. I read every message. Cheers!

My LinkedIn

I've watched this play out across dozens of teams. The engineer who asks questions first in meetings, or says "I can handle it", usually gets promoted. They become the person other engineers turn to when something breaks.

Meanwhile, the super smart engineer stays quiet in meetings. They think about problems and spot three edge cases that might go wrong. They're right about the edge cases. But by the time they formulated concerns, the confident engineer has already started coding.

This happens because confidence signals competence in ways that actual competence doesn't. When your staff engineer says "I'll check it" right away, it shows they can handle it, even if they are googling all things up. When your smart junior says "I’m not sure if this is right", it sounds unsure, even if their solution is actually good.

The confident engineer understands a key: being 80% right with 95% confidence beats being 95% right with 80% confidence. They make architectural choices that move the team forward, even if it's not perfect. They understand that in most cases, the cost of delay exceeds the cost of imperfection.

I've seen this dynamic destroy careers. The engineer can solve any coding puzzle. But they take three days to review a pull request because they think about every possible improvement. The senior developer writes careful, great code. But they never try to lead because they don’t feel ready. The architect spots every problem in every design. But they have trouble suggesting fixes because they are never happy with their own ideas.

The tragedy isn't that these engineers lack talent. It's that they've optimized for being right instead of being effective. They've confused perfectionism with professionalism.

The confident engineer has learned a different lesson. They understand that most technical solutions are reversible. Most code can be refactored, and most mistakes can be fixed. They know that making progress is more important than being perfect. This is true especially when things change every week and the product can change every few months.

This doesn't mean confidence excuses incompetence. The engineer who confidently ships broken code won't last long. But there's a sweet spot where average skills combined with high confidence creates outsized impact. These engineers keep the team together. They say "yes, we can build that" while others explain why it is hard.

The market rewards this combination because shipping is the ultimate skill. Companies don't pay engineers to write perfect code. They pay them to solve problems, make decisions, and move products forward. The engineer who can do this confidently, even imperfectly, creates more value than the engineer who can do it perfectly but slowly.

I've learned to hire for this quality as much as technical skill. The knowledge gap closes with time and mentorship. The confidence gap rarely closes on its own.

If you liked this post, hit the like button. It's the best feedback I could get.

Until next time,
Adlet

Connect with me on LinkedIn, just use the button below. I read every message. Cheers!

My LinkedIn

Two years later, I gave a big talk to 300 engineers, got asked to speak at three more events, and got a promotion because my bosses thought I could be a leader. Same brain, different outcome. I learned a simple rule: Success = (number of attempts) × (probability of success each time).

Most engineers obsess over the second variable. We practice coding problems, learn how to design big systems, and make our GitHub pages look cool. We act like every chance is an uni exam, and if we’re not perfect, we think we failed. But here's what nobody tells you: the first variable matters more.

After that first disaster, I spoke at ten more events over eighteen months. Company lunch-and-learns where I fumbled through slides about API design. Lightning talks at conferences where I rushed through my conclusions. Panel discussions where I said "um" more than actual words. However, I learned that confidence isn’t about being perfect one time. It's about being brave enough, often enough, until the math works in your favor.

The breakthrough came during talk number ten. I was presenting about incident response at a SRE meetup when someone asked how we handled our worst outage. Instead of deflecting or giving a sanitized answer, I told the real story. The panic, the wrong assumptions, the moment we realized our monitoring was lying to us. People laughed. Someone approached me afterward saying it was the most honest post-mortem they ever heard.

That vulnerability taught me more about talking to people than any teacher ever could. The speaking opportunities that followed weren't about technical expertise anymore. They were about connecting with other engineers who lived through the same chaos and wanted someone to acknowledge it out loud.

The tech world makes us believe there’s a perfect engineer who always passes interviews, and gets promoted because they’re super smart. Reality looks messier. The engineers who thrive aren't the ones who never fail. They're the ones who fail forward, fast and often.

I’ve seen smart engineers get stuck because they wait for the perfect chance, project, or moment to go for a promotion. Meanwhile, their not-as-smart coworkers get ahead by trying more things, asking for help, and making more projects. Not better projects. More projects.

The math is unforgiving but fair. If you have a ten percent chance of success on any given attempt, you need to make ten attempts to expect one success. But most people make two attempts, fail twice, and conclude they're not cut out for whatever they were trying to do. They optimize for the wrong variable.

This isn't about seeking out embarrassment or treating every stage like amateur hour. Each attempt should be genuine, thoughtful, and a little better than the last. But the emphasis belongs on "each attempt". Perfect is the enemy of prolific.

Now, when engineers say they want people to notice their skills, I don’t tell them to wait for the perfect talk or the best conference. I tell them to sign up for any meetup happening this month. Then sign up for another one next month. Keep speaking until their voice finds its power.

The math that actually matters isn't the complexity of your algorithms. It's how many times you're willing to run the program.

And again: Success = (number of attempts) × (probability of success each time).

If you liked this post, hit the like button. It's the best feedback I could get.

Until next time,
Adlet

Connect with me on LinkedIn, just use the button below. I read every message. Cheers!

My LinkedIn

At Skyscanner, he explains how choosing between management and the staff IC path comes down to where you get your energy, enabling people vs. scaling through technical leverage. He shares how rebuilding an underperforming personalization team led to their first big win in years, proving leadership is often about people, not tech.

But enough from me. Here are Jose’s answers from our conversation.

1) If you’re a Senior Individual Contributor deciding between pursuing a Staff path or moving into management, how do you recommend making that choice? How did you personally recognize which path was right for you?

For me, the choice between management and the staff or principal path comes down to what gives you energy. You cannot really do both.

If you go into management, your impact shifts away from coding and more into coordination, planning, and people development. You still need to understand the technical details, but you will not be in every pull request or every brainstorm. You also stop getting the same kind of feedback you used to as an individual contributor, but, you don’t miss it. You actually feel proud when your direct reports get strong feedback, because you know you have created the conditions for them to thrive.

Another part is growth. A promotion or lateral move does not just happen. It takes months of planning and shaping opportunities. You are not doing the work yourself, but you are guiding the narrative, and when it comes together it is incredibly rewarding to know you played even a small part in someone’s journey.

On the principal IC side, the impact looks very different. You are solving higher-level technical problems, setting architecture, unblocking teams. You might design a framework that entire departments depend on, or connect the dots across multiple squads. You do not always carry things through to the end, but you know your judgment is multiplying other people’s work.

Of course, you give things up. You are not embedded in a single team anymore, and you may miss the satisfaction of building side by side and shipping something directly. But what you gain is that ripple effect: knowing your technical decisions shape dozens of projects, and that without you, whole streams of work might stall. That is the kind of impact that makes the principal role rewarding.

2) How do promotions typically work for engineering managers (e.g. M1 -> M2, M2 -> M3)? Is it valuable to explicitly express your aspiration to advance to your manager like in IC roles?

At Skyscanner, we do not really label roles as M1, M2, M3, but there are equivalents. For data science, it is more like Manager → Senior Manager → Director. Beyond that, Senior Director and VP levels do exist, but they are rare in smaller disciplines like ours (we are around 60 data scientists in total).

The general pattern is the same though: scope and complexity increase with each step. A manager leads a single team, focusing on delivery, hiring, and wellbeing. A senior manager oversees multiple teams or managers, and spends more time on cross-team alignment and stakeholder relationships. A director is operating at an org level, shaping strategy across domains.

What is unique in our discipline is how you get there. All of our data science managers started as individual contributors. You had to be an excellent IC before moving into management. But that transition can feel strange at first because, where you were a strong individual contributor, now you are suddenly a junior again in management, relearning a whole new skill set.

It is also rare that we hire managers externally. Culture is very important at Skyscanner, and managers set the culture for their teams. Get that wrong, and the whole group can suffer. By moving people internally, we have much higher confidence the culture will remain strong.

Finally, timing matters. For someone to move into management, there first needs to be a spot — either an existing vacancy or a new team being built in the next 6 to 12 months. Then it can happen in 2 ways: sometimes individuals raise their hand, other times existing managers spot potential leaders and start conversations to explore willingness and fit.

3) Describe a difficult people-management case. How did you diagnose root causes, what actions did you take (including HR involvement), and what were the measurable results?

One of the toughest situations I faced was when I was asked to support and step-in our Hotels Personalisation team. The team had not shipped a successful model in more than a year, and credibility with stakeholders was very low.

When I audited the team, the biggest issues were on the people side. The manager was not really managing (no structured one-to-ones, no planning, no stakeholder relationships). The senior data scientist was technically brilliant — she could build PyTorch models in her sleep — but she could not diagnose what problem needed solving. She was solving the wrong things, and that meant we were never going to win.

The outcome was painful but clear. After aligning with my director, we made the call to rebuild the team. We let the existing group go and brought in new hires internally who could both lead and focus on the right problems. At the same time, we simplified the technical system to give them a clean foundation.

6 months later, that rebuilt team shipped the first big win in hotel ranking in years. The lesson for me was that sometimes it is not about technical. And as a manager, you need to recognise when the people you have are simply not a fit for the challenge in front of them.

4) With AI tools making it easy to solve Leetcode-style problems, how do you see technical interviews evolving at Skyscanner?

At Skyscanner we actually do not use Leetcode-style problems for data science roles. What we do instead is much more about testing how people think.

The first stage is usually a short technical screen in Python or SQL. But the goal is not syntax. The idea is seeing how candidates translate a question into code, even if it is pseudo-code. We want to see reasoning, not memorisation.

The second step is a business case. We pick a problem we have solved before, so we know the trade-offs and decisions involved. What we look for is whether they naturally ask the right questions, form reasonable hypotheses, think about feature importance, and outline a plausible approach. Because we went through the real journey, it is easy to see who is thinking in the right direction.

We sometimes add an A/B testing case too. The interviewer plays the role of a product owner (often a deliberately difficult one) who pushes for bad testing decisions. The candidate’s job is to design the experiment properly, analyse results, and hold their ground. It tells us a lot about how they balance technical rigour with stakeholder pressure.

Could AI tools help with some of this? Maybe (or probably). We have seen people try. But it is usually obvious when someone is repeating what an AI told them instead of actually thinking through the problem in the room. In fact, generally, those who get everything right are treated suspiciously because we have seen great candidates not nailing every single question. Reasoning, communicating, and applying judgment is very hard to fake.

5) If you were starting your engineering career today, what would you focus on to build a strong foundation for long-term growth?

If I were starting my career today, I would still build the foundation in two layers: timeless fundamentals, and adaptability.

On the fundamentals side, I would still do something like Andrew Ng’s classic machine learning course: the basics of modelling and statistics have not gone away. But I would go further: I would deliberately put myself into data wrangling work. Volunteer for the ETL tasks, learn how to build a star schema database, debug data logs. Everyone wants to build models, but the reality is that without clean, reliable data, those models are useless. Being the person who understands both the data engineering and the modelling makes you indispensable.

On adaptability, I would take advantage of the fact that AI now lets you learn by doing at an incredible pace. Fifteen years ago it was much harder to build something end-to-end on your own. Now you can. So I would consume courses, but then I would immediately put them into practice: build dashboards, spin up an MLops pipeline, try a simple mobile app, train a deep learning model. The point is not to be perfect, it is to learn by building.

And finally, I would invest early in communication. The people who grow fastest are not just the best coders, but the ones who can explain trade-offs to stakeholders, collaborate across disciplines, and influence decisions. That combination of technical breadth, adaptability, and communication is what sets you up for long-term growth.

Thank you Jose for sharing these lessons!

If you found this post useful, let me know in the comments or with a like. It’s the best feedback I could get. I’ll keep bringing more industry leaders to my newsletter.

Until next time,
Adlet

Connect with me on LinkedIn, just use the button below. I read every message. Cheers!

My LinkedIn

Most of these messages are noise. But buried in them, once in a while, is a company that could be worth a real look. The problem is, the pitch is never the truth. Founders sell vision. Recruiters sell urgency. If you make a career move based on either, you are gambling blind.

The only way to cut through is to run your own checklist. Over time, I’ve built mine. It is not complicated, but it is sharp enough to filter 90% of the inbound messages I get.

The first number I check is revenue per employee. Ask the founder, or whoever reached out to you, for the revenue number. Divide their annual recurring revenue by the total headcount. If that number is below $150K, the company is either pre–product market fit or scaling too early. They will burn fast when the market tightens. If it is above $300K, there is enough efficiency to suggest real traction. Most engineers never ask this, but it tells you in one shot if the business model makes sense.

Then I check fundraising history on Crunchbase. Do not only look at valuation headlines. Look at the timing. Healthy companies raise every 12–24 months and grow into each round. If you see a raise only six months after the last, it usually means burn is out of control. If you see a gap of three years with no news, it means they struggled to get the next check. Both are red flags.

Next is investors. Look at their financial stability. Check the size of the fund. A small fund may not have the capital to support future rounds. Do they fund follow-on rounds, or abandon companies after the first check?

Equity is the hardest to diligence, but you can still push. Ask from the founders about the preferred share price in the last round. A clear answer means they respect you. A vague answer usually means liquidation preferences are so high that your common equity will be nearly worthless. Many engineers only discover this after years of work, when their “life-changing” grant turns into nothing.

I also check the team. LinkedIn makes it obvious. How long do engineers stay? Are the first ten hires still there? If you see a pattern of people leaving at the two-year mark, it usually means insiders see the ceiling. Early churn is the most honest signal you will get.

One more check most engineers ignore: customers. Look at engagement and retention. For B2B, ask how many top accounts renew, losing one big client can wipe out a large portion of revenue. For B2C, check usage and repeat behavior, high churn or low engagement signals trouble. Impressive logos or large user counts mean little if the business can’t retain them. Customers tell the truth long before TechCrunch does.

When you step back, the decision always comes down to three currencies: equity, ego, or exit. Equity is the bet that your shares will be worth something. Ego is the pull of being needed, building fast, feeling essential again. Exit is the freedom you hope to buy later. None of these is wrong. But you have to know which one you are choosing, or you will get burned.

I have seen smart engineers chase ego and call it equity. I have seen people join for equity only to discover they were last in line on the cap table. The failure is not choosing wrong, but not being honest about what you want or checking if the company can deliver it.

Every message in your inbox is asking for the same thing: your time, traded for risk. Your job is to make sure the numbers make the risk worth it. Revenue per employee. Fundraising pace. The investor behind the logo. The equity terms. The team’s behavior. The customers. That is the real checklist.

If those do not pass, nothing else matters.

If you liked this post, hit the like button. It's the best feedback I could get.

Until next time,
Adlet

Connect with me on LinkedIn, just use the button below. I read every message. Cheers!

My LinkedIn

In meetings, it’s easy for your ideas to get lost because people interrupt, ask “quick questions”, or talk over you. Being loud doesn’t mean you’re right. It means you spoke the loudest. The best engineers I know don’t rush to talk first or louder. They write first. A clear proposal doc or a well-timed Slack thread often does the heavy lifting that a meeting can’t.

When you write, you create something that sticks. It lives beyond the noise of a call. The doc, your words guide the team and stop confusion. Instead of fighting for air time, you’re influencing the direction from a different angle. One that scales far beyond the hour on the calendar.

Writing also scales your impact beyond GitHub commits. Your code fixes the problem now, but your writing helps people understand it later. When you write well, you multiply your influence. You become more than a coder, you become a force multiplier.

The ironic part is that writing clarifies your own thinking. I’ve spent hours stuck on a problem, but when I wrote about it, the answer became clear. Writing forces you to untangle your assumptions and makes contradictions stand out. If you can’t explain your design in writing, you don’t understand it yet.

This is why good writing is often a quiet form of leadership. You don’t have to dominate the room or interrupt to move things forward. Instead, you set the record straight in text, letting your ideas breathe and take root. Your writing becomes the single source of truth when the meeting ends and questions pile up.

Of course, many engineers tell themselves writing is not their job. “I’m a coder, not a writer,” is a phrase I once used. But real impact in tech requires more than shipping clean code. It demands aligning teams, reducing confusion, and building trust. None of which happen without clear communication.

The engineers who influence the most are often the ones who write the most. They write RFCs, proposals that stop extra work and get everyone to support the idea. Their influence lasts far beyond a meeting slot.

So next time you’re tempted to jump into the fray and shout louder, remember: writing is your quiet power. Write your ideas down, send the doc, share the proposal. That’s how you scale your voice. That’s how you make decisions happen without being in the room.

If you liked this post, hit the like button. It's the best feedback I could get.

Until next time,
Adlet

Connect with me on LinkedIn, just use the button below. I read every message. Cheers!

My LinkedIn

Soham worked more than 5 remote jobs at the same time. He was fooling half of Silicon Valley. So, how did he pull this off?

It all started with a cold email. He sent the same message to many companies, saying:

I love everything about what your company is doing. I don't have many hobbies outside coding. I am not athletic, bad at singing, don't drink, can't dance. Building is the only thing I am good at. Just want to be heads down chasing that goal.

This email intro was pure genius. Admitting he had no hobbies showed vulnerability. The self-deprecating humor made it relatable. The focus on work was sharp and clear. It triggered founders’ thoughts: “This is the dedicated engineer we need.”

Companies kept falling for it again and again. He aced every interview and got hired. Then, he started working many jobs without anyone knowing. For months, he collected salaries from several startups at the same time.

Then everything unraveled when Suhail called him out on X:

PSA: there’s a guy named Soham Parekh (in India) who works at 3-4 startups at the same time. He’s been preying on YC companies and more. Beware. I fired this guy in his first week and told him to stop lying / scamming people. He hasn’t stopped a year later. No more excuses.

That single tweet opened the floodgates. Founder after founder started sharing their Soham stories:

“We hired this guy a week ago. Fired him this morning.”
“Soham was our first engineering hire in 2022. We let him go.”
“This guy got a trial contract, then ghosted us after signing.”

The internet couldn't get enough. X exploded with Soham memes. The whole saga became a viral phenomenon.

Beyond the memes, the story revealed something serious. Soham’s scheme is eroding trust in remote work. Companies built on good faith now question every remote employee.

Soham isn’t alone. Overemployed subreddit has near 500,000 members. They share tips on working several remote jobs. They call it “overemployment” and treat it like a career strategy. Members exchange tactics to manage many bosses without getting caught.

The Soham phenomenon shows remote work creates new opportunities. But exploiting them can break vital trust. That trust is what makes remote work possible in the first place.

My take on this would be more conservative. Don't play the short game. Five salaries won’t matter when your reputation is radioactive. In tech, your name is your currency. Play long term.

Until next time,
Adlet

If you'd like to connect with me on LinkedIn, just use the button below. I read every message.

My LinkedIn

1. The Pragmatic Programmer — Timeless coding wisdom

Authors: Andy Hunt, Dave Thomas

I picked this up because every senior engineer I knew said, “You have to read it.” I expected it to be dry but it felt like two mentors sharing hard-won lessons over coffee (without fluff). Clear, practical advice, write code that’s easy to change, fix root causes, master your tools.

One idea that stuck: “Don’t live with broken windows.” Messy code only gets messier. So make sure to clean it up early. This isn't limited to software engineering, is it?

Another favorite: “Find bugs once.” If a human finds a bug, a human shouldn’t find this same bug again.

This isn't just a book, it's a whole mindset.

2. Thinking, Fast and Slow — Sharpen your decision-making

Author: Daniel Kahneman

This isn’t a tech book, but every engineer should read it. Daniel Kahneman explains how we think, how often we’re wrong without knowing it.

We use two systems: one fast and emotional, the other slow and logical. Knowing which is active? That’s powerful.

Before reading it, I often trusted my gut too much when debugging or designing. Afterward, I slowed down, asked better questions, and spotted my blind spots. It made me a better engineer and teammate. I listen more and admit when I might be wrong.

3. Designing Data-Intensive Applications — Master scalable systems

Author: Martin Kleppmann

I was reading this while working on backend-heavy projects. It felt dense at first, but Martin Kleppmann makes complex topics like distributed systems and databases easy to grasp. It’s not only about what works, but why and how things fail. Biggest takeaway? We often take infrastructure for granted. “Just scale it” isn’t so simple.

This book taught me to see the tradeoffs: consistency vs. availability, batch vs. stream, monolith vs. microservices. After reading it, I stopped thinking in features and started thinking in systems.

To sum it up briefly

If you’re an engineer and you’re feeling stuck or just want to sharpen the way you think, these three books might be what you need.

They don’t teach code. They change your perspective. And here’s the best part: you don’t need to read them all at once. Pick one. Take your time. Let it sit with you. Let it reprogram how you see the craft.

If you found this helpful, please like or share it with a friend and consider subscribing if you haven’t already.

Thanks for reading,
Adlet Balzhanov

Connect with me on LinkedIn, just use the button below. I read every message. Cheers!

Connect Now on LinkedIn

For example, in your day-to-day work, maybe they leave vague, passive-aggressive comments on your code reviews that make you question every career decision you’ve ever made. Or maybe they just love making everything more difficult than it needs to be.

I wish I could tell you that the workplace is full of rainbows and mutual respect, but that would be a lie. Instead, let’s talk about how to deal with these people in a way that keeps you sane, professional, and still on track for that promotion you deserve.

Advice 1: Look at the situation from a different angle

I know, I know. It’s easy to assume that a difficult coworker is just a terrible human being who wakes up every morning thinking of new ways to make your life miserable. But sometimes, it’s not personal. People have bad days. They have stress from things you don’t see. For instance, personal issues, or maybe they just spilled coffee all over their laptop right before a big presentation.

Before you decide that they’re out to get you, take a step back. Have they always been like this? If it’s the case, give them a little grace. You’d be surprised how many workplace “enemies” turn into allies once you see them as people first.

Advice 2: Do Not React Immediately

Ever wrote an angry email or message, only to regret it five minutes later? Yeah, me too. The next time you’re about to respond to a frustrating comment, take a break. Go grab a coffee, or just breathe for a minute. There are various quick ways to lower stress, such as doing sports, going for a run etc. Allow your emotions to cool down a bit to avoid making things worse for yourself.

Most of the time, the other person isn’t trying to attack you, they just have a different way of communicating. Some cultures value directness, while others emphasize politeness and diplomacy. What feels like rudeness to you might just be how they express themselves.

Advice 3: Adapt Your Communication Style

If you and your coworker are constantly clashing, it might be time to change the way you interact. If face-to-face conversations always end in frustration, try switching to email or messages, where you can carefully craft your words. On the flip side, if written messages feel too cold or aggressive, try having a real conversation instead.

One trick that works well in technical discussions is to avoid even-numbered debates. If you and this person always disagree, bring in a third party. With an odd number of voices, decisions become easier to reach because there’s always a majority. Simple but effective.

Advice 4: Keep Records (Just in Case)

If you’ve tried everything and things aren’t improving, start keeping a written record of your interactions. This is about having evidence if you ever need to escalate the issue.

Save emails, messages, and comments that highlight problematic behavior. If possible, get a neutral third party’s opinion to make sure you’re not overreacting. Sometimes, what feels like an attack is just a miscommunication, but if multiple people see the same problem, you know it’s not just you.

Advice 5: Know When to Walk Away

At the end of the day, some people are just toxic. Or they just don’t like you in any case. It happens. If you’ve tried every strategy and they’re still making your life miserable, it might be time to move on. That doesn’t necessarily mean quitting your job but maybe switching to another team or project.

No job is worth burning out over. You have decades ahead in your career, and trust me, you don’t want to spend them constantly fighting battles that drain your energy.

Conclusion

Handling difficult coworkers is part of the job, but it doesn’t have to consume you. At first, I found dealing with those assholes challenging, but over time, I realized that their pushback helped me grow. I became better because of it. The key is to stay adaptable, keep your emotions in check, and recognize when it’s time to step back. Whether it’s through perspective shifts, better communication, or strategic distancing, there are ways to protect your sanity while still being a team player.

By the way, sometimes HR can help, but what I often observe is that they mainly try to minimize damage on a larger scale and go to bureaucracy. They may also start a counter that you might be a conflict person.

And if all else fails? Remember this: some people are just difficult, and that’s their problem, not yours.

Thanks for reading,
Adlet Balzhanov

Connect with me on LinkedIn, just use the button below. I read every message. Cheers!

Connect Now on LinkedIn

1. Coding is important, but communication is everything.

You can write great code, but if you can't communicate, it won’t matter. Clear writing, clear thinking. This is how ideas spread and projects ship. Explain your work simply, document it well, and keep your team in sync.

Example:

Imagine you built an algorithm that’s 40% faster. Great. But if you can’t explain it clearly, no one will care. Impact only matters if others understand it.

Action Item:

• Practice explaining your work in a simple way. Try writing one short paragraph like you're talking to a 5th-grade friend. By the way, this will help you in job interviews as well. Clear answers matter more than fancy words. A friend once failed the LeetCode problem but got the job by explaining their project well.

• Be active in team discussions and retrospectives. Focus on being clear and concise.

2. Code reviews aren’t critiques. They’re conversations.

When I started, code reviews felt scary like people were only looking for mistakes. Now I see them as chances to learn and grow. Each comment helps me be a better engineer.

Action Item:

• Ask for specific feedback when submitting your code. For example, “I’m unsure about my error handling here. Thoughts?”

3. The best debugging tool is a break.

You know that feeling when you’ve been staring at a bug for hours, only to solve it in 10 seconds after stepping away? Yeah, that’s not a coincidence.

Example:

I spent entire afternoon on a bug which was a small mistake with a variable. A short coffee break helped me spot it fast. Sometimes stepping away solves more than staring at the screen.

Action Item:

• When stuck on a bug, set a timer for 30 minutes. If you’re still stuck when it rings, take a walk, grab a coffee, or do something non-technical before coming back.

4. One bug, one fix, one lesson.

Every bug is a learning opportunity whether in code or in life. When you encounter one, don’t just patch it. Ask yourself: How did this happen? What can I do to prevent it next time?

Example:

After fixing a production issue, I also improved logging, monitoring, and tests.
That way, we can catch problems earlier next time.

Action Item:

• After big bugs, review what went wrong. Use techniques like the Five Whys to find out why it happened. Write down the cause, the fix, and how to prevent it.

• Add a new test for each bug to stop it from happening again. One bug, one fix, one unit test.

5. Mistakes are part of the process.

No matter how experienced you become, bugs will still find their way into your code. That’s okay. Mistakes aren’t failures; they’re feedback.

Example:

A junior engineer deleted a column from the live database by mistake. We didn’t blame them but used this incident to add better safety checks.

Action Item:

• When you make a mistake, write down what happened, what you learned, and how you’ll do better next time.

• Encourage a blame-free culture on your team. Focus on solutions, not blame.

6. Don’t over-engineer.

Early on, I thought great code meant handling every edge case and future feature. Now I know: simple code always wins.

Example:

I once built a complex config system for a feature that only needed two settings. Looking back, a simple approach would've been easier to build and maintain.

Action Item:

• Before you start, ask: “What’s the simplest way to solve this?”

• Follow YAGNI (You Aren’t Gonna Need It): don’t build features until you need them.

7. Test your code. Future you will thank you.

Writing tests can feel tedious, but they save time and catch bugs when it matters most. They give you confidence to ship and refactor. Seriously. Never refactor without them.

Example:

I built a key feature which broke in production due to missing input checks. One simple test would've caught it.

Action Item:

• Set a goal to write at least one unit test for every new function, feature, bug you create.

• Use code coverage tools to spot missing tests.

8. Learn the business side.

Knowing why a decision is made matters as much as knowing how to build it. Software solves real problems. It is not code for code’s sake.

Example:

I worked on a notification feature that felt useless. After release, users left so many comments that it helped them catch key updates. That changed my view of the problem.

Action Item:

• Talk to product managers or join customer feedback sessions to learn user needs.

• Learn basics like ROI, KPIs, and customer personas to understand your work better.

9. Efficiency is your superpower.

Small improvements grow over time. Faster typing, better tools and more make a big difference.

Example:

By automating a weekly data-cleaning task that used to take an hour, I saved my team 50 hours per year.

Action Item:

• Invest time in learning keyboard shortcuts, IDE features, and productivity tools.

• Look for repetitive tasks in your workflow and script or automate them.

10. The “perfect” job doesn’t exist.

There’s no single role or company that will check every box. Focus on growth, impact, and culture over perfection.

Example:

A friend of mine switched teams or Big Tech jobs over small disagreements. But different opinions are normal and part of the process.

Action Item:

• Make own list of must-haves like learning, work-life balance or big salary. Then choose roles that fit.

• Think about your long-term career goals and pick roles that match them.

Wrapping Up

Software engineering is more than coding. It’s about the journey, people, and lessons. It’s tough but full of possibilities.

To my younger self and beginners: embrace the process, be patient, and keep learning. You’ve got this.

If you found this helpful, please like or share it with a friend and consider subscribing if you haven’t already.

Thanks for reading,
Adlet Balzhanov

Connect with me on LinkedIn, just use the button below. I read every message. Cheers!

My LinkedIn

Event-driven systems are everywhere. They help apps talk to each other, handle data better, and stay responsive. But if you’re not careful, they can also get messy fast. One big problem? People often confuse event-driven architecture with specific technologies like queues or message brokers.

As Dragan Stepanović briefly put it on LinkedIn:

Here’s the kicker: you don’t need messaging/queuing technologies to do Event-Driven Architecture.

That insight sparked my curiosity and inspired me to learn more, which led to this article.

Martin Fowler’s breakdown of event patterns gives us a clear way to think about them. Here’s what you need to know.

What Is Event Notification?

Think of event notification as a simple heads-up. One system says, “Hey, something just happened!” and leaves it to others to decide what to do about it. For example, an app might send out an “OrderShipped” event to let other systems know an order is on its way.

Real-Life Example: When a user updates their profile picture on a social media platform, an event notification can be sent to notify other systems, like a newsfeed service or a recommendation engine, about the update.

Why It’s Good:

• Keeps Things Independent: Systems don’t need to rely on each other too much.

• Easy to Set Up: The sender doesn’t need to know who’s listening.

Why It Can Be Tricky:

• Hard to Trace: If a lot of systems are listening and responding, it’s tough to see the full picture.

• Hidden Commands: Sometimes, events get misused to tell other systems what to do, which defeats the purpose.

Pro Tip: Only use events when systems really don’t need to know much about each other. Be clear about what the event means.

What About Event-Carried State Transfer?

This is when the event carries all the info someone might need. Instead of just saying “OrderShipped,” the event might include details like the order number, shipping address, and delivery date. This way, the other systems don’t have to ask for more info later.

Real-Life Example: In e-commerce, when an order is placed, the order service sends an event with all order details, allowing the inventory, shipping, and notification systems to act independently without querying the order service.

Why It’s Great:

• Fast and Reliable: Systems can work even if the main app goes down.

• No Waiting Around: No need to call the main system to get details.

Why It Can Be a Pain:

• Too Many Copies: Every system has its own version of the data, which can get out of sync.

• More Work for Listeners: They have to store and manage all that extra data.

When to Use It: When speed and resilience matter more than keeping things perfectly tidy.

What Is Event Sourcing?

Event sourcing is like keeping a diary. Instead of storing the latest state of something, you write down every change. To find out what’s going on, you read through the changes and piece it together.

Real-Life Example: A banking system records every transaction as an event. To calculate the current account balance, the system replays all transactions from the event log.

Why It’s Cool:

• Complete History: You can see everything that ever happened.

• Undo or Replay: Go back in time or test out new ideas by replaying events.

• Audit-Friendly: Perfect for tracking important changes, like financial transactions.

Why It’s Tough:

• Harder to Manage: Replaying events can get complicated, especially if you’re working with other systems.

• Changing the Rules: If your event format changes over time, it can break things.

Pro Tip: Use snapshots to save the current state every so often. It makes replaying faster and easier.

What Is CQRS (Command Query Responsibility Segregation)?

CQRS is about splitting the work. One part handles changes (commands), and another handles questions (queries). It’s like having two tools for two different jobs.

Real-Life Example: In a ride-sharing app, the command system manages ride bookings and updates, while the query system handles showing drivers’ locations to users in real-time.

Why It’s Useful:

• Optimized Performance: Each part can be built for its specific job.

• Better Scaling: You can handle lots of reads or writes without breaking a sweat.

Why It Can Be Overkill:

• Extra Complexity: Splitting things up means more moving parts to manage.

• Not Always Needed: For simple systems, it just adds work.

When to Use It: When your system has lots of reads and only a few writes, or when the read and write logic is very different.

Event-Driven Isn’t Just Tools

Here’s where many teams get it wrong: they focus too much on the technology. Event-driven doesn’t mean you must use specific tools like Kafka, RabbitMQ, or AWS SQS. Those are just ways to implement the patterns. What really matters is the architecture—the way systems communicate and share responsibilities using events.

Logically, event-driven architecture inverts the control flow to reduce the two-way coupling we see in request-response systems. For example, many HTTP-based technologies allow systems to subscribe to and publish events without needing traditional message queues. Adding a physical queue, like RabbitMQ or Kafka, is about solving specific problems such as load-peaking, not about defining event-driven architecture itself. You can still do Event-Driven Architecture without these tools—it’s about design, not dependency.

How to Choose the Right Pattern

Event-driven systems aren’t one-size-fits-all. Each pattern has its sweet spot:

• Event Notification: Great for simple signals. Use it to keep systems loosely connected.

• Event-Carried State Transfer: Use when speed and independence matter more than keeping data perfectly synced.

• Event Sourcing: Perfect for audit trails and systems that need to rebuild history.

• CQRS: Ideal for complex systems with heavy reads or different models for reading and writing.

It’s easy to get carried away with fancy patterns. But remember, simpler is better. Don’t use event sourcing or CQRS unless you really need them. Start small, learn as you go, and adjust as your system grows.

Conclusion

Event-driven systems are powerful, but they’re not magic. Understanding the patterns and when to use them makes all the difference. Start with clear goals, keep things as simple as possible, and watch out for unnecessary complexity.

Special thanks to Martin Fowler for inspiring this exploration of event-driven systems, and to Dragan Stepanović for his insightful LinkedIn post that reminded me that event-driven architecture is more about design than tools. This article is my way of learning and sharing what I’ve discovered.

Until next time,
Adlet

Loved this post? 💙 Hit that like button—it means the world to me and helps me grow.

Know someone who’d find this helpful? ♻️ Share it with them! Let's spread the knowledge and keep inspiring each other.

Stay awesome!

Connect Now on LinkedIn