This serves as a reminder/guide/aspiration for myself first and foremost. Some days you perform better than others. The goal is to be a cracked dev every day.

I recommend creating a daily mantra you read every morning for the things you're weak at.

I've been at many early stage startups. So I'm writing this to my younger self. These are more or less observations I’ve seen in real practice and admire.

Get technically good

First thing, get technically good. Honestly, the only way here is to build a lot of things. Build like crazy. Build a lot of side projects. Dig deep into several areas. Have breadth but at the same time depth.

The goal is to be able to ship fast while at the same time trying to find simple solutions to complex problems.

Is what you're working on important?

Ask yourself every day, what I'm working on, is it important?

Priorities change day by day, week by week, what you worked on yesterday might not be the most important thing to work on today for the company.

Say no

It's easy to just say yes to everything. By default, say no to things that aren't top company priorities.

If yes, communicate what you're working on and don't give false promises.

Leading a project

Don't make scope too big

Don't make scope too big. Think about the minimal thing to ship to customers so you can iterate based on feedback.

Overcommunicate how it's going

Overcommunicate how it's going. Make sure people are aware of the progress. Make sure it's clear what's being done + why it's being worked on now (should be done before project starts).

Single place for communication

Make sure there's a single place for communication. A place all stakeholders can go to to understand the progress + if the project is on track.

Linear Project Updates are perfect for this.

Be a driver

If you see something that should be fixed, fix it. Make a PR and ship. If it's something you don't know how to fix, make sure to raise awareness plus make sure it gets shipped.

For me, this often means asking the person who knows how to fix it how to do it so that I can learn and next time it occurs I can fix it myself.

Dealing with discussions/disagreements

When discussions happen, ask yourself, what's the fastest way to get to action here? How can we get “data” whether we’re on the right track or not?

Surprisingly many discussions can be shut down by having someone do prototypes and see how things work. It's easy to discuss and talk about things. But getting to the action and shipping is what matters.

Remember, in discussions, always take a step back and ask yourself "why?". Your idea is an idea among ideas. The goal is figuring it out as a team.

Talk to users

Talk to users. Talk to them every day. What problems do they have? What do they like/dislike? How are they actually using the product?

You will be surprised how little devs talk to users. It makes you so disconnected from the product if you don't do it.

Dogfood

Use the product. Use it with intentions same as your users. You will come up with more ideas. You will notice things that need to be fixed (then you ship the fixes).

Spend time doing this. It's much more important than you think.

Think like a founder, as if it's your own company/product

The key to really becoming a cracked dev is to think like a founder. As if it's your own company/product. You're gonna do everything you can to make it successful.

The devs I’ve worked with who do this re the ones I admire the most.

Even if you don't have the motivation to do so, see it as a learning experience for yourself when you go on and start your own company. That'll serve as motivation for thinking like a founder and really pushing yourself in the company to do your best work.

A lot of people ask me how to be more effective when learning. So I thought of writing some thoughts down here. I guess mainly to my younger self.

Read the error message

When you get an error, read the error message. A lot of the times, just reading and understanding the error message is enough to fix the issue. Plus often you learn new things how the library/framework works under the hood. Very easy to miss.

Read a lot of documentation with AI

When learning a new library or framework, read the documentation. Read it carefully. Copy paste the entire text into AI. Talk with AI about it if you've any questions. Play around with the code examples they have there.

From experience, spending time upfront reading a lot of the documentation is a cheat code to shipping faster. You automatically avoid running into common issues that other people will typically run into.

This is what I’ve done myself when working with e.g.

• Tldraw SDK

• React Flow

• Convex

• …

Follow your curiosity

If something interests you, follow your curiosity. It's fun. It's a great way to learn. When things are fun, you're more invested.

At the moment, I’m building a silly multiplayer game. It’s a racing game. Mainly because I wanna play it myself with friends.

Learn different things

Learn a lot of different things. Don't just focus on a single thing. When you learn a lot of different things, learning new things become easier because you've consistently put yourself in the position where you need to start from the beginning with zero knowledge.

What I’ve done for example early in my career is to build side projects with different libraries or frameworks. It’s not to become an expert I’d say, but to gain breadth.

Build from scratch

To achieve mastery, I really recommend building things from scratch. I've built things from scratch such as React itself. You learn how things really work.

I recommend giving a shot yourself, thinking from the outside, with the DX how you would build something from scratch.

You will fail a lot. It's fine. I've tried rebuilding React from scratch 4 times actually lol. I recommend giving it a shot and struggling a lot before you dig into the open source code and learn the actual implementation.

Build a lot of fucking things

Build. Build. Build. Tie things together. Ship. Get stuff working. Show some cool demos in public.

Ask a lot of questions

This doesn't just refer to work. Ask questions everywhere. In communities, colleagues, on hackernews, reddit, etc.

Never let your known unknowns grow. Eliminate them asap. Make sure to ask a lot, no matter where you are, and learn from range of people.

Teach others

To teach is to learn twice. I've said this before. Make sure to write blog posts. They serve as good reflection + helps you detect gaps in your knowledge since you've to thoroughly explain things.

What I currently do for the most part

• Build a lot of things.

• Write blog posts time to time.

• Read a lot of documentation.

• Learn/build different things -> solve different kinds of problems -> expand your knowledge exponentially.

Good books contain concentrated wisdom from developers with years of experience.

Set aside 20-30 minutes daily for reading. This small habit compounds dramatically over time. Start with classics in your specialty, then branch out to adjacent fields.

Don't just read technical books. Mix in books on communication, psychology, and business to develop a well-rounded perspective that will set you apart.

Always be building something

Nothing improves your skills faster than building real projects. Theory only takes you so far, you need to put in the reps.

Keep a side project active at all times, even if you can only dedicate a few hours weekly. These projects let you experiment with new technologies without the constraints of work projects.

