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. Not because we don’t understand it, but 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. The problem isn’t that it’s incorrect—it’s that 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 familiar. 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

• # of subscribers (from 37 → 3402)

• number of reads in 2025 (73.3K)

When I started writing in December 2024, I thought maybe max 100 people would care about my takes.

I was writing for the version of myself who questioned whether anyone else noticed the same patterns. We’re all just trying to build things that matter while navigating the current state of the tech industry.

Top 3 most viewed articles of 2025

In the coming 2026, I’ll of course continue writing. Please share in the comments which topics you would be most interested in. Any ideas or thoughts would be valuable.

Thanks for reading, and for reminding me that honest writing still finds its people,

Adlet

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…” isn’t weakness. 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.

In fast-moving teams, I’ve seen this play out over and over. 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. Not because they don’t know how it might land but 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. That’s a career skill.

This isn’t about playing dumb. It’s about reading the room and using soft language as a kind of interpersonal lubricant. 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

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, same fear of public judgment, 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. Not because I liked embarrassing myself, but because 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

These are the leaders that slow everything down, wear people out, and make good engineers want to leave.

The first type is The Hero Blocker. These are smart, and that’s the problem. They need to be the smartest person in the room. Every idea you bring feels like a threat. They question your work, not to make it better, but to show they know more. They hide this as “high standards”, but it’s their ego under the hood. Over time, the team stops sharing bold ideas. It’s not worth the fight. You play it safe.

The Pusher. This one is always in a hurry. Everything is urgent. Every project is behind. Every ask is “just a small favor”. They don’t code, but they’ll push timelines like they do. They don’t ask how you’re doing, only when it’ll be done. At first, it feels like momentum. Then it becomes chaos. You burn nights and weekends to meet made-up deadlines. You stop thinking long-term. You start cutting corners. Pushers don’t mean to break their teams. But they do it anyway by never letting up.

The third type is The Proxy. This type doesn’t understand the work, and they don’t try to. They sit in meetings, nod a lot, and then repeat what you said to their boss like it was their idea. When it’s time to present to leadership, they speak for you. When there’s a problem, they vanish. You do the real work. They take the credit. Over time, this gets tiresome. Not because you need applause, but because you need a leader who has your back. The Proxy never does.

Tech is full of these types. And they don’t always fail fast. Some get promoted. Some are seen as “strong operators”. But they leave behind teams that are tired, and slowly giving up. The engineers leave because their best work gets ignored, blocked, or stolen. And if you’ve worked under one of these "leaders", you know the exact moment when the light goes out.

Surviving bad leadership teaches you what good should feel like. They clear the path, share the wins, and protect the team. When you find one, you don’t forget it. Right?

If you liked this post, hit the like button, share your story in the comments. 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 2025, FAANG feels like a time capsule from a different internet. Today’s momentum belongs elsewhere. To be specific, to the builders of intelligence, not only infrastructure. Enter: MANGO. Meta, Apple, Nvidia, Google, OpenAI.

It’s a signal that the center of gravity in tech has moved from platforms that distribute content, to platforms that understand it.

Why MANGO?

• Meta still plays in the big leagues, but it’s no longer the Facebook of your parents’ feed. It’s leaned into AI research, LLMs, Llama, giving 100 million offers to current OpenAI engineers. Meta’s bet is clear: stay relevant by becoming an AI-native company.

• Apple remains the ultimate hardware+software integrator. Seems like they’re quietly building the AI ecosystem that doesn’t scream “AI.”

• Nvidia. It’s the new oil. Without its GPUs, AI doesn’t run. Jensen Huang went from geek hero to modern-day Carnegie. Millionaire printer. An average IC3 (Senior) Engineer at Nvidia went from a $250k TC at time of offer (2022) all the way to an $850k TC only 3 years later (Source: levels.fyi)

• Google (still the G in MANGO) may be catching up with Gemini, VEO 3, but it still controls the web’s backbone, search, and an absurd amount of compute.

• OpenAI, the star of this shift, grew into a global intelligence layer. I don’t even need to explain how game-changing things got after ChatGPT launched in November 2022.

The Implication

FAANG was about attention. MANGO is about cognition.

The shift shows where value is: in companies that think, reason, and predict. The future isn’t who can host the most content or deliver the fastest package anymore. It’s who can understand us better than we understand ourselves.

For talent, this means the best minds are drifting toward AI-native orgs. For capital, it means chasing compute, models, and differentiated data. For founders, if you’re not building with intelligence at the core, you’re playing last decade’s game, dot com.

FAANG had its run. But the world doesn’t need more apps. And that future?

