Not slowed. Done. The meter said I had spent a month of AI in a week and a half.

My first instinct was to buy a bigger plan. But something bugged me. I don’t type that much. My prompts are short. My files are small. Where did a month of tokens actually go?

So I followed them. All 172 million of them.

The answer changed how I use these tools every day. About 92 of every 100 tokens were the model re-reading things it had already read. Only 1 in 100 was the model writing anything new.

You are not paying it to think. You are paying it to re-read.

First, I had to see it

You cannot fix what you cannot see.

Claude Code keeps a log of every session on your laptop. Every prompt, every reply, every token, sitting in plain files. Nobody ever reads them.

I found a free dashboard that does [3]. It runs on your machine and reads those logs. It adds up where every token went. Nothing leaves your laptop. No login, no API key.

I ran it on my 174 sessions. About 2,400 prompts. Here is the ten-second version of what it found:

Why so much re-reading

Here is the part nobody tells you when you install an AI coding tool.

The model has no memory. None. Every message starts from a blank brain. So the tool re-sends everything, every single turn. The system prompt. Every tool definition. Your project rules. The whole conversation so far. Then your one new line at the end.

Ask ten small questions and you pay for the whole history ten times. The chat feels light. The bill grows fast.

The cache is the whole game

Re-reading everything at full price would be madness. So there is a trick. It is called prompt caching.

The first time through, the model does the reading and saves its work. That save is a cache write. Next turn, it reads the save instead of redoing the work. A cache read costs about a tenth of the fresh price [1].

That is the whole deal. Write once, read it back for a tenth.

But the cache has two rules. Break either one and you are back to full price.

Rule one: nothing above it can change

The cache works top down, like a stack of plates. System prompt on top. Then your project rules. Then the conversation. Your new message sits at the very bottom.

Change one thing near the top and everything below it dies. Add a tool server mid-session. Edit the system prompt by two letters. The model quietly re-reads it all, at full price.

The whole stack in one picture. Bob is about to break every layer of it.

Rule two: the clock

The cache also expires. On a Claude Code subscription, you get about an hour between messages [2]. On the raw API, and for sub-agents, five minutes.

Walk away mid-task and come back past the window. Your next message rebuilds the entire stack from zero. The deeper the session, the more that hurts.

Keep the session warm, or close it. Half-abandoned is the expensive state.

Meet Bob

Bob is not real. Bob is every one of us on a deadline. Bob ships fast, and Bob torches tokens like they are free.

I know his eight habits well. I found every one of them in my own logs. The fixes sort into three moves.

Close the loop, or keep it warm

Bob ghosts his sessions. Mid-task, he wanders off for two hours. He comes back, types one word, and pays to rebuild everything he had. Finish the thought before you stand up, or clear it. A warm session is a cheap session.

Bob runs one session all week. By Friday, every message still re-reads Monday’s debugging. Same work, ten times the bill. New task, new session. /clear is the cheapest key on your keyboard.

Carry less context

Bob hoards tools. Twelve tool servers, connected “just in case.” Every message hauls thousands of extra tokens he never uses. Keep the tools you actually call. Drop the rest.

Bob pastes whole files. Two thousand lines, so the model “has context.” Now every turn re-reads all of them. Point at the file instead. Paste the one function that matters.

Bob dribbles questions. Five tiny follow-ups, five full re-reads of the chat. Ask once, ask fully. One good message beats five lazy ones.

Steer before it runs

Bob swaps models mid-task. The cache belongs to one model. The “cheaper” model rebuilds everything from scratch, and the quick question costs more than staying put.

Bob says “just build it.” The model charges down the wrong road, writes 400 lines, then scraps them all. Ask for the plan first. Approve it. Then let it build.

Bob watches it spin. The same broken fix, retried ten times while he gets coffee. Failing three times in a row? Stop it and redirect.

Run it on your own logs

The dashboard is free, open source, and local only [3]. Credit where it is due: Nathan Herkelman built it, and it is excellent.

One command. It scans your logs, opens your browser, and shows the damage. The first scan takes under a minute.

You cannot argue with your own logs. Mine said 92 percent. I would bet yours says something close.

What happens next

In the dinner bot post, I promised a look at what my AI actually spends. This was it.

Next, the honest part. I am running these eight fixes for a month, with the dashboard watching. Did the bill actually drop, and by how much? That post writes itself either way.

Every build lands here first, as a full log like this one. Subscribe and you’ll get each one in your inbox.

Build fast. Understand everything.

Become an AI engineer with me.

Om

References

1. Anthropic docs, Prompt caching. Cache reads cost about 10% of the base input price. Cache writes cost 1.25x for the five-minute window and 2x for the one-hour window. Docs

2. Claude Code docs, How Claude Code uses prompt caching. On a subscription, Claude Code requests the one-hour cache window automatically. Sub-agents and raw API keys default to five minutes. Docs

3. The dashboard: github.com/nateherkai/token-dashboard by Nathan Herkelman (MIT license). It reads your local Claude Code logs and nothing leaves your machine.

Tonight’s dinner. The dish, the ingredients, one prep note. Nobody typed it. Nobody had to remember it.

Saturday morning, it buzzed again. The week’s menu, plus the full grocery list, sorted by aisle.

Last week I texted the bot: “change Wednesday dinner to rajma chawal.” It replied “Menu updated.” That was the whole deploy.

And behind all of it? No server. No database. No app.

An AI agent I built in one evening. $0 a month.

This is the full build log. Every decision explained, including the two bugs that made it late for dinner.

The 6 PM question

You know the question. “What’s for dinner?”