The key is consistency. A little progress each day is better than sporadic marathon sessions. Your GitHub profile becomes a portfolio of your growth journey.

Write regularly to solidify your learning

Writing forces clear thinking. It's one thing to understand a concept, but another to explain it clearly.

Block off dedicated time (I like taking one full day every other or third week) for writing, reading, and reflecting. This reflection time helps you internalize what you've learned and identify gaps in your knowledge.

Writing helps you find opportunities too. Blog posts about technical topics show employers and clients what you know and how you think, often better than a resume can.

Do things in public

Share what you're working on and learning about. Being open about your work creates opportunities you'd never get by keeping to yourself.

Get in the habit of putting your code out there, writing about what you're learning, and joining tech discussions online. Getting feedback from others helps you grow faster.

In tech, who you know matters as much as what you know. Go to meetups, help with open source projects, or join online communities. Build relationships consistently, don't just reach out when you need a favour.

Consistent sleep schedule

As developers, it's so easy to mess up your sleep schedule. I know it myself. When you got some hardcore bugs especially that you badly wanna solve, you can stay up all night.

But honestly, it's not worth it. A good sleep schedule is what will make you extremely productive as a developer.

I was fortunate to interview with many startups earlier this year. When I interviewed with Lovable, they ticked every single green flag. They were amazing. Still feels surreal to have joined. I wake up excited working with amazing people on something revolutionary every day.

Green Flags: Signs of a Healthy Startup

Transparency across all areas

They openly share information about funding, challenges, and company direction. Nothing feels hidden or sugar-coated during interviews.

Kind, respectful team members

Everyone treats you with respect during the process. No condescension or power plays. They value your time and contributions.

Meeting your actual future team

They ensure you meet the specific people you'll work with daily, not just the hiring manager or executives. This shows they understand team dynamics matter.

Practical interview process

Their process tests relevant skills through realistic scenarios. No arbitrary puzzles or requirements disconnected from the actual job.

Supporting your interview success

They provide clear instructions, answer pre-interview questions, and set proper expectations. They want to see your best work.

Flexibility and adaptation

They're willing to adjust the process for your needs or circumstances when reasonable. Shows they value people over rigid processes.

Clear business model and funding

They can articulate exactly how they make money and their funding situation without vagueness or trying to sell you a bunch of bullshit.

Honest about challenges

Leadership openly discusses current challenges and past failures, not just successes and vision. Shows maturity and realism.

Upfront about the work

Some startups sell you work-life balance. The reality is that you'll be expected to work hard. If they're upfront about the life at a startup, that's a good sign you'll be working with honest people.

Red Flags: Warning Signs to Watch For

Vague answers

They can't or won't answer direct questions about business metrics, funding, or company challenges. Often indicates deeper issues.

Belittling or undermining behavior

Interviewers who make you feel small or mock your background are revealing a toxic culture that rewards dominance.

Impractical process

Their interviews don't actually test for the skills needed in the role. Shows misalignment between hiring and actual work.

Unusually slow communication

Long delays between interview steps with no explanation usually means the company is disorganized and has internal problems. This will make your job harder if you work there.

No team interaction

If they refuse to let you meet potential teammates, they're either hiding culture problems or don't understand team dynamics.

Urgent hiring with vague reasoning

"We needed someone yesterday" without clear explanation often means poor planning or unrealistic expectations. Or they're hiring/firing people like crazy.

Funding ambiguity

Vague answers about runway, burn rate, or financial stability. A healthy startup has clear metrics here even if challenging.

"We're like a family" emphasis

This often masks poor boundaries, emotional manipulation, and unreasonable expectations for loyalty despite business realities.

Unclear product roadmap

If they can't explain where the product is going and why, it suggests strategic confusion that will affect your work.

Perks over substance

Too much focus on office perks, parties, or culture instead of the actual work, compensation, and growth opportunities.

Unexplained high turnover

If many people have left the role or team recently and they struggle to explain why, this is a major warning sign.

Glorification of overwork

References to "hustle culture," unlimited vacation that no one takes, or expectations of constant availability reveal unhealthy expectations.

No clear success metrics

If the hiring manager can't articulate what success looks like in the role after 6-12 months, you'll have moving targets and unclear expectations.

What to do with these flags

Keep taking notes throughout the interview process. A few red flags might be explainable, but patterns matter. Trust your observations, not just what you're told. Remember that you're evaluating them as much as they're evaluating you.

When I first started coding, I thought being a software engineer was just about writing code. Years of working at startups taught me it's really about delivering value through thoughtful, well-executed features and products.

I kept running into the same challenges: unclear requirements, scope creep, and the dreaded "why are we building this again?" conversations. This is the guide I wish I had, a practical framework for taking features from idea to successful delivery.

Whether you're building a small feature or an entire product, these principles will help you ship with confidence.

1. Understanding the Why

Before anything, you need to stop and ask: "What problem are we actually solving here?"

I've learned the hard way that skipping this step leads to building the wrong thing. Your project could even get stopped.

Points to go through:

• Who is this for? Get specific about your users: their context, pain points, and what success looks like for them.

• What's the core problem? Not the solution you're thinking of, but the actual underlying issue.

• Why now? Understand what makes this a priority over other potential work.

• Have we tried solving this before? Or a similar problem? If yes, what didn't work and why?

A strong "why" helps you:

• Push back on unnecessary features

• Make better technical decisions

• Keep the team aligned during development

• Actually deliver something valuable

For example, instead of "we need a carousel component," you should be thinking "users need a way to quickly browse multiple product images without leaving the page."

2. Success Definition

Now that we know why we're building this, we need clear targets. Without metrics, you're shooting in the dark.

Points to go through:

• What metrics actually matter? Don't track everything, focus on what proves you've solved the problem

• How will you measure success? Get specific about the numbers (if suitable)