It tastes like MANGO 🥭

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

You learned how to pass exams. How to build things that kind of worked. You got good at memorizing syntax, grinding LeetCode, regurgitating sorting algorithms from memory.

But then you hit the real world. Real teams. Real systems. Real deadlines. None of that coursework prepares you for the chaos of building software that matters.

That’s where I started learning for real. Not from a professor.
From YouTube.

Here are the three channels that reprogrammed my brain. They didn’t only teach me code. They taught me how to think like an engineer.

1. Andrej Karpathy

I found Karpathy’s YouTube by accident, like when you try a new food and it’s actually delicious.

No flashy edits. No clickbait. Just signal.

Karpathy doesn’t teach like a regular YouTuber. He teaches like someone who’s done it for real and now wants to share what he learned the hard way.

His videos changed how I think about hard stuff. Backpropagation and Transformers didn’t feel like magic anymore. It felt like I could build something like GPT. Not because he made it super easy, but because he explained it in a way that made me feel smart.

Every time I watched Karpathy, I walked away a little sharper. A little more curious. And most importantly: a little less afraid of the hard stuff.

2. CS50

You could spend $200,000 on a computer science degree and still not learn as much as you do from the channel for free.

CS50 from Harvard isn’t just a good YouTube course. It’s one of the best ways to learn computer science, anywhere. Watch one video. You’ll see how clear, exciting, and fun it is.

But what really amazed me wasn’t just what course instructors taught. It was how they taught it.

They perform. They make you care about the ideas, the choices, the reasons behind the code.

And the homework? It doesn’t just check if you understand. It checks if you can keep going when it’s hard.

3. ArjanCodes

I shared a lot of knowledge with my team based on Arjan’s teachings.

There’s a gap most tutorials never cross: the line between code that works… and code that lasts.

That’s where Arjan comes in.

His channel is a masterclass in design thinking. Not academic UML diagrams. Not over-engineered theory. Clean, maintainable architecture. Explained like you’re sitting next to a senior dev who gives a damn.

He breaks down patterns and principles: SOLID, DDD, testing strategy, clean architecture. But he never loses sight of why it matters. That’s what makes him good.

After Arjan, I started seeing things I didn’t notice before. The hidden coupling. The tech debt traps. The slow rot of “just ship it” logic.

To sum it up briefly

We’re living in the greatest era of self-education in history. The tools are free. YouTube is free. ChatGPT is free. The knowledge is abundant. But attention? That’s expensive.

These three channels earned mine—and repaid it tenfold.

They taught me things my degree never did: How to design for humans. How to reason under complexity.

If you’re on the path and you’re serious about leveling up, start here. Watch. Take notes. Rewatch when it clicks. Let the knowledge compound.

If you found this helpful, please let me know and click the like button below. It’s the best feedback I could ask for.

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

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

Something’s changed.

We’re now living in the era of the 100x engineer. And no, it’s not just a flexed-up version of the old title. It’s a whole new species. Enabled by AI. Multiplied by tooling. They’re not just writing code. They’re orchestrating leverage.

small teams, massive impact

Look at Bluesky, a small social app that’s quietly become a Twitter alternative. Around 20 full-time employees. Nearly 40 million registered users.

Well, tiny team. Lean budget. And yet they’re serving millions of users, building protocol-level infra, and iterating faster.

How?

Because today, one sharp engineer, equipped with the right AI tools, cloud infra, and good taste can build, scale, and maintain systems that used to take full departments.

They’re not 10x more productive. They’re operating in a different dimension.

tools that feel like superpowers

A 100x engineer doesn’t write every line of code by hand. They design systems, prompt copilots, reuse LLM-generated scaffolding, and delegate grunt work to machines. They spend their energy on high-leverage decisions — architecture, interface, feedback loops. And let AI handle the boilerplate.

It’s not just about knowing how to code.
It’s about knowing what not to code.

AI isn’t replacing engineers. It’s amplifying the best ones. The same way spreadsheets didn’t replace accountants, but made the great ones unstoppable.

leverage is the new headcount

Remember when startups needed 20 silicon valley engineers to be taken seriously? Now two people with laptops and a good idea can launch something that feels like magic because the tools are magic. Not even two, remember this one guy Maor Shlomo, who built a one-person startup, Base44, completely solo and sold it to Wix for $80 million in cash after just six months (June 2025). It’s not about having the biggest team or the most funding anymore.

Think Vercel. Supabase. Replit. Claude. GPT-4o. We’re building on the shoulders of abstractions so powerful, it’s almost cheating.