It lands when everyone is tired and hungry. Worst possible time to make a decision. So we ate the same three dishes on repeat. Not because we love them. Because deciding was the expensive part.

So I wrote the menu down once. Seven dinners, one per weekday. Then I built a machine to nag us about it.

The whole system

The chat is a Telegram group. The bot sits in it like another member.

The state of our kitchen is three JSON files in a GitHub repo. A menu. A grocery list. A reminders file.

Three tiny Python scripts read those files and message Telegram. GitHub Actions runs them on a schedule. The 5 PM send is fired by a free Vercel cron instead. There’s a scar behind that choice. We’ll get to it.

Want to change something? Text the bot in plain English. Claude reads it, picks a structured edit, and the code commits the file.

A normal week for it

1. Every evening at 5, dinner lands in the chat. Dish, ingredients, prep note. Cooking starts without a debate.

2. Saturday at 10 AM, the grocery list arrives.The week’s menu on top. Every item below, grouped by aisle. One store run.

3. Menu edits happen by text. “Change Monday to pasta.” The bot commits the change. The next reminder reads the new file. No redeploy.

4. Reminders too. “Remind me every Friday at 6 to water the plants.” The bot computes the cron line and rewrites its own workflow file. The system edits its own schedule.

5. Everything is a commit. git log shows who changed what, and when. Undo is one revert.

   

What a dinner bot taught me about production

A repo is a fine database

1. Git as the database. The data is three small files that change a few times a week. A real database earns its keep with queries and heavy write traffic. We have neither. Git gives us history and one-command undo, free. For data this shape, the repo wins.

2. Zero dependencies where it hurts. The scheduled scripts use only Python’s standard library. Nothing to install on the runner. Nothing to break at dinner time. The one real dependency, the Claude SDK, lives on the webhook side. If that fails, a text goes unanswered. Dinner still arrives.

Time is the hard part

3. Your server lives in UTC. You don’t. First bug. On Sunday night, the bot announced Monday’s dinner.

At 5 PM my time, UTC is already tomorrow. The runner believed UTC. One line fixed it: compute the day in your own timezone.

4. Free schedulers run late. Second bug. The 5 PM message showed up at 6:30. Some days, 7.

Nothing was broken. GitHub says scheduled jobs can wait in line, and some get dropped [1]. I had read a queue as a clock.

5. Match the scheduler to the promise. Dinner is the one message that can’t be late. So that cron moved to Vercel, which lands within minutes [2]. Everything else stayed on GitHub. Late and free is fine for a grocery list.

6. Daylight saving will move your dinner. Clocks shift twice a year. Cron does not. Each workflow keeps its winter value in a comment. Future me swaps one line.

Letting AI touch production

7. Tool use, not free text. Claude never touches the files. It fills a strict schema: which day, which dish. My code does the actual edit. If the model gets creative, the schema rejects it. The blast radius stays exactly as big as the schema.

8. Two locks on the door. The webhook checks a secret header, so only Telegram can call it. Then it checks the chat ID, so only my chat can command it. Anyone else gets a polite refusal. Ten lines of code, and a public URL stops being scary.

9. An audit log I didn’t build. Every edit the bot makes is a commit with a message. When the menu looks wrong, git log answers “what changed” in five seconds. I’ve built audit tables at work that did less.Run it tonight

Run it tonight

The code is public github.com/Omsai92/ai-dinner-bot.

The README takes you from zero to your first reminder in about 15 minutes. A Telegram bot, two secrets, done. The chat-editing layer is optional and adds twenty more.

What happens next

This is the second full build log in Under the Hood. More are coming. A token-cost dashboard that watches what my AI spends. A deeper cut of the job agent, failure by failure.

Every build lands here first, as a full log like this one. Subscribe and you’ll get each one in your inbox.

Build fast. Understand everything.

Become an AI engineer with me.

Om

References

1. GitHub Docs, Events that trigger workflows, on the schedule event. It warns the event “can be delayed during periods of high loads”. It adds that “some queued jobs may be dropped”. Docs

2. Vercel Docs, Usage & Pricing for Cron Jobs. Hobby plan cron jobs run at most once per day, with per-hour precision. A 1:00 AM job fires between 1:00 and 1:59. Docs

3. Full source code: github.com/Omsai92/ai-dinner-bot (MIT license).

4. Stack: Python standard library (scheduled scripts), GitHub Actions (scheduling and state), Claude tool use (chat parsing). Plus the Telegram Bot API (messages) and Vercel (webhook and the dinner cron).

An AI had read 157 job posts overnight.

It picked the best five, scored them, ranked them, and sent them to her on Telegram.

She replied:

“Apply to #3.”

Ten minutes later, a tailored two-page resume landed in her chat as a clean PDF.

A friend of mine is job hunting.

I built this for her in one day.

I’ve been an engineer for 12 years. This is the fastest I’ve ever built anything. AI wrote most of the code.

And that speed hides a trap. This post is about the trap, and the way out.

Everything feels like magic now

Building with AI feels amazing. The code appears. It runs. You ship. You feel like a wizard.

Then it breaks at 2 AM. And you’re staring at a system you never understood.

You’re not alone. Nearly half of developers say fixing AI code takes longer than writing it. [1] And AI-written code carries almost twice the bugs of human code. [2]

Nobody ships bad code on purpose. They ship code they never looked at.

Ask why. Every time.

AI writes the code. But it also makes the decisions. Dozens of them. Silently.

Should this poll or use a webhook? Should this retry or fail loud?

Twelve years ago, you learned these answers the slow way. Years of code reviews. Production fires.

Now the world’s most patient senior engineer sits in your terminal. It will explain every decision it makes. But only if you ask.

So every time AI makes a decision, I ask the same four questions:

1. What’s the architectural decision you just made?

2. What principle is it based on?

3. What other options did you consider?

4. What are the trade-offs?

I call this Ask Why. Four questions, every decision.

Copy-paste version, for your next AI session:

You just made a design decision in this code. Answer four things:
1. What's the architectural decision you just made?
2. What principle is it based on?
3. What other options did you consider?
4. What are the trade-offs?
Keep it short. Then wait for my next instruction.

One day of building. Eleven system design concepts. That’s what those four questions bought me.

AI is the fastest system design teacher that has ever existed. If you keep asking why.

What the job agent actually does

You know how job hunting goes. Hundreds of posts. Most are noise. Reading them eats your evenings. So I automated a friend’s job hunt.

Here’s the whole system in four boxes:

job boards  ->  scorer  ->  Telegram  ->  resume drafter
 (fetch)       (filter)     (notify)      (on my reply)

Here’s a normal morning for it:

1. Every morning at 9, a scheduled job wakes up. It pulls fresh postings straight from company job boards. Real APIs, not scraping hacks.

2. Claude scores each job against the resume. Out of 100. Skills, role fit, location, company. Anything under 70 gets dropped.

3. The top five land in Telegram. 157 in. 5 out. Zero noise.

4. I reply “apply to #3.” A tiny relay catches the message and wakes a second agent.

5. That agent reads the full job post. It drafts a tailored resume and cover letter. Truthful. It rephrases. It never invents. Then it sends the PDF back to the chat.

6. A human clicks submit. Always. The bot proposes. We decide.

It costs about $0.15 a day to run. It took one day to build.

11 things this build taught me

Every one of these came from asking why. They fall into the four boxes you just saw.

Getting the data

1. API contract design. Four job boards. Four different data shapes. One small script per board turns them into one clean shape. The rest of the system never knows the difference.

2. Idempotency and dedupe. The same job shows up on two boards. A small file remembers every job we’ve seen, so you get one alert, not two. “Seen it already” is a feature. You have to build it.

Deciding what matters

3. Scoring pipelines. “Good match” is a feeling. Feelings aren’t repeatable. So the AI scores against a written rubric. 40 points for skills. 30 for role fit. 20 for location. 10 for company.

4. Precision vs recall. An agent that sends 50 “matches” a day gets muted in a week. So the gate is hard. Score 70 or more, or the job never reaches my phone. Some days it sends nothing. Empty days are correct. Noise is failure.

Reaching a human

5. Webhooks vs polling. Polling asks “anything new?” every minute, all day. Mostly the answer is no. A webhook is a doorbell. It rings only when someone is there. I chose the doorbell. Then I asked why, and learned when polling still wins: it’s simpler and needs no public URL.

6. Cron and timezones. “Run at 9 AM.” Sounds simple. But 9 AM where? Servers think in UTC. 9 AM Pacific is 16:00 UTC. And daylight saving moves it twice a year. Write the math in a comment. Future you will forget.

7. Fan-out notifications. Two people, two phones, one loop. Easy to build. Easy to forget to design for.

Shipping safely

8. Human-in-the-loop. Full auto-apply sounds cool. It’s also how you spam 100 companies with a broken resume. So the bot proposes and a human decides. Draw that line on purpose. Before the system draws it for you.

9. Secrets management. One leaked token and a stranger owns your bot. Tokens live in the environment. Never in the repo. Never in a screenshot.

10. Serverless relay. Catching a Telegram reply needs a public URL. Renting a server for one URL is silly. So the relay is one small function on Vercel. About 40 lines. Nothing to rent. Nothing to patch.

11. Document generation pipelines. Recruiters want PDFs. Screening bots want clean files they can parse. So markdown goes in, and a two-page PDF comes out. Same input, same output, every time.

Eleven concepts. One build. One day.

These aren’t toy lessons. Webhook plus scoring gate plus scheduled job plus human-in-the-loop. That’s the same pattern behind most production AI systems companies are paying for right now.

Want to run it yourself?

Full source code: github.com/Omsai92/ai-job-agent.

The README walks you through setup in about 10 minutes. Fork it, drop in your resume, pick your companies.

What happens next

I’m calling this series Under the Hood. Build 01 is this job agent, every decision explained. The webhook. The cron. The scoring gate. And exactly where it breaks.

Build 02 is a token-cost dashboard. Build 03 runs our dinner on a Git repo. $0 a month.

Every build lands here first, as a full log like this one. Subscribe and you’ll get each one in your inbox.

Build fast. Understand everything.

Become an AI engineer with me.

If you enjoyed this article, then hit the ❤️ button and share it with a friend or coworker who might find it useful too!

Did I overlook anything important? Feel free to drop a comment 🙋‍♀️🙋‍♂️

Thanks for being here,
Omsai Jadhav

Early in my career, I often reacted defensively and dismissed feedback.

This hindered my growth significantly; missed opportunities stemmed from either disregarding or poorly accepting feedback.

However, learning to accept feedback effectively transformed my career trajectory. Within 3 years, I ascended from mid-level to Staff Software Engineer, largely due to embracing feedback and continually improving.

There are many resources and articles on how to give feedback, but few on how to receive it.

Here are five mistakes I have made while asking for feedback, so you don't have to:

1. Not Seeking Specific Feedback

Stop asking: "Do you have any feedback for me?"

Why: You might hear generic replies like, "Keep it up. You're doing well."

Giving and receiving feedback can be uncomfortable. Let's make it easier for feedback providers.

Instead of generic questions, ask for specifics.

Example prompts you can use:

if working on communication skills:

“How was my communication with stakeholders during the last project?”

if improving coding skills:

"Have you noticed any patterns in my PRs? Any areas I should focus on? Recommended resources?"

If new to a team, inquire:

"How did I handle gathering requirements through questions? Any room for improvement?"

Seeking project design feedback:

“Thoughts on the readability of my design document?”

OR

“How could I improve my presentation to a larger audience?”

After addressing specifics, invite feedback on other aspects by generic questions.

2. Not Seeking Real-Time Feedback

You can bring something in progress for feedback, not necessarily from the past.

This helps you receive feedback on your thought process or approach.

Why:

It allows for immediate action, and we often learn from others who've been through similar situations.

This method has helped me avoid many mistakes and learn from others' experiences.

For example:

While refining my feedback-giving skills, I discussed my approach with my manager. I typically use the sandwich method but realized feedback sometimes gets lost, leaving only the positives.

Through our dialogue, I recognized I don't allocate enough time to feedback and focus more on positives. This makes the constructive part seem insignificant to the listener.

This discussion highlighted my blind spots, prompting further research on feedback techniques.

3. Seeking Validation and not Feedback

Asking for feedback just to get a pat on the back instead of real advice can stop you from getting better.

For example:

Using leading questions like, "Wasn't that presentation fantastic?" may prompt only positive responses, even if improvement areas exist.

Instead, ask:

"What areas could I have improved during the presentation?" or "Any suggestions for a different approach next time?"

It's normal to seek validation. But it's important to tell apart praise from real feedback for meaningful progress.

4. Ignoring non-verbal cues

Not paying attention to body language can make you miss important signs.

Even though it might be tough, especially when you're working from home, you can still catch these signs.

For example:

If someone seems unsure or avoids looking at you when giving feedback, you can mention their body language by saying:

"I noticed you paused before mentioning that. Is there something you're not sure about?"

This lets them know you're serious about feedback and encourages them to share more openly.

5. Getting defensive

I have been guilty of this many times. However, when you understand that:

the lack of some skill isn't a permanent flaw but a temporary challenge waiting to be conquered,

it will change your perspective towards feedback.

I suggest reading Mindset - by Carol Dweck, which helped me in managing anxiety when faced with areas of weakness.

While I still get defensive occasionally, it has significantly decreased.

I hope these tips help you get the right feedback and discover your blind spots.

But getting a ton of feedback can feel like too much if you're not sure how to handle it.

In the next article:

I'll discuss what to do with all the feedback you've received. Keep an eye out! :)

If you enjoyed this article, then hit the ❤️ button and share it with a friend or coworker who might find it useful too!

Did I overlook anything important? Feel free to drop a comment 🙋‍♀️🙋‍♂️

Thanks for being here,
Omsai Jadhav

Share

Great articles you don’t want to miss from my fellow writers:

• How to live balanced life as an Engineer? by

• Engineers, joining an early-stage startup isn’t financially worth it! by

• How to Master Salary Negotiations by

• Tired of Reviewing Code? Here's How to Make It Easier by

• Beyond Guesswork: The Art and Science of Project Estimation by

Why?

Too often, we prioritize learning tech before considering business needs. I fell into this trap early in my career—it's common post-college. Colleges don't emphasize business thinking.

After many mistakes chasing new tech, I've learned: prioritizing business impact is key.

Now, I focus on understanding the business problem first, then choose the right tools and tech.

This shift has profoundly boosted my career. I've learned tech practically and understand its limitations and future use cases.

Here's how I apply this mindset daily:

1) Focus on business impact

When proposing engineering-driven projects, focus on what problem you're solving

It should be doing one of the following:

1. Generating revenue

2. Expanding customer base

3. Cutting costs

Most tasks fall into these categories:

• Refactoring code → technical debt, slashing future development time and costs.

• Improving engagement → making money (ex. through ads)

• Improving user experience → growing/retaining customers

• Mentoring teammates → invests in individuals who can drive significant business impact in one of the above areas.

I can go on, but you get the point

Remember: You need to choose where to invest your time depending on the business need at that time.

For example, when it comes to choosing a project, you should choose one with the highest impact and lowest effort first and go from there.

You might ask, what do I do when I exhaust high-impact, low-effort projects?

Worry not, check out my LinkedIn post here where I talk about it

I understand not every project is engineering-driven; sometimes it is led by a project manager. Hence, my next point is:

2) Closely Align with Your Product Manager

Wear a product cap and think about the problem first.

Control the temptation to design a solution in your head the minute you hear the problem (I am guilty of doing this many times).

Instead:

1. Understand what and why first

2. Ask questions to grasp all dimensions, challenging assumptions.

3. Define the Minimum Viable Product (MVP) based on available tools and required solutions within a reasonable timeframe.

4. Negotiate with PM without losing focus on the problem you are solving

   Often, engineers become fixated on the "how," losing sight of the original problem and the customer's needs.

Picture credit: beyonddesign.com

Now that you understand what and why and have a clear understanding of the business problem

The story does not end there; you can take this mindset in solving how:

3) Using Data to Drive Design Decisions

So, you might be rolling your eyes and thinking, "Oh great, another spiel about data-driven decisions."

And hey, I totally get it; all the new project initiatives/features are driven from data insights and led by Product mangers.

So why do we as engineers need to worry about it?

This is a big mistake.

Here is an example of how I used data in making a crucial design decision.

When migrating a service from a monolith to a new one to create a materialized view for a marketplace app feature, I faced a choice:

1. Replicate the existing logic as is.

2. Simplify the solution based on the problem at hand.

I proceeded with option 2 and took data's help.

Analysis revealed that "97% of users have only 8 items listed on their profile."