• What indicates failure? Know when to pivot or roll back

• Where's the business value? Connect your metrics to company goals

A good success definition:

• Has clear, measurable goals (e.g., "reduce load time to under 2 seconds" not "make it faster")

• Includes both user and business metrics

• Sets realistic timelines

• Has stakeholder agreement

For example, instead of "improve the checkout experience," you should define "reduce abandoned carts by 20% in the first two weeks after launch."

3. Initial Scope

After defining success, you need to be ruthless about scope. What's the smallest thing we can ship that validates our assumptions?

Break it down into two paths:

Happy Path:

• What does a perfect user interaction look like?

• What features are absolutely required for launch?

• What can we push to v2? Be aggressive here

Unhappy Path:

• Where can things go wrong?

• What's our fallback for each failure?

• How do we handle poor conditions?

Let's use a real example, building a product image viewer:

Happy Path:

• User sees the main product image

• User clicks through additional images

• Images display at the right size and quality

Unhappy Path:

• Image fails to load? Show placeholder with retry

• Slow connection? Show progressive loading

• No JavaScript? Fall back to static grid

• Mobile? Support basic touch gestures

Everything else: animations, zoom, sharing features - can wait. Ship small, learn fast.

4. Data Model & API Design

With scope defined, let's map out your data and API surface. Keep it high level.

Core questions:

• What are your main entities?

• What data lives on the server vs client?

• What API endpoints will you need?

For example, an e-commerce feature:

Server Entities:

• Product (name, price, status)

• Order (items, payment status)

Client State:

• Cart (items, total)

• UI states (selected options, form data)

API Surface:

• GET /api/products -> Product[]

• GET /api/products/:id -> Product

• POST /api/orders -> Order[]

The goal here is to do this at a high level, without getting into the details.

Side note before technical approach

If the technical approach isn't clear after modeling your data, I recommend taking a step back and writing a spec. If you work in a team, these are commonly called RFCs (Request For Comments). Now, exactly what you call them isn't important here.

The goal would be to:

• Get the problem on paper → what exactly are you trying to solve?

• Research existing solutions → how have others solved this?

• List out approaches → what are your options and their tradeoffs? What makes sense “now”?

5. Technical Approach

Time to get into the details. Whether it's a startup's v1 or a new feature in a mature product, break it down into clear pieces.

Think about:

• Break v1 into clear tasks

• Critical paths that need extra attention

• Edge cases and error handling