100x engineers are not mythical solo heroes.
They’re highly leveraged operators who understand the stack — technical, product, and human. They’re thoughtful. Opinionated. Resourceful. And ruthlessly focused on outcomes.

so what does this mean for you?

If you’re a builder, this is your moment. You don’t need permission. You need curiosity, taste, and a willingness to ride the wave.

If you’re a team lead or founder, look for leverage-minded engineers. Not just coders. Systems thinkers who see tech as a tool to compress time and scale impact.

And if you’re feeling behind, don’t worry. The 100x mindset isn’t about IQ. It’s about how you approach your work:

• Use AI like a cofounder, not a toy.

• Treat tools as force multipliers.

• Work on what matters most, not what’s most familiar.

We’re not just shipping software anymore.
We’re building futures with teams small enough to fit in a group chat.

And the people doing it?
They’re not superhuman.

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

That line hit me. Not because of the opportunity, but because of the “Been following your work.” This wasn’t magic. And it didn’t happen overnight.

If you’re a software engineer and you’re not taking your personal brand on LinkedIn seriously, you’re just skipping changes.

Well, then how to build a personal brand on LinkedIn that actually gets you noticed?

Why Bother?

Here’s the harsh truth:
You can be incredible at your craft and still invisible.

The best jobs don’t always go to the best engineers.
They go to the ones who are visible, trusted, and easy to say yes to.

LinkedIn isn’t just a job board. It’s a living, breathing proof-of-work platform.
It’s where hiring managers, founders, VCs, and your future co-founder are already looking. And judging.

Having a solid LinkedIn presence doesn’t mean posting daily threads about microservices. It means:

• Making it easy for someone to quickly understand what you’re great at

• Giving people a reason to follow your journey

• Signaling to the right people

Let me break it down, part by part — practical, doable steps you can take this week. Not saying my profile is perfect, but I’ll use the power of being the author of this post and share some examples from it :D

1. Profile Picture

This is your digital handshake.
No pixelated selfies. No conference badges. No sunglasses.

✅ Use a clean, high-resolution headshot
✅ Wear what you’d wear to a casual interview
✅ Look approachable, not like you’re trying to sell crypto

Not wearing black and white, but I think it looks good though.

2. Headline

Most people just put: “Software Engineer at Company X.”
That’s fine. If you want to be invisible.

Instead, tell people what you do and why it matters. Think value, not title.

Better:

Building reliable systems at scale | Go, Kubernetes, AWS | Obsessed with clean code & shipping fast

Or:

Senior SWE | Founder of The True Engineer newsletter (2K+ subscribers) - Expert Insights and Practical Advice for Modern Developers

3. Profile Banner

This is your billboard. Use it.

Ideas:

• A photo of you speaking at an event

• A simple tagline (e.g. “Scaling systems, one microservice at a time.”)

• Your personal website, blog, newsletter or GitHub repo

• A clean graphic that reflects your tech stack

Use free tools like Canva to create something that feels personal and on-brand.

4. About Section (aka Your Origin Story)

This is where most engineers stumble. They either:

1. Skip it entirely

2. Copy-paste their resume

3. Write in third person like they’re a Marvel villain

Don’t do that. Here’s the move:

Write like you’re telling a friend what you do — and why you love it.

Keep it human. Here’s a structure that works:

• Who you are

• What you love building

• What you’ve done

• What excites you now

• What kind of opportunities you’re open to

Example:

I climbed from New Grad to Senior Engineer in just 3 years at a Big Tech company by the age of 24. Now, I'm sharing my insights and mentorship through my newsletter (www.thetrueengineer.com)

What I Do Best
- Backend Engineering (6+ years) – Python expert, designing robust and scalable architectures
- Distributed Systems & Conversational AI – High-performance, AI-driven applications
- Competitive Programming & Math – 2x ACM ICPC Semifinalist, leveraging algorithmic thinking in real-world engineering

If you're interested in software engineering, system design, or career growth in tech, let's connect!

5. Experience Section

This isn’t your resume. It’s your highlight reel.

For each role, focus on outcomes, not tasks. For example,

❌ “Built a microservice”
✅ “Developed a fraud detection service from scratch to replace the legacy backend, resulting in an 85% reduction in the p95 latency”

Use bullet points. Quantify when possible. Mention tools, but lead with impact.

6. Content: What to Post

You don’t need to go full LinkedInfluencer.
But posting something once or twice a week is how you stay top-of-mind.

Here’s what works:

• Share what you’re learning (e.g., “Spent the weekend playing with Postgres CTEs. Here’s what surprised me”)

• Small wins from work (e.g., “We finally killed a flaky test. Here’s how”)