This insight led me to realize that I could forego storing a materialized view and instead generate it dynamically without impacting the majority of users.

By optimizing the design accordingly, I delivered the project 1.5 months ahead of schedule, with improved latency and a much simpler architecture.

Next time you're faced with a major design decision in backend systems, leverage data for guidance.

4) Use Your Own Product Regularly

Many times we get so focused on building the solution; we forget to put ourselves in the customer's shoes.

Make a habit of using the product you're building.

For example, at Offerup, when we present anything to a larger group, the first slide contains our introduction along with a picture of the item we sold/bought. This practice fosters a product-focused mindset within the company and serves as a great icebreaker.

Consider implementing similar practices in your team or organization.

Even if you don't work in a B2C company, there are other ways to stay connected with your product:

• Engage directly with customers.

• Read public reviews.

• Review the Voice of Customer (VOC) data, typically available through your product manager.

• Schedule regular one-on-one meetings with your PM to gauge product performance.

• Learn to read Tableau or PowerBI dashboards.

• Collaborate closely with the data team to access relevant metric data.

The bottom line is: strive to embody the mindset of a business owner for your project, periodically thinking like a business person to drive success.

Other great articles on this topic from my fellow writers:

• From read here

• From read the product-minded software engineer

If you enjoyed this article, then hit the ❤️ button! Your support means the world to me. Feel free to share it with a friend or coworker who might find it useful too.

Did I overlook anything important? Feel free to drop a comment 🙋‍♀️🙋‍♂️

Thanks for being here,
Omsai Jadhav

Share

Today marks 10 years since I started in the industry. Throughout this time, I've worked in small, mid-size, and large companies.

Along the way, I stumbled, I fell, but most importantly, I learned.

Here is a curated list of lessons I've learned that I wish someone had shared with me when I took my first steps into the professional world.

Let’s dive in.

Subscribe now

1. Not Focusing on Learning

Avoid running after money, big names, or comfort early in your career.

A senior director who was also my mentor said something that stuck with me:

In the early stages of your career, you are valued for your potential, while later on, you are valued for experience, knowledge and what you can contribute

I have observed this in my career journey as well. Investing in myself early in my career opened up more opportunities later. This approach is efficient and will help you in the longer term.

So, focus on learning and gaining skills for the first 10-15 years in your career. Choose a job prioritizing learning and people > money, benefits, or comforts.

For the same reason, I try to learn something new every day, apart from what I learn on the job.

2. Not Using Manager as a Resource

I had a completely wrong notion about the manager's role at the start of my career.

I had this idea that being a lone wolf was the epitome of being a genius coder. I used to reach out to my manager in the extreme cases. This belief was the biggest hindrance in my growth at the company and caused uneasiness on the manager's side.

Recently stumbled upon a post by Taha, and it was like reading a page from my own early career diary.

By keeping information close to the chest, we unknowingly mold our managers into the micromanagers we dread. It's a classic case of shooting ourselves in the foot.

Over the years, I realized that using your manager as a resource and collaborating as a dynamic duo is the cheat code to career acceleration.

Seriously, this skill can fast-track your growth like nothing else. Take it from someone who's been there – be intentional and clear the air on what you expect from your manager.

Still skeptical? Explore various topics on how to engage with your manager effectively in previous post here

3. Being Sensitive to Feedback

Early in my career, I was like a feedback ninja – dodging and deflecting every piece that came my way. It wasn't that I didn't appreciate improvement; I just didn't handle it well. Defensive mode, activate!

Book: Mindset - by Carol Dweck changed the way I looked at feedback. Particularly this:

that the lack of something in me wasn't a permanent flaw but a temporary challenge waiting to be conquered.

Fast forward to today, and I've become a feedback junkie. I owe a big chunk of my growth to the feedback I've received and actually acted upon.

Here is what works for me:

1. Jot It Down:

   Every piece of feedback gets a spot on my notepad.

2. Come up with a concrete action plan:

   Find opportunities to flex those newly acquired muscles and show improvement in action.

3. Circle Back to the Feedback Giver:

   It's not just about proving I've listened; it's about building trust with the person who took the time to dish out the feedback.

   And guess what? Some of those feedback-givers evolved into my long-term mentors.

4. Not Having Mentors

In the earlier chapters of my career, I hesitated to seek guidance, fearing potential rejection.

However, as time unfolded, I recognized the significance of mentorship. Now, my most impactful professional moments stem from one-on-one sessions with my mentors.

People love feeling helpful. If they see sincerity, curiosity, and drive, they will go out of their comfort zone to invest their time in you.

Reach out to folks with the right attitude, and brace yourself for the wonders that mentorship can bring to your life. Whether it's someone within or outside your team, find that person you feel safe talking to and understanding.

5. Letting Imposter Syndrome Slow You Down

Early in your career, self-doubt can be a real buzzkill, and if left unchecked, it can cast a shadow on your future.

Spoiler alert: it never really packs up and leaves for good.

The antidote? Awareness. Wrap your head around the fact that feeling like a bit of an imposter is normal.

So, read up on it, dive into articles like this from and this from . Engage in meaningful discussions with fellow developers.

These resources, combined with the wisdom from the book "Mindset," served as my compass. They drove home the point that everyone is a work in progress, and skill refinement is a continuous process. Gratitude for mistakes became a cornerstone of my growth mindset.

So, when imposter syndrome comes knocking (which is not a rare occasion), I take it head-on. I seize the opportunity at hand, giving it my best shot. Over time, the results of my work reinforce my belief and confidence in myself.

6. Focusing Too Much on Promotions

Don't obsess over the next thing or the next level promotion. This robs the happiness and satisfaction of work.