• Where performance matters most (sometimes it doesn't at all, be pragmatic)

• What and how to test

For example, building a checkout flow:

• Break down the flow (cart, shipping, payment)

• Handle edge cases (network errors, validation, timeouts)

• Focus on payment processing reliability

• Test critical flows (successful purchase, common errors)

• Start simple, optimize later if needed

Remember: you can always improve things later, but you need to ship first.

Feature Flags

If you're shipping a new feature in an existing product, you'll want to use feature flags. This lets you test in production and roll back quickly if needed.

6. Safety and Monitoring

Once you're ready to ship, you need to know if things are working. Set up monitoring before release, not after something breaks.

Watch for:

• Where are users getting stuck?

• What errors are happening?

• Are we hitting our performance targets?

• Are we meeting success metrics?

For example, in a checkout flow:

• Track completion rates

• Monitor payment errors

• Watch page load times

• Track cart abandonment (this one is really interesting for a checkout flow, you want people to pay haha!)

Keep monitoring focused on what matters, if a metric won't trigger action, don't track it.

Popular tools for monitoring:

• Sentry for error tracking

• Datadog for performance monitoring

• PostHog for user behavior tracking

7. Rollout Plan

Time to ship, but do it safely. Every release needs a clear plan, even if it's just v1. And to be very clear, it's different for a feature vs a product. It can be the same, but it's not always.

For a startup, you want to consider not launching it to everyone. Maybe you want to launch it in stages:

1. Internal testing.

2. Private beta.

3. Public beta.

4. Public release.

Think through:

• How will you test before users see it?

• Who gets access first?

• What would make you roll back (e.g. too many critical errors during checkout)?

• How do you know it's working (user behavior, metrics)?

For example, launching a new checkout:

• Test internally first (team orders)

• Release to 10% of users

• Monitor error rates and completion

• Roll back if errors exceed 2% (just an example)

Keep your first release small and controlled, you can always speed up rollout if things look good.

Conclusion

This isn't a strict framework. Tweak it to your needs if you want.

It's a good one to follow though.

One thing you'll notice, the whole point of software engineering:

1. Deliver value.

2. Make sure we delivered value.

3. Not work on the wrong thing for too long (original Agile definition).

Think of other fields where you don't have the "soft" part e.g. construction. It's not just hard to change something that's done but also while you’re doing it. Which is why it requires the waterfall approach where you plan everything out from beginning to end before you start.

I think because software is so easy to change we sometimes underestimate the complexity that builds up over time.

When you think of yourself as a product engineer, a question you should always ask yourself: "What's the simplest thing that could work? If I removed any requirements or loosened any constraints, how much of a simpler solution could I come up with?"

If you realize by removing 20% of the requirements, the problem becomes 60% simpler, you should probably do that.

This isn't always the case of course! But it's good to keep in mind. Every time you're presented with a problem, focus on understanding the problem. Don't always think about solving the problem but rather thinking from a "simplicity-first" perspective.

Even if you're far away from solving the full problem, it's ok. At least thinking "What can I do here to improve the situation (towards solving the full problem) with little complexity as possible?" is a good habit to have.

At least you can compare the "optimal" solution with alternatives. Then evaluate customer value delivered vs complexity added.

One of the things you learn in the Navy: Slow is smooth, Smooth is fast.

It's about how going slow is ultimately the way to go fast.

In this post, I want to share how it applies to different areas of software development and life.

This quote is so powerful when intentionally applied.

Learning

When you learn something, take your time. Don't rush. You may get things to work. But that doesn't mean you understand how it works. Ask a lot of questions. Don't be afraid of taking more time to let the knowledge sink in.

When you do NOT learn thoroughly, you may find yourself coming back to the same topic or encounter problems you could've avoided in the first place by deepening your understanding.

And I won't lie, speaking from experience, it has happened to me so many times.

By learning things the thorough way, you will find yourself wasting less time having to re-learn the same things over and over.

Solving a bug

When you solve a bug, take it slow. Focus on narrowing down the problem and understanding the root cause. If you understand why it's happening, you will know the solution.

If you enounter a tricky bug, ask yourself: "How can I narrow down the problem?"

From there, you can start to take steps towards figuring out the solution.

I've found myself being very effective in debugging when I'm relaxed and simply focus on understanding WHY the problem is happening.

Leading a project

One of the mistakes I made when leading my first projects was being hasty.

This led to multiple issues:

• Estimates were way off.

• Project ended up being a disaster.

• Stakeholders weren't fully aligned.

• More unknowns than expected were introduced.

It's better to spend more time upfront planning. Get all stakeholders aligned and make sure to clear up any known unknowns. Of course, unknowns may appear in the future. But if you know CURRENT things you could get more clarity on, it's better to spend time gaining more clarity.

By getting all stakeholders aligned, I mean making sure that everyone is on the same page about what the project's definition of done means.

To achieve more clarity, you may need to do prototypes or RFCs.

By spending more time upfront planning and researching, you will also be able to give a better estimate for the project.

Yes! Estimates aren’t meant to be perfect, but they shouldn’t be way off. This is important for the business to thrive.

The best thing you can do anywhere is to use the product.

Use it. Understand the problems it solves. Since you come in with fresh eyes, it’s easy to come up with ideas on how you can improve it.

If anything is confusing, ask questions. Those questions can lead to new ideas. Ideas you can contribute with and instantly stand out as someone who isn’t just a factory worker. But someone who cares about the business, product and takes ownership.

Ask about the business

Learn more about the company’s origin story. Understand the core vision.

Learn about the users. Watch customer research videos. Learning how users use your product will validate the assumptions you had. We all assume our users use the product in a certain way.

However, these assumptions must be validated. It’ll also help you contribute with even more meaningful ideas.

Review past issues

Look at past issues the team has had. This will help you be more effective when encountering the same or similar issues.

This doesn’t just have to be post-mortems, but can also be bug fixes. You can find them looking at past tickets or pull requests.

Look into the process of solving those bugs. Some teams have “runbooks”, documents used to describe the process of solving issues that may arise again.

Set up 1:1s with teammates

I strongly recommend setting up 1:1 meetings with your new teammates. This isn’t just an opportunity to build relationships that go a long way, but to learn:

• Recommendations to work effectively within the team.

• Important things to know.

• Recent issues and how the team overcame those issues.

• Resources to learn more about the business domain.

Take notes

Don’t underestimate taking notes. I do it myself. Even when just having a conversation with someone.

When you take notes, you aren’t just making sure you don't miss anything, but that you understand everything.

I’m an avid note-taker. I love how I never forget or skip anything because of note-taking.

At my last company, I kept track of the work I did as a Senior Software Engineer..

I don’t just keep track of the work, however.

I keep track of the impact, too.

How did implementing XYZ impact the customers, product or team?

The impact

No one cares about the work. People care about the impact of the work.

This is true whether you want to get promoted or seek your next role.

This is arguably the biggest mistake people make when trying to get promoted.

They highlight their work but forget to mention the impact.

Now, if your manager is nice, they will help you extract the impact of your work to go on advocating why you should get promoted to the people above your manager.

If they aren’t nice, they will push down on the work you did, resulting in no promotion.

It might even be the right decision, considering you haven’t realized it’s the impact of your work that matters, not the work alone.

Example

In my last company, organized our weekly learning session.

Instead of simply saying I organized a weekly learning session, I should say how it affects the team and customers:

• Increases bus factor.

  • Decreases lead time because knowledge spreads across teams.

  • Leads to faster delivery.

  • In the end, results in happier customers.

• People have shown to appreciate it.

  • Got good feedback during the retro perspective.

Focus on the impact.

Showing that you focus on the impact is already a sign of professionalism and a green flag for your next role or promotion.

If you believe something is possible and YOU can accomplish it, you will look for ways to make it happen.

Let me break it down for you with my story.

I dropped out of high school and became a software engineer.

I made a firm commitment and believed in myself. I was going to drop out of high school and land a full-time job as a software engineer.

I did the best I could to make it happen. I refused to believe it wasn’t possible despite the start of the pandemic and the lay-offs at the time

Now, on the other hand, people around me refused to believe it was possible.

They thought I was crazy.

They thought I was joking.

But if we step back, because they never believed in it, how on earth would they know whether it’s possible or not?

They didn’t believe in it, to begin with, and never questioned it.

Of course, they wouldn’t look into how you can drop out of high school and become successful in the world of tech.

I’m often asked how to become a Senior engineer quickly.

The Senior level varies from company to company, but there are elements to it that are generally true in the industry.

Before we dive into the two main ingredients, let's cover the fundamentals.

Get technically good

One thing that’s in your control is getting technically good. By that, I mean getting good at programming. This can be done by building side projects, reading books, and taking online courses.

Get known for getting things done

Get known for getting things done. When you promise, you deliver. Be seen as a reliable person. This sets the foundation for a good reputation and builds trust.

Get good at communicating

Be able to communicate effectively with developers and non-developers alike. This includes both written and verbal communication.

Be a team player

Be helpful, spread knowledge, and show that you care about the team as a whole, not just your own work.

Two main ingredients

The two main ingredients for becoming a senior engineer are ownership and impact.

Ownership

Ownership is based on two principles: Identify and Act.

**Identify:** This is how you develop an eye to identify problems that are pain points. You don't simply point out superficial problems, but dig into the underlying issues.

**Act:** This is how you evaluate the problem's impact, the cost of fixing it versus not fixing it, and its priority against other team commitments.

How to develop an eye for “identify”?

It doesn’t happen overnight. It happens over time as you gain more experience.

Highlighting some opportunities split by levels:

• Junior / Mid developers - Look for problems that are affecting team productivity

  • Is it difficult to work in your codebase? Maybe refactor things

  • Are the tests breaking all the time? Improve your process or use linters

  • Are you not catching bugs before shipping? Improve your release pipeline!

• Senior developers - Improve team and customer relations

  • Is a customer unhappy with your team? Can you resolve it?

  • Are they complaining too many times about a workflow or an API? Can you turn the complaints into a feature?

Act

Some hesitate to take action after identifying a problem. They feel:

• They are not the expert.

• How can I propose a solution if I am not a manager?

• They fear failure or worry that the new work will take longer.

The feeling is normal, but don't stop there. The top 1% of engineers push through the discomfort and deliver excellence.

Be confident. Remember, do your best, and if you make mistakes, you learn. You will learn regardless of whether you make a few or many mistakes.

One thing I’ve found helpful is seeking input from one of my peers. It helps me become more confident in my proposal and whether I’m on the right track.

Impact

Impact is about working on the right problem—a problem that is important to the team and the customers.

Let's take a look at two examples, one is my own.

Fixed accessibility issue

At my first job, I led our accessibility initiative. See my previous newsletter post for more details.

However, a customer navigating our website using a screen reader was blocked from accessing certain parts of the site. They filed a complaint to our customer success team.

The ticket ended up being written but was just lying around. People were not even aware of it. I looked at it and brought up that we should fix it as soon as possible.

I prioritized fixing this issue and getting it out to customers.

This is an example of focusing on work that has a real impact on the customers.

Improve CI speed

Improving the CI speed is a great example of impact. I've heard many do this to increase their impact. It's a small thing, but it can make a big difference in the team.

If you can cut down the time by 30%, that's a big win. Think about how much time every team member spends waiting for CI to finish.

Your team will move faster and you'll be able to deliver more features.

Conclusion

Becoming a Senior engineer is different in every company.

Cover the fundamentals of being a good developer.

Lastly, focus on the two main ingredients: Ownership and Impact.

I invented BDD.

Blog-Driven Development.

It’s a practical philosophy where a developer writes to grow 100x faster.

I’ve written 250+ posts over the past couple of years and have experienced the sweetness of BDD.

In this post, I want to dive deeper into BDD and open it to the world.

The benefits of blogging

We can break down the benefits of blogging into two parts:

• Writing in silence

• Writing in public

It’s phenomenal how blogging is a complete package.

After writing my first blog post, I got hooked on writing.

Writing in silence

Writing in silence is easier than writing in public. The benefits of writing in silence are included in public writing.

Writing is an art.

As I’m writing this, my thoughts are going to different places.

Writing forces me to think. It forces me to reflect as I’m expressing myself by composing words.

Reinforcement

Writing about a topic reinforces it in my brain.

As I’m forced to think, not just about what I’m writing, but how I’m supposed to express what I want to convey, it makes me drill down into the topic deeply.

Additionally, we tend to re-read our writings as we’re writing them.

Test my understanding

Expressing myself is a way to test my understanding.

Writing forces me to express myself.

If there are gaps in my knowledge, writing will expose it. It’s good. Wherever we lack knowledge, we can dive in and fill the gap.

This can be done by revising what you learned or doing more research.

Strengthen my memory

Over the past couple of years, my memory has improved.

Sometimes my own memory shocks me. It’s fascinating how sharp it has become.

Interestingly, this change began when I started writing frequently.

Writing in public

Writing in public includes the benefits of silent writing.

Additionally, writing in public comes with more benefits.

You’re now writing for the world.

You’re writing to readers.

This is where writing turns into a complete package.

Get your name out there

Writing in public lets you put your name out there.

This can lead to increased opportunities.

The more people know you, the more opportunities you will get.

This is how you create luck. By working hard both in silence and public.

Additionally, this is a stepping stone to build a personal brand.

A personal brand is extremely valuable. This is when paths you never thought existed open up.

You may have no thoughts today of what to do with your personal brand, but I guarantee you will look back in 2 years and thank your younger self for having started writing in public.

Improved communication skills

You’re now writing to readers.

It’s the same as writing code in a team.

You understanding it, isn’t enough. Others have to understand it too.

This is where you’re forced to edit your writing. You put effort into improving it. This will result in bettering your communication.

Learn from others

Others being able to see your knowledge and learn from you is valuable. They can ask questions and correct you when you’re wrong.

It’s true, we can all be wrong. It’s completely fine to be wrong. We should be humble and learn from others whenever given constructive feedback.

That’s why I believe it’s good to write about what you learn and your personal opinions.

When and what to write

You don’t know what to write about.

You don’t know when to write.

You simply can’t cross the bridge from wanting to write to actually being a writer.

What to write

As developers, opportunities to write exist everywhere.

Look around yourself.

• Struggling with something?

• Learned something new?

• Built a project?

• Disagreed with someone on something?

Write. Write. Write.

People have the assumption your writings need to be informative and perfect.

Guides from zero to hero.

That’s false.

Another thing to mention, if you’re truly stuck, then simply write for your younger self.

Now, you have a bunch to write.

When to write

Timer

Always make sure to work focused when writing.

It’s best to set a timer and focus hardcore when writing. This way you can be effective and don’t waste brainpower.

I would recommend setting your timer to at least 15 minutes before taking a quick break.

When

As for when to write, I strongly recommend forming a habit.

Consistency is key.

Having a habit helps staying consistent.

Start small. Slowly increase the duration and intensity of the habit over time. Consistency must be the core, hence intensity isn’t the primary focus.

We all got time.

Just start!

Ideas gathering

Notes

I take notes on my phone throughout the day.

Whenever an idea sparks in my head, I take notes right away so I don’t need to remember it.

It helps. I don’t feel like I need to subconcisouly think about the idea because I’ve written it down already.

Drafts

I enjoy starting draft blog posts.

I don’t think you need to write the entire blog post in a single sitting.

Sometimes I start a blog post and work on it bit by bit.

From an hour to a month.

It varies how long it takes for me to finish a post.

Conclusion

BDD is amazing.

It was one of the keys to my fast growth going from Junior to Senior developer in just 18 months.

Write. Write. Write.

We relaunched the Survival Kit for developers.

The kit contains 4 tools.

You can buy the entire kit or each tool separately:

• Resume template: Got me interviews at Google, Vercel and Cloudflare.

• 6-month intense roadmap: Took Miraya from zero to landing a coding job in less than 6 months.

• Book with two parts: Miraya's success story and top tips to get a developer job fast and crush your interviews.

• Guide for getting $100k+ jobs in tech: Strategies that got me two $100k+ remote offers with just 18 months of work experience.

If you're learning to code or on the job hunt, it's perfect for you.

You can find more information on our brand new website.

What does it mean that TypeScript is a superset of JavaScript?

We'll dive into that today and uncover exactly what that means.

TypeScript isn't a real language

TypeScript is a superset of JavaScript. It contains all the features of JavaScript and extends them with additional functionality. Essentially, any valid JavaScript code is also valid TypeScript code. TypeScript adds static typing to JavaScript, allowing developers to specify types.

However, TypeScript doesn't run in production. TypeScript is transpiled to JavaScript before execution, meaning that TypeScript code is converted into plain JavaScript code which can then be run in any JavaScript environment. This transpilation process is necessary because browsers and most environments do not natively understand TypeScript

Duck Typing

In TypeScript, types aren't unique. They are just a way to describe the shape.

Duck typing simply means that an object's type is determined by its shape. The term comes from the phrase, "If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck."

This means that TypeScript's type system is structural rather than nominal. In a nominal type system, two types are considered equivalent or compatible if and only if their declarations name the same type.

A structural type system can lead to weird behaviors. For example, if two different types have the same structure, TypeScript will consider them to be compatible, even if they were intended to be distinct.

Another example is that if you pass an object to a function that expects a specific type, as long as the value you pass satisfies the type's structure, TypeScript will not complain.

Nominal Typing in TypeScript

Surprise, surprise!

You can achieve nominal typing in TypeScript by using symbols.

Symbols are unique identifiers that can represent a type. They're guaranteed to be unique, so you can use them to distinguish between different types.

We will "tag" our types with symbols to make them nominal.

Let's say we have two types, CustomerProfile and AdminProfile. They have the same structure, but they are different types. And we decide for some reason they should be distinct.

Looking at the code, we can see that if we try to assign a CustomerProfile to an AdminProfile, TypeScript will complain.

We just launched a brand new community: Little Software Planet.

A place for developers to grow, connect and learn.

Introduction

I went from Junior to Mid-Level Developer at my first company in 10 months. I want to share what I did to grow so fast and drop a couple of things I learned along the way.

Looking back, I think there were 4 main things that made me deserve the promotion.

Made our site more accessible

We needed our site to be accessible. We had older people, such as grandparents, using our site. When I started, the company had a consultant who led the accessibility initiative. I was extremely curious about accessibility because I had never heard about it before. It was a surprise to me.

After learning more about it and talking to my manager, who had prior experience in accessibility, I learned we had a need for it. I learned more about accessibility in my spare time and built side projects where I focused strongly on accessibility, which included testing with a screen reader.

Later, the consultant left. There was room for me to step up and become the accessibility expert of the engineering department. I talked to my manager and proposed testing our site with a screen reader and Axe DevTools to identify issues. I documented all the issues and sorted them by severity level. I followed up and discussed this with my manager. We decided to fix any issues that resulted in a horrible user experience.

Getting good at accessibility also helped me write better tests with Testing Library.

I would consistently share knowledge and make sure the team implemented accessible code.

Introduced practices that helped the team move faster

The practices I introduced were Pair Reviews and Stop and Fix.

Pair Review

Instead of the async flow of reviewing PRs, Pair Review is hopping on a call and reviewing it productively together. This helped us move more efficiently.

Pair Review

We had a problem where whenever build would fail, it could be broken for days. This resulted in the team going into panic mode when we had to ship to customers.

Stop and Fix is a practice from Extreme Programming: Whenever build (main branch) is broken, the entire team stops to fix it. This ensures the codebase is always in a working state.

Documented usage of performance APIs in React

Performance APIs in React were used randomly because people had assumptions about how they worked.

We should always measure to see if there is a need to optimize for performance.

Such APIs don't always come with a benefit, but always come with a cost.

I asked the team about it. There seems to have been a misunderstanding of how the APIs work. After a discussion, I documented the usage of those APIs.

People stopped randomly using the performance APIs. When they did, they would add a comment explaining why they were using it.

Got good at testing

We used the React Testing Library at work, and I got extremely good at it. I also took the TestingJavaScript course from its creator, Kent C. Dodds, and contributed to it (Open Source).

Already in my third month, my manager realized how good I was at testing. We had a meeting that month: my manager, another Lead, and myself. We discussed my rapid growth and how happy the company was to have me. That’s when my manager told me he was shocked to see how good I was at testing when we pair coded.

Lessons to take

What can we learn from my experience?

• Get technically good.

• Be extremely curious.

• Don’t be shy about confronting the team despite your experience.

• If you identify a real problem, step up and propose a solution that involves you having a real impact.

While interviewing during my job hunt, I was asked how I’d take a feature from start to delivery.

I think it's a great question because it reveals how the candidate thinks through the entire development cycle. The thinking and understanding here differentiate more senior developers from junior ones.

Let’s start with the interview question I got: “You’re given a feature. What’s your general approach from start to delivery?”

General steps

1. Ask why

The first step is to ask the “why”. Why do we need to ship this feature to customers?

From my experience, if enough data hasn’t been gathered, this could delay the feature until more data has been gathered.

By “data”, I mean the information that explains the “why” behind the feature.

If you have enough data, you will be more motivated and also work on the right thing.

2. Identify MAVP

Identify the Minimum Actually Viable Product (MAVP). What is the minimal thing you can ship that still offers real user value?

Instead of shipping the entire feature, you want to break it into milestones. The first milestone would be the MAVP.

To learn about the MAVP, you have to learn about your users and thoroughly understand the “need” for the feature. This is also why you need the first step to do this step successfully.

Here, you will want to break the feature into milestones with the first iteration being the MAVP.

I wouldn’t worry too much about the future milestones. They can be broken down into rough assumptions. Once you reach those milestones, you will have much more clarity about what to work on.

3. Simplest technical solution

When working on something new, we often have to come up with a technical solution. It’s easy to think that whatever is seen as the “common” or “best” solution in our industry for a particular problem may be the right solution.

But, simplicity is key. You want to identify the simplest solution for your situation.

Keep YAGNI (You’re Not Gonna Need It) in mind. Do not implement something you don’t need. Focus on the present moment and find the simplest solution to satisfy the current requirements.

This may sometimes be a solution that would typically look ugly in a different situation.

4. Break into tasks

Once you have the idea for the technical solution, break the MAVP into clear and small tasks.

This is good for several reasons:

• To not get overwhelmed.

• Easier to review the pull requests.

• Transparency on how the work is going.

5. Feature flagging and rollout

You will want to implement feature flags as you work through the tasks. Feature flags enable you to turn on the feature for specific users in different environments, such as development, staging, and production.

For example, in the staging environment, you may not want to show the progress of MAVP to everyone to avoid making it look messy. But you still want to show it to your Product Manager and Designer for feedback.

With feature flags, you can roll out a feature incrementally or to all users.

It’s a good practice to roll out the feature incrementally. You can enable the feature for a subset of users and gather early feedback, e.g. based on location.

This way, you can already improve the feature based on user feedback before rolling it out to all users.

6. Validate assumptions and gather feedback

Once MAVP has been launched, the first milestone, you want to validate the assumptions you had.

The assumptions often come from the initial “why” behind the feature.

• What’s the problem?

• What do customers need?

• How is the feature expected to solve this?

  • What do we aim to achieve?

You want to gather user feedback and validate your assumptions.

If you didn’t achieve what you aimed for, why? What went wrong?

If you did achieve what you aimed for, what did you do right?

7. Improvements and following milestones

In this step, my preferred approach is to first look at user feedback and try to improve the feature based on that. It’s important to stay agile and not work on the “next” milestone because you feel you have to.

What matters most is customer satisfaction.

If you plan on working on the next milestone, you can prioritize which milestone to work on based on user feedback.

Important note

This is a general approach taking a feature from start to delivery.

I said “you” all the“, but I want to emphasize that this is all done with the team.

For example, you might set up a brainstorming session with a few developers to identify the simplest technical solution.

Or you will write an RFC and have it reviewed by team members.

Speaking of RFC, I have a template.

Conclusion

In the real world, developing a feature from start to finish isn’t as easy as working on it and getting it shipped.

The general steps we went through would be a pretty Senior answer.

Someone who is more Junior might start by breaking it into smaller tasks and likely mention Feature Flagging not to break production.

I love to build things. I’m grateful to have the skill set to do so.

In this post, I want to share how I build side projects.

In the end, I’ll answer some of the questions you asked me about building side projects.

Requirements in a document

I start by writing down what I want the project to include. What should it do? I tend to let loose and include many things.

Once that’s done, I reduce the requirements to the MAVP (Minimal Actually Viable Product). What’s the minimal thing I can ship that still offers real user value?

In the first iteration of my project, I don’t want to ship something that includes “everything”. It would take too long to build. I want to ship the minimal thing that still includes the core value the project delivers.

Sketch in Excalidraw

Usually, I have a rough idea of how the project will look like. If I don’t, I’ll look for inspiration over at Dribbble.

Once I have a rough idea of how it should look, I sketch the UI in Excalidraw. This is not too tricky, it’s simply the base for the design.

Design in Figma

Once the sketch is done, I design the project in Figma. I start by deciding the colors and fonts. Designing your project can be difficult if you’re not a designer.

I enjoy designing the project in chronological flow. By that, I mean how the user would land on the page and figure out how to use the app from start to finish.

For my last project, for example, I started by designing the login screens and finished with the share dialog screen.

Resources

To learn to design, I recommend Refactoring UI.

To learn accessible design, I recommend Inclusive Design Patterns.

To learn Figma, I recommend this workshop at Frontend Masters.

Build the project

Now it’s time to build the project.

I start by initializing it and pushing it to a Github repository.

I then deploy my project immediately and ensure automatic deployment is in place. This is quite easy with Vercel. Simply import your repository and deploy, and every time you push to the main branch, it’ll deploy automatically.

It’s important to deploy your project right away. You don’t want to build a full-blown app locally and then struggle with deployment. Pinning down the error will be tricky if that happens, speaking from my own experience.

It’s easy to get distracted. Focus on getting the first iteration of your project done. You can always add more things later. Perfection is the enemy of progress.

As for testing, I enjoy writing tests where it makes sense. My goal is to gain enough confidence to be able to ship. It’s important for me that the core features work as expected. If I have functions that transform data, I enjoy doing TDD and putting a unit test in place.

I prefer E2E tests for the UI tests. I’ll use Playwright or Cypress. If I know how the UI will be implemented, I do TDD. Otherwise, I don’t mind building for a while till I get some more clarity. But I’m a big fan of driving my code with tests.

When writing E2E Tests, make sure to use Testing Library’s accessible queries. This way, you test your app the way the user would interact with it rather than querying implementation details. If you use Cypress, this isn’t baked in (compared to Playwright). You’ll have to add Cypress Testing Library.

Further reading

This post may interest you:

Final check

When you think you’re done, do a final check.

Play around with your app in production. See how it feels. Put yourself in the users’ shoes. Try to break the app.

I often end up doing slight modifications to enhance the user experience before considering it done.

Document the side project

Lastly, you want to document the side project in the README.

Here are some things I like to include:

• Demo

• What it does

• How to get it running locally

• Specific features and some code

• Bugs or Future improvement ideas

• Architecture

• Tech stack

Announce

Once it’s all done, you can announce your project.

Share it on all of your socials!

Next steps

The next step is to keep working on the app. The first iteration doesn’t mean you’re entirely done. You can either improve based on user feedback or just keep hacking!

FAQ

What to build?

I like to build a clone of something I want to learn, such as Figma, Excalidraw, Miro, or Google Docs.

Or I like to build something to make it Open Source and actually try to get users.

If you don’t know what to build, just start building something small. It doesn’t have to be the next big thing. Mini projects are totally ok. As long as you’re learning.

How do you find the time?

I’d recommend forming a habit. Regular deep work where you put in the work on your side projects. Focus on being consistent. Consistency adds up over time. Being consistent is better than putting in much intensive work and getting burned out.

How do you finish it on time?

Sometimes I do, sometimes I don’t. You get more clarity on how long it takes to build something as you’re building it. My advice is to really focus on shipping the first “iteration” as mentioned in the beginning. Don’t try to ship something crazy at once.

How long should I work on it?

How long you want. As long as you’re learning and having fun, right?!

At my last company, I organized our weekly learning session.

It would happen once a week.

Since we were remote, sharing knowledge wasn’t easy. The goal was to share knowledge across teams with the aim of increasing the bus factor.

It turned out pretty well. During a company retro we once had, many voiced being very happy with the learning sessions and saw it was one of the company’s strengths.

It was fun. The learning session channel we had on Slack would turn into a place where people regularly shared interesting resources or learnings.

Beginning

At the beginning, I made many mistakes:

• No Agenda

• Not recording the sessions

• Not keeping people informed

• Tried to get it prepared ad-hoc on the same day

Looking back, I feel a bit bad.

Improvement

But we learn from feedback and the mistakes we make.

After receiving feedback from my manager, I improved:

• Agenda

• Clearly inform who is presenting what

• Recording each session, updating the Agenda and sharing the session with the team

• Prepare the session a week before or cancel, letting people know a good time before the session won’t be happening

If you organize sessions for your team, do it with professionalism.

Everyone’s time is expensive.

Every cognitive effort in the organization is valuable and not cheap.

Respect your teammates by respecting their energy and time.

The last thing you want is for people to join a call and stay 5 minutes just for you to announce it’s not happening this week.

It’s annoying.

People have work to do and context-switching is more draining than we think.

I understand that life is short. You won't be able to learn everything or get to do everything. That doesn't sadden me, but what does sadden me is the great amount of curiosity I have lost as I have grown up.

I have a baby sister, she is over 2 years old now. Seeing her growing up, she is extremely curious about everything, even tiny dots on the floor. It shocked me a bit, how long she can look and try to analyze a small dot on the floor.

I at first found it funny, it was a bit silly seeing it. As time has passed, I have been contemplating more on curiosity. It struck me, babies are much more curious than adults, and it is one of the reasons they are great learners.

They are so curious, even learning boring things becomes exciting, because of all the questions that come to their minds.

It saddened me, to think about how much I could have learned already if I kept such a curiosity. I'm a disciplined individual, and I spend a lot of time every day seeking knowledge, but that was really one thing that shook me.

Where did all that curiosity go?

As someone who wants to learn a lot, primarily in tech, I want to have such a curiosity.

By asking a lot of questions, and keep digging into a topic, we can learn way more than we expect. It requires a constant hunger for knowledge, and not being satisfied with what you already know.

One thing I'm reminded of is the quote by Kyle Simpson:

I always tell people that the only difference between me and them is that I asked more questions and didn’t stop until I found the answers.

I'm reminded of the Beginner's Mind. Kyle doesn't seem to be classifying himself as an expert, but rather someone who just kept asking.

Searching

I'm now searching for principles to live by that allow me to constantly be curious, and never satisfied with the existing knowledge I have. To have a beginner's mind, and live by it.

Things that come to mind:

• Listen more

• Ask more than I answer

• Never be satisfied with your current knowledge

• Find a way to regularly question the things you do, and ask yourself why you do them

• When you think you are right, instead calm down, and think you may be wrong

You discovered a part of the system that could be much more performant.

You assumed optimizing this part of the system would have a great effect.

You managed to make the part 11 times faster!!

You made a pull request, excited to share it with the team.

But, wait?

A Senior engineer comes in. They leave a comment and don’t seem too excited.

Have you measured the impact of this optimization on the system in use, to see the effect it has on customers?

You spent 4 hours to make this part of the system 11 times faster, will it all go to waste?

Ambdahl’s Law

Software engineering always goes back to customers.

It’s important to not do things blindly.

Making a small part of the system faster may not have an overall effect on the system. It’s easy to fall into traps when focusing on performance optimizations.

Make sure your time is spent wisely as a developer.

If you want to optimize things for performance, make sure to measure first. You can measure the specific part of the system if you wish.

However, it’s more important to measure the whole application in use to see the performance issues from the perspective of the customers.