• Questions you’re thinking about (e.g., “Is it ever worth rewriting from scratch? Curious how others think about this.”)

• Book/code/tool recommendations

• Reflections on the job hunt, interviews, or side projects

Golden rule: Write for one level behind you.
What feels obvious to you might be gold to someone a step earlier in the journey.

💡 Pro Tip: The 3-2-1 Method

Each week, aim to:

• Comment on 3 posts (especially from people you admire)

• React to 2 posts from companies you like

• Publish 1 short post about something you learned

This keeps your account active and your name familiar — without spending hours online.

Final Thought

You don’t have to be famous.
But you do want people to associate your name with something.

Could be:

• “The backend engineer who breaks down complex stuff simply”

• “The dev who’s always trying new tools”

• “The one who explains systems thinking with clarity”

Be intentional. Be visible. Be helpful.

Because in a world full of noise, the quiet, thoughtful voices are the ones we remember.

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

I graduated thinking I needed one thing: a good job at a good company. That’s what all the advice boiled down to.

But here’s the truth: your career isn’t a ladder. It’s a jungle gym. And in your early 20s, you’re just trying to figure out which direction even matters.

So, if I could go back and talk to that version of me, I’d tell them these hard-earned truths what actually plays out in real life.

Let’s get into it.

1. Job-Hopping Early Is a Feature, Not a Bug

If you’re in your early career, changing jobs every 1–2 years isn’t a red flag. It’s a growth hack.

At this stage, you don’t need “stability” — you need exposure. Different codebases. Different managers. Different company cultures. Every hop teaches you what no bootcamp or CS class can: how real engineering orgs work.

Some of my smartest peers switched roles three times in five years. Today, they’re Staff Engineers, PMs at startups they believe in, or founders with actual taste. They got there by sampling early. Think of your first few years as product-market fit — but for your life.

Pro tip: each jump should teach you something new — a different tech stack, a new domain, or a better way to work with people. You’re not climbing. You’re exploring.

2. Internships Are More Strategic Than You Think

If you’re still a student (or mentoring someone who is), listen up: the right internship is a cheat code.

Most people optimize for brand names. That’s fine — but also try to optimize for learning speed. Here’s what I wish I knew:

• Do both: Try one internship at a small startup, and one at a big company. That contrast will teach you more than any class.

• Regularly talk to people 2–3 years ahead of you. Not 20 years. Not TikTok influencers. Real engineers who remember what it was like to be in your shoes. Their advice hits different. Find them on LinkedIn, attend free tech events, approach them during the breaks. Believe me — most people love to share advice

• Think beyond English. If you’re studying abroad — say, in Germany — learn the local language. Your job prospects post-grad will skyrocket. Please don’t sleep on this. Being fluent in the local tongue is often the hidden key to unlocking real opportunities. Otherwise, you’ll fall behind because of the language barrier — and in most cases, English-speaking jobs are highly competitive. I know many people who wasted 1–2 years just trying to land a job due to the language gap.

Internships aren’t just about resume lines. They’re test drives. Use them to find your taste.

3. If You Want to Be “Rich Rich,” Big Tech Is Not the Path

Controversial? Maybe. But if you’re optimizing for wealth, Big Tech is… fine. You’ll get RSUs, a stable salary, maybe hit $300K+ after a few years.

But you won’t get leverage.

If your dream is true wealth — freedom, ownership, asymmetric upside — you’ll need to build something, join a rocket ship early, or play the long game in equity-heavy bets.

Big Tech is like the business class of tech careers. Comfortable. Predictable. Safe. But you’re not flying the plane.

And that’s okay — just be honest about what you want.

4. AI Is Changing the Game — Stay Curious, Not Just Scared

The rise of AI tools isn’t the end of software engineers. It’s the end of low-leverage, repetitive software engineering.

The best devs I know are already 10x-ing themselves by using AI for boilerplate, documentation, debugging, even product ideation. It’s not just about coding faster — it’s about thinking differently.

This shift rewards the curious. The generalists. The ones who aren’t afraid to learn new tools, try strange ideas, or talk to users. If you treat AI like a partner, not a threat, you’ll win.

5. Don’t Let Your Job Be Your Whole Identity

Tech loves to turn work into religion. “What do you do?” becomes who you are.

But here’s the quiet truth no one tells you: the happiest engineers I know don’t worship their jobs. They have range.

They build real friendships. They play music, lift weights, volunteer, write, learn languages. Their identity isn’t just Python or React. It’s being a curious human.

You’ll burn out quickly if work is your only pillar. And more importantly — you’ll miss out on the actual good stuff: deep friendships, great partners, inside jokes, road trips, side projects that matter. Those things make the tough sprints at work worth it.