If you are thinking about it all the time, you are more likely to take fewer risks. You'll start playing it safe, terrified of making mistakes, and overthinking what others might think.

It's a roadblock to rapid learning and growth. I confess; I've been down that rabbit hole early in my career, and it's a confidence killer.

So, here's the deal – shift your focus. Forget about the promotion for a moment. Instead, dive into the process, soak in the feedback, and make learning a daily ritual with a growth mindset.

Once you've aced these moves, crafting that promotion package becomes a breeze. Remember that getting promoted involves many factors, so understand what is within your control versus what is not. This will put you at ease and provide clarity on what needs to be done.

I hope you found the quick list helpful! Add your most impactful lessons from your career in the comments below.

Thanks to those who subscribed! If you haven't, please consider subscribing now

Subscribe now

Thanks for being here,
Omsai Jadhav

I missed out on opportunities due to lack of awareness. Don't repeat my mistake!

Here are the most impactful books that have changed me the most as a software engineer. Read these early in your career to benefit the most.

1. Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin

Coding is pretty much a never-ending gig, especially if you're on the individual contributor path.

It's not just about creating cool features or giving instructions to a computer; you're basically turning business requirements into code. And here's the kicker: you want to create code that others can easily grasp and build upon.

This book laid the groundwork for me and dispelled coding myths.

2. The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin

This book is all about attitude!

Behavioral tips from this book helped me level up from an amateur to a professional software engineer. It covers:

• Employee expectations

• Employer expectations of you

• Conflict resolution framework

• Achieving work-life balance, and more.

3. Mindset: The New Psychology of Success by Carol S. Dweck

Struggling with asking questions or seeking help?

My journey as an SDE at Microsoft started with this struggle.

This book shifted my mindset, emphasizing that “everyone is work in progress”. It taught me “fundamental abilities can be developed through dedication and hard work—brains and talent are merely the starting point”.

Now, I proudly ask questions.

It has also helped in dealing with Imposter Syndrome, a common challenge at various career stages.

4. The Manager’s Path by Camille Fournier

A comprehensive guide on the role expectations in the management chain, from mentoring a single person → leading as CEO.

Reading the first few chapters of it helped me greatly in my career.

My main takeaways:

• What to expect from my manager

• How to take control of your career

[Check out my earlier articles 1 and 2 where I talk more about this.]

5. How to win friends and influence people by Dale Carnegie

This book helped me:

• Become a leader and influence others

• Took me from independence to interdependence

• Opened my eyes to how humans function at their core

I found myself effortlessly stepping into others' shoes during conversations. This simple skill has supercharged my ability to influence others.

Parting thoughts:

A quote I read on Instagram goes something like this -

If you imagine all the knowledge to be contained within a circle,

• then one small part of that circle is 'What you know'

• A slightly bigger portion is 'What you know you don't know'

• The largest part of the circle, however, is 'What you don't know you don't know'

Lesson: There is so much untapped wisdom out there that we are completely unaware of—wisdom that can dramatically shift our paradigms.

I hope you found the quick list helpful! Add your most impactful books in the comments.

If you enjoyed this article, then hit the ❤️ button! Your support means the world to me.

Thanks for being here,
Omsai Jadhav

How often does your mind get lost in finding solutions as soon as you hear a problem statement?

When I excitedly jump into problem solving, I find myself going in the wrong direction and ending up redoing the whole thing.

This approach isn’t the most efficient way to reach a solution. It leads to missed deadlines, wasted efforts and affects team morale.

Getting clarity on the problem first is the most efficient way to arrive at a solution.

Let me explain..

The wrong approach: Focusing on the How first

For example:

Let's say you are starting to work on a new task or project.

What would be your approach to tackle this? Think about the last task you completed at work. Pause for a bit and recall the steps you took.

Before: I used go back and forth between how and what/why

This is how I used to do it before:

• Read the requirements

• Immediately start thinking about solution.

• I ask a few questions to clarify how the requirements would fit in the solution.

• When requirements don't fit, I tweak my solution. I repeat this process.

• I deliver a solution with the best quality code.

• People start testing the feature, issues come up. Some cases fail.

• Now I go back and tweak my solution even further to accommodate those.

• After a few rounds of this, now the best quality code starts looking ugly.

• I ask for more time to refactor the code to make it cleaner.

• After a few rounds of this, I deliver the solution.

When I use the above approach, I encounter many roadblocks and experience frustration when I discover new things that I haven’t thought of before. There is back-and-forth in understanding the problem better and tweaking the solution as I gain more clarity.

A lot of effort is unnecessary, even though I feel productive and am doing a lot of things; however, I move forward slowly.

This approach results in:

• Wasted efforts

• Delays in shipping features

• A significant number of bugs

• Multiple rounds of testing and QA resources

• Overall decreased team efficiency

Let's see if we can solve the above issues by hyper-focusing on the problem first.

After: I now focus on "why" and "what” first

I now restrain the urge to immediately think about solutions (the "how" part).

To achieve this, I wear a product manager's cap, temporarily distancing myself from my engineering role.

Questions I ask to understand the problem/task:

1. What is the business value?

2. What is the problem it is solving?

3. Why now?

4. Have we considered other alternatives? If yes, why did we choose this? If not, can we brainstorm on this?

5. What is the priority of the task?

6. What is the success criteria for this?

7. Should we be doing this in multiple parts? Starting with MVP and building on it?

I am surprised how many times the requirements got changed, and the scope of the project got altered because somebody has the right questions.

then I move on to the “how” part

Once I have satisfactory answers to my queries, I transition to the "how" part and put on my engineer's cap. I won't bore you with another list of questions you should be asking, but you get the drill.

When I do this, the number of times I needed to make drastic changes to my solution was negligible.

I still need to go back and forth wearing these caps during the project. Sometimes I discover some limitations/opportunities once I dig into the how part. I discuss that with product managers and decide the path forward.

But, the number of times I go back and forth is significantly less compared to the previous approach.

So, the difference between the first approach and the second is that I was hyper-focused on the problem in the second approach. All my questions were targeted to get more clarity on the problem itself first and then move on to questions about how do I solve it.

I have found this to be the most efficient way to deliver any task I work on. And in my experience, this has reduced the number of bugs drastically as well.

Now, let's talk about practical steps to achieve this..

A Structured Approach:

1. Write down a list of questions

I highly recommend writing down these questions as you work through both what/why and how parts.

Writing down gives order to chaos in your head. This is not a new technique, therapists suggest this in the form of a journal to get more clarity. I am extending the same idea here but focus on questions and only questions.

2. Organize your questions

Organize your questions. Figure out which questions you want to tackle first.

The key is to progress from basic queries to more refined ones.

3. Take a break

Take a break and let your mind rest. Engage in other activities without consciously thinking about the problem. Your subconscious will continue working on the questions. Insights will emerge like pieces of a puzzle, and your mind will naturally connect them. Soon, you'll discover the answers.

Having clarity on the questions beforehand allows your subconscious to work while your conscious mind focuses on the task at hand.

4. Answer the first question on your list.

That is, solve the first problem. Strike it down! This action sets the stage for building momentum.

5. Proceed to the next item on your list.

Add more questions as you come up with them. If required, go back to step 2, reorganize your questions, and move to step 3 and so forth.

Parting thoughts:

Right questions steer you in the right direction and enable you to get back on track fast. They guide conversations, much like a good tennis match, facilitating a back-and-forth flow. These questions develop capacity and potential in others, creating those "aha moments" in your team and with your team members.

Developing this one skill to focus on getting clarity on the problem first will help you grow faster in your career and all aspects of life.

I'll leave you with some of my favorite quotes on this topic":

Oprah Winfrey: “Ask the right questions, and the answers will always reveal themselves.”

Albert Einstein: “If I had an hour to solve a problem…I would spend the first 55 minutes determining the proper questions to ask, for once I know the proper question, I can solve the problem in less than five minutes.”

I hope you found these tips useful!

Did I overlook anything important? Feel free to drop a comment 🙋‍♀️🙋‍♂️

If you enjoyed this article, then hit the ❤️ button! Your support means the world to me. Feel free to share it with a friend or coworker who might find it useful too.

Thanks for being here,
Omsai Jadhav

At the start of my career at Microsoft, I used to dread these one-on-ones. I would be relieved when my manager was busy and rescheduled them to other times. When we did have these meetings, they often ended in less than 10 minutes. I would provide my update and assure everything was going well when she asked if I needed any help.

Being an introvert was a part of it, but I came to realize that it hindered my growth, and I felt stuck. After my first performance review cycle, I had to take a good look at myself. I received a good amount of feedback from my manager, which came as a surprise to me because, in my head, everything was going great.

I had to revisit every aspect of my profession. One significant aspect I worked on is my relationship with my manager and how to conduct effective one-on-ones.

I have been honing this skill since then, and I can tell I have come a long way. I grew significantly as a software engineer because of it. And now, my one-on-ones are more meaningful and productive.

Here are some topics I've listed that might be helpful in your next one-on-one. I have also expanded on each topic, explaining why you should bring it up and its importance.

You don’t have to cover all these topics in one go; choose depending on the situation and where you are at the moment.

1. Discussing Personal Life:

Allowing your manager a glimpse into your life is crucial. It doesn't mean you need to spend the entire time talking about hobbies, families, or weekends.

Building this connection makes it easier to request time off, especially during stressful personal situations.

2. Feedback:

Waiting until performance reviews for feedback is never a good idea. It creates a long period of uncertainty without any guidance. Mistakes and screw-ups are inevitable, and timely feedback is crucial for growth.

I recommend keeping track of all feedback, both positive and negative. It will help you look back and see the progress you've made. It also comes in handy during performance reviews.

3. Setting Goals:

You should be very intentional about your short-term and long-term goals. And make sure you align those with your manager early on.

I recommend writing them down in a shared document with your manager and tracking these regularly. It makes you accountable, and the shared clarity enhances your chances of promotions.

4. Promotion Talks:

If you're aspiring for a promotion, proactive communication is key. Don't assume your manager will offer you one without you initiating the conversation. Take the initiative to discuss your promotion openly.

Familiarize yourself with the promotion process within your company. Work with your manager to build a promotion packet. Starting this process early demonstrates your commitment.

I find Jordan's article on how to frame your promotion conversation here very useful.

5. Projects:

Picking projects that match your goals usually keeps you motivated and makes it easier to achieve them.

Managers typically have insights into future plans and are aware of what's on the horizon. Expressing your interest in specific projects early on allows you to collaborate with your manager.

This approach ensures that you're working on projects you're passionate about.

It's surprising that many people don't take this initiative and end up working on projects and tasks assigned to them.

6. Making Sense of "Why" Behind Work:

Sometimes, our job could look mundane and without purpose. Understanding the "why" behind your work is vital for motivation and job satisfaction. Don't hesitate to ask your manager where your tasks fit into the bigger picture of the business or team goals.

When you grasp the significance of your role in the larger context, it becomes easier to stay motivated and engaged. It also enables you to align your efforts with the objectives of the organization.

7. Trainings/Other Resources:

Inquire about conferences or training programs that align with your discussed goals. Managers often appreciate employees who show initiative in their own growth and development.