Final Thoughts

Your early career is less about climbing and more about tasting. You’re not falling behind if you’re exploring. You’re not failing if you feel lost sometimes.

Don’t play someone else’s game. Play yours.

Build the kind of life you’d want even if the internet disappeared — a mix of good work, great people, and endless curiosity.

And if you’re reading this feeling unsure, you’re not alone. We’ve all been there. The secret is: no one really has it figured out. Some of us are just better at asking the right questions.

Until next time,
Adlet

🎉 We're approaching 2,200 newsletter subscribers! Thank you for your support!

You’re the real MVPs!

Loved this post? 💙 Just hit the like button below. It's a small favor from you, but it helps me grow a lot.

Stay curious!

Last year, I was playing around with AI tools. Mostly just asking them basic stuff like “Summarize this article” or “Generate a tech documentation about …” Cool, but nothing life-changing.

I realized I wasn’t using AI wrong, but I also wasn’t using it right. It was like having a Ferrari and only driving it in a parking lot. So I started digging into how to talk to AI better. Like really talk to it.

That’s when I found something that changed my workflow, my side projects, even how I explain things to friends.

Here are three powerful prompting techniques that turned AI into my most trusted coding partner, thought organizer, and brainstorming buddy.

Let’s dive in.

1. Chain-of-Thought Prompting

Sometimes, when you ask AI a question, it just spits out the answer. No explanation. No thinking out loud. Just… boom. Final answer.

But here’s a better way to ask:

Design a basic system architecture for a ride-hailing app. Explain your decisions step by step. Starting with the core services and why you chose them.

Now instead of a one-size-fits-all diagram, AI walks you through its logic (step by step). What services it prioritized, how they talk to each other, and trade-offs it considered.

Why this is powerful:

• You learn how the AI makes decisions

• You catch flawed assumptions early

• You can tweak the parts that don’t feel right

I use this when I’m exploring designs, reviewing code suggestions, or preparing engineering strategy docs. It’s like having an architect who always explains their thinking—and never pushes back on feedback.

2. Role-Based Prompting

One of the best ways to get more useful answers from AI? Give it a role and a specific audience.

For example, if you ask:

Explain the difference between SQL and NoSQL databases.

You’ll probably get a technical breakdown—useful, but maybe not what you actually need.

Now try this:

You’re an experienced database expert explaining to a product manager with limited technical background. Help them understand the key differences between SQL and NoSQL, and when to choose one over the other—using simple, real-world examples.

Suddenly, the answer shifts. Less jargon, more clarity. Focused on what the listener needs to know, not just what the AI knows.

I use this approach often—especially when aligning with cross-functional teams. Whether I’m drafting strategy docs, onboarding new hires, or prepping for stakeholder briefings, this trick helps AI tailor the tone and depth so I don’t have to do all the translation work later.

Think of it as turning AI from a know-it-all into a great communicator.

3. Modular Prompting

Big tasks are where things fall apart. Unless you break them down.

One time, I asked AI:

Write a complete guide on mentoring new grad engineer.

The answer? Too long, all over the place, and overwhelming.

So I broke it down:

Step 1: Explain the importance of code reviews.
Step 2: Discuss how to give constructive feedback.
Step 3: Share tips for setting learning goals.
Step 4: Suggest ways to encourage independent problem-solving.

Now the AI was thinking like a team lead—not just dumping ideas. The output became a clean, usable draft.

This method is gold for:

• Creating technical design docs

• Writing sprint plans or retrospectives

• Mapping out hiring roadmaps

• Or even prepping talking points for a tech leadership sync

The key? Guide AI through your thinking. One logical step at a time. You’ll reduce noise, avoid rework, and get results that fit how you operate.

So, Why Does This Matter?

Because this is where things are going.

Tech companies, and honestly, smart solo builders too are looking for people who don’t just use AI, but know how to guide it. Prompting is the new literacy.

These three techniques are how I’ve gone from AI “user” to AI collaborator. And once you start using them, it’s hard to go back.

Try This
Before you leave, challenge yourself:
Next time you use ChatGPT (or any AI tool), don’t just ask a question.

Use one of these techniques. See what happens. You might be surprised at how much better your results are.

If this post made something click for you—share it with someone. Let’s help more folks stop driving Ferraris in parking lots 😉

Until next time,
Adlet

🎉 We're approaching 2,000 newsletter subscribers in just a couple of days! Thank you for your support!

You’re the real MVPs!

Loved this post? 💙 Just hit the like button below. It's a small favor from you, but it helps me grow a lot.

Stay curious!