8. Asking for Advice:

When dealing with tech stuff, it's normal to ask for feedback on your code or design documents. But, when it comes to navigating the complexities of the workplace, tapping into your manager's wisdom can be invaluable.

Whether you're dealing with a tricky coworker or facing a tough situation that requires guidance, your manager can provide valuable insights.

I hope you found these tips useful! They're the nuggets of wisdom I've picked up from some fantastic mentors and managers along the way.

Did I overlook anything important? Feel free to drop a comment 🙋‍♀️🙋‍♂️

If you enjoyed this article, then hit the ❤️ button! Your support means the world to me. Feel free to share it with a friend or coworker who might find it useful too.

Thanks for being here,
Omsai Jadhav

We often place a lot of responsibility on our managers to shape our experiences and guide our careers (I admit I've been guilty of this), but I firmly believe that the relationship with our manager is a two-way street, just like any other close interpersonal relationship.

It's crucial to develop a sense of ownership and authority over your own work experience, instead of depending solely on your manager. Taking charge of your own experience at work is a vital step in shaping your career and finding happiness in your workplace.

At the forefront of this journey is taking ownership of your 1-1 meetings.

Main Takeaways

Here's what we'll be discussing:

1. Regular 1-on-1s: Why having consistent catch-ups with your manager is essential for clear communication and mutual understanding.

2. Effective Agendas: How setting meeting agendas boosts productivity and keeps discussions on track.

3. Note-Taking: Using shared documents to jot down important points discussed with your manager, strengthening your professional relationship.

4. Expanding 1-1s to Senior Team Members: Expanding your 1-on-1s to include other senior colleagues for diverse perspectives, collaboration, and sharing knowledge.

   ---

Let’s dive in…

I have a few tips to share with you on how to have effective 1-1s with your manager, which can significantly enhance your performance in your current job.

But first, let's clarify what 1-1 meetings are all about.

These one-on-one meetings provide dedicated time for you and your manager to discuss anything you want. This time is yours. However, it's common to feel like we don't have much to talk about, leading us to believe these meetings aren't necessary on a regular basis. Yet, as Camille Fournier aptly stated in her book, The Manager's Path, "Regular 1-1s are like going to a psychiatrist when you're fine and discovering you have depression."

Now, let's explore some key tips to make your 1-1s with your manager more effective:

1. Schedule Regular and Predictable 1-1s

One common issue in many workplaces is the irregularity of one-on-one (1-1) meetings. Managers often neglect these sessions, postponing them due to perceived inefficiency or lack of productivity.

To address this challenge, my advice is to proactively establish a consistent schedule for your 1-1 meetings. Regardless of whether you are a new hire or a seasoned professional, make it a priority to set up these sessions from the beginning. If the meetings are not already on the calendar, take the initiative to schedule them regularly, ideally on a weekly or biweekly basis. For newcomers, starting with weekly meetings is recommended. Over time, as you understand your manager's preferences, you can adjust the frequency accordingly.

Begin by allocating a 30-minute slot each week for your 1-1 meetings. If your manager is not accustomed to scheduling these sessions or tends to postpone them indefinitely, initiate communication. Politely inform them, "I've scheduled our next 1-on-1 meeting and outlined the topics I'd like to discuss. Does this time work for you? If not, please let me know a suitable alternative. I am eager to cover these points with you." Taking this proactive approach ensures clarity and consistency in your communication with your manager.

2. Set an Agenda

Providing some structure to the meeting can significantly enhance productivity and efficiency. Having a predefined agenda ensures both parties know what to expect. You can create this agenda and share it in the calendar invite, Slack, or email—whichever communication platform suits you—prior to the meeting.

3. Take Detailed Notes

Take detailed notes during the meeting, capturing all major insights and feedback, whether positive or negative. Create a live document that you share with your manager. Both of you can update it regularly. This document can include the agenda for the next meetings and any feedback your manager provides. Keeping this record allows you to track your progress over time. I've been doing this for the past five years, and it has been immensely helpful. Having a documented history of feedback and improvements can be valuable during performance reviews.

You can use this simple format which works for me:

4. Expanding 1-1s to Senior Team Members

If you haven't already, consider scheduling 1-1s with other senior engineers, skip-level managers, or directors in your company. It's a good practice to talk to them first before initiating these meetings. Having 1-1s with various team members will give you a broader perspective of the company. You can exchange ideas and bring different perspectives from various teams to yours and vice versa. This will accelerate your growth and foster a more collaborative environment within the company.

I trust you understand the significance of one-on-one meetings. However, effective 1-1s go beyond mere status updates. It's common to be uncertain about suitable discussion topics. For guidance on what to discuss with your manager during these sessions, check out my second article here.

TL;DR:

• Take Ownership: Your relationship with your manager is a two-way street; don't rely solely on them to shape your work experience.

• Effective 1-1 Meetings:

  • Regular Meetings: Schedule consistent 1-1s, ideally weekly or biweekly, to ensure communication.

  • Structured Agendas: Set meeting agendas beforehand to enhance productivity.

  • Detailed Notes: Keep comprehensive notes on feedback and progress for performance reviews.

  • Expand Meetings: Have 1-1s with senior team members for broader perspectives.

For guidance on what to discuss with your manager during these sessions, check out my second article here.

I hope you found these tips useful! They're the nuggets of wisdom I've picked up from some fantastic mentors and managers along the way.

Did I overlook anything important? Feel free to drop a comment 🙋‍♀️🙋‍♂️

If you enjoyed this article, then hit the ❤️ button! Your support means the world to me. Feel free to share it with a friend or coworker who might find it useful too.

Thanks for being here,
Omsai Jadhav