🚨 Announcement 🚨
Join me for the upcoming free live workshop where I will go deep into developing your interview skills.

“3 Interview Mistakes Devs and QA Engineers Make That Sabotage Interviews (And How to Fix Them Fast)”.

Register Now

You’ve spent years building your skills.

You’ve put in the late nights, the weekends, the debugging marathons. You’ve solved real problems, learned new tech, and stayed ahead of the curve.

But when it comes to interviews?

You feel stuck.

You give answers you know are technically sound. You talk about the work you’ve done. You try to be clear and confident.

And yet, the rejections keep coming.

Sometimes you get ghosted.

Sometimes you get told someone else was a “better fit.”

But deep down, you know the truth:

It’s not because you’re not good enough.

It’s because your answers did not resonate with the answers interviewers were expecting.

And that’s the part no one teaches you.

How to explain your thinking?

How do you tell the story behind your code without missing technical details?

How do you show value without sounding like you’re bragging or reciting from a textbook?

The worst part?

If you don’t fix this, you could stay stuck here.

Interview after interview. Job after job.

Watching less experienced people land roles you deserve.

Not because they’re smarter. But because they know how to talk like someone who belongs.

In this post, you’ll discover the three silent mistakes most developers and QA engineers make in interviews and how to fix them fast. Before they quietly kill your next opportunity, too.

Mistake 1: Not doing the right type of preparation

Most people focus on learning the technical details they may not know or trying to brush up on some areas they might have forgotten.

However, very few people focus on what they have put in their resumes.

One key question is, "Give me a brief overview of yourself." This is one of the first questions and is almost always given in most interviews.

Many people do not prepare for it. Some give a summary that tells nothing more than a CV, while others, still focused on remembering things they might get asked, ramble on without a beginning or ending.

Other common questions are likely to be asked, and it is better to prepare for them so that you can make a powerful impression.

Some of them include:

• What are your strengths and weaknesses?

• How do you overcome challenges at work?

• What problems have you encountered in your past/current organisation?

• What is one thing you do not like about your past/current organisation that you would like to improve?

• How do you stay updated with technology advances?

Mistake 2: Treating the interview as a quiz instead of a conversation

As an engineer, you will always want to showcase your technical knowledge. So it makes us answer the question as fast as possible. Sometimes, we don’t even wait for the interviewer to finish the question.

Now this has a few problems.

1. It comes across as if you have memorised the answers. Competent people do not need to memorise the answers. They can pull the answer out of experience rather than memory.

2. The interviewer will feel that you have not listened to their questions completely, making the interviewer feel out of sync with you. You might come across as a person not open to listening.

3. With the focus on answering fast, you forget to provide the nuance that the answer might have.
   
   The interviewer might assume that you are not aware of the nuance (which will kill your chances) or might ask follow-up questions, and you may or may not get the nuance that the interviewer was looking for.

Mistake 3: Not referencing your answers with experience

Interviewers want to know about you and your experience. So when you answer a technical question without referencing your experience, you are giving away the opportunity to talk about your deep technical knowledge.

The interviewer is not looking for the technical answer, whether you know it or not.

They are looking for your experience in solving the problem.

For example, consider the question: In Spring Boot, what is the difference between the @Controller and @RestController annotations?

Now the answer is straightforward.

@Controller is used to define a web controller that returns views (like JSP or Thymeleaf), while @RestController is a convenience annotation that combines @Controller and @ResponseBody, making it return JSON or XML directly from all methods by default. Use @RestController for APIs, and @Controller for web pages.

But if you answer it with an example from your experience.

@Controller is used to return a view and is typically used with something like Thymeleaf. I’ve used @RestController when building REST APIs. The nice thing is, I don’t need to add @ResponseBody to each method. It automatically converts the return value into JSON. So whenever I’m building a REST API, I just use @RestController.

This gives your interviewer a perspective that you have worked on it and have not repeated some answers that you memorised.

How to avoid these mistakes?

To avoid these pitfalls, you need to understand the different buckets of questions.

3 Question Buckets

Most candidates focus heavily on technical questions when preparing for software engineering interviews.

However, interviewers evaluate you on more than just your coding ability.

Based on my 15+ years of experience and being on both sides of the table, I find it helpful to divide interview questions into three main buckets, each with its own subtypes and preparation strategies.

Common Interview Questions

These questions aren’t meant to test your technical depth. They’re designed to understand your motivation, personality, and communication skills.

Often asked at the beginning of an interview, these questions help set the tone and offer the interviewer a glimpse into how you see yourself.

Examples:

• Tell me about yourself.

• What are your strengths and weaknesses?

• Why are you looking for a change?

• Where do you see yourself in 5 years?

How to prepare?

Create a draft of these answers and practice them before a camera.

Tweak answers as you feel the right words that work for you.

Once you have mastered it, the words will come naturally from you.

Your answer will become to the point, and you will deliver it with confidence that will make a good impression, especially with the first question: tell me about yourself.

Technical Interview Questions

This is the meat of most interviews, especially for engineering roles. But not all technical questions are created equal. You can further break them into three subtypes, each requiring a different mindset to approach them effectively.

Fact-Based Questions - (Assessing Knowledge)

These questions test your understanding of specific technologies, tools, or concepts. The answers are usually short and have a “correct” answer.

Examples:

• What does @AutoConfiguration do in Spring Boot?

• What is a RESTful API?

• What’s the difference between HashMap and ConcurrentHashMap?

How to prepare?

The trick here is to answer the question by adding scenarios you used in your experience.

If you have used it before, highlight specific examples of how you have used it and also talk about some of the challenges you have faced.

If you don’t have experience, answer the question and tell them you have never used it.

This prevents further questions about topics you might not know, and the interviewer will move towards a topic you are familiar with.

Opinion-Based Questions (Assessing Preferences and Thought Process)

Here, interviewers are interested in how you form opinions, make trade-offs, and justify your choices. There may be no single “correct” answer, but they want to see if your thinking is grounded and experience-driven.

Examples:

• Do you prefer SQL or NoSQL databases? Why?

• Would you introduce a new language like Python in a Java-heavy codebase?

• What’s your take on using microservices vs. monoliths?

How to prepare?

These are tricky, as you might not know if the interviewer dislikes one part of it. The idea is to provide your opinions and give examples if you have them.

You can also reference blogs if you don’t have enough proof of experience.

In either case, the critical piece is the ending. You finish it by saying your experience or learning limits your thoughts, and you are open to ideas that will help you learn better.

This helps you get pointers if the interviewers have strong opinions about it and also showcases that you are open to feedback and learning.

Scenario-Based Questions (Assessing Application and Design Skills)

These practical, open-ended questions test how you think through real-world problems, design systems, or debug tricky issues. They simulate the kind of challenges you’d face on the job.

Examples:

• You’re asked to build a REST API—what are the key things you’d consider?

• How would you debug a slow-performing endpoint?

• How would you handle consistency if multiple microservices need to share the cache?

Behavioural Questions (The Culture Fit Test)

Behavioural questions assess how you work with others, deal with conflict, handle pressure, and grow from challenges. These are crucial for determining whether you’d fit the team and company culture well.

Examples:

• How do you handle tight deadlines?

• What would you do if you’re blocked and not getting the needed information?

• Tell me about when you received difficult feedback and how you handled it.

How to prepare?

Similar to common interview questions, the questions are limited. So you can prepare well for these.

You need to use the STAR technique to answer these questions. If you can master this technique, you can also answer your technical questions with this approach.

The benefit is that this approach makes you tell a story. The story might not be the best in the world, but it will be enough to hook the interviewer's attention.

It also gives the interviewer opportunities to ask questions, and since you are basing it on your experience, you will always be on firmer ground than with other questions.

The STAR framework provides structure:

• Situation: What was the context?

• Task: What needed to be done?

• Action: What did you do?

• Result: What was the outcome?

Final Thoughts: Turn Preparation into Confidence

If there’s one thing to take away from this, great interviews don’t begin in the interview room.

They start with how you prepare.

• Prepare answers to common and behavioural questions ahead of time—not to memorise, but to internalise.

• Anchor your responses in your experience. That’s where your strengths live.

• Use the STAR technique to draw out scenarios in advance. The more you practice these, the more naturally they’ll come to you when it matters.

• Don’t just say your answers. Practice them on a video call. Record. Rewatch. Adjust. This one step alone can drastically improve how you come across.

When you combine clear structure with authentic storytelling and real-world examples, your interviews feel less like an interrogation and more like a conversation you’re ready for.

Want help putting this into action?

Join me for the upcoming free live workshop:

“3 Interview Mistakes Devs and QA Engineers Make That Sabotage Interviews (And How to Fix Them Fast)”.

I’ll discuss real-world examples, live breakdowns, and simple techniques you can use immediately.

#1: Create a README Like a Solution Engineer (13:48)
Use your README to demonstrate your thought process, including solution diagrams, requirements, implemented features, and future enhancements. This showcases your problem-solving approach even before writing code.

#2: Showcase Projects at Any Stage of Completion (18:22)
Even unfinished projects can demonstrate your skills - document implemented features separately from planned enhancements to show interviewers what you've accomplished and your forward-thinking approach.

#3: Focus on the "Why" Behind Technical Decisions (22:47)
Clearly explain your design decisions and technology choices. Being able to articulate why you chose specific approaches demonstrates technical competence and helps differentiate your work from AI-generated code.

Here's the template link: https://gitlab.com/dd.omniview/github-readme

For your reference, you can find other aweseome README templates you can use in your projects if your goal is to have more open-source contributions

• https://www.makeareadme.com/

• https://github.com/matiassingers/awesome-readme

If you have more questions or need more clarity on being a better software engineer, reply to this email with your thoughts.

Love to read about them.

But here’s the harsh truth—LeetCode isn’t enough.

You can memorize algorithms, ace coding challenges, and yet struggle in real-world software development.

Because when you’re on the job, your biggest problems won’t be binary trees or dynamic programming.

They’ll be messy codebases, unpredictable users, and working with people who don’t think like you do.

Here's 7 reasons why solving Leetcode problems does not help you become a good software developer.

1. AI can solve LeetCode problems - where does that leave you?

All the LLMs can solve LeetCode problems in a matter of seconds. The accuracy will only improve as time goes on.

So what's the value that you can bring to an organization?

2. Users are unpredictable

This is an old joke.

A QA walks into a bar. Orders a beer. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a string of random characters. First real user walks in and asks where the bathroom is. And the whole bar catches fire.

Real-world users don’t follow predefined rules.

They input unexpected values, break your UI, and find edge cases you never considered.

In the video below, see what users are using the new Bounce Features for Mercedes.

Mercedes Bounce

Writing production code means anticipating failures and designing for resilience—something LeetCode won’t teach you.

3. Your code is not an island

Most real-world applications interact with multiple external systems—APIs, databases, third-party services.

These systems change, fail, and return unexpected data.

Handling these changes with minimal disruption is a critical skill that LeetCode completely ignores.

I remember an issue where the labels on parcels got all mixed up.

How do you find what caused the issue?

You never learn to troubleshoot issues across many systems using LeetCode.

4. Your code is only the technical specification part of the software. The bigger part is people.

Software development is a team sport. You’ll collaborate with engineers, product managers, designers, and QA testers.

You’ll encounter tough personalities and conflicting priorities.

More importantly, you’ll get feedback.

QA engineers will break your code, senior engineers will challenge your designs, and business stakeholders will change requirements.

Learning to handle this with maturity and professionalism is essential—LeetCode doesn’t prepare you for that.

5. Seeing the Bigger Picture Matters More Than Fixing Bugs

Sometimes, a bug might look an easy fix. But if you do not take time to understand the consequences of the fix on the system, it might result in a host of new bugs that you never thought of.

Understanding the exact root cause of the bug and analyzing impact to the overall system is critical to doing good development work.

Key questions you can ask:

• Are you 100% sure of the root cause? The best way to determine is if you can reproduce the bug.

• When this fix gets deployed, is there any concurrent feature that this will affect?

• Is this scenario one-off, or does it have the potential to repeat often?

• Is there a requirement that will get affected in the near future?

6. There is a method to software development

Most often this method is Agile. 

Understanding sprints, stand-ups, code reviews, and release cycles is crucial for working effectively in a team.

Without this, you’re just writing code in a vacuum. No company operates that way.

7. Writing Code Is Easy—Writing Simple Code Is Hard

"A code is written once but read a thousand times." - Robert C. Martin

Anyone can write code that works.

Great developers write code that is clean, understandable, and maintainable.

Future developers (including your future self) should be able to read and extend it without frustration.

Good coding practices include:

• Writing clean, readable code

• Following design patterns (be careful with this one)

• Writing meaningful tests

• Documenting edge cases and limitations

The Bottom Line

LeetCode is useful, but it’s not enough. Focusing solely on it creates massive blind spots.

The best developers go beyond algorithms. They learn:

• How to write maintainable, well-structured code

• How to debug and troubleshoot real-world systems

• How software interacts with infrastructure and external services

• How to work effectively in teams

Now you might be wondering, when you are just starting out or switching to software development, what is one practical step that you can take.

One key action is that you can build a real-world project. Now there are caveats to that.

I will add that in another post. But it helps with most of the problems discussed in the post.

Reader’s challenge:
Even if you skip LeetCode and work on a real-world project, which of these challenges do you think you’d still struggle to learn?

Hit reply to let me know. Looking forward to your reply.

It’s a typical Tuesday afternoon, and your team is gearing up for a routine release—a feature here, a bug fix there.

Nothing groundbreaking, but it’s part of the rhythm that keeps your product evolving.

Developers have wrapped up their work, testers have validated the changes, and the release is queued up for deployment.

E2E tests are triggered to check for impacts on the overall system.

Few test cases fail.

Developers are called in to look into the issues.

Delivery leads / engineering managers are notified of the issues and now everyone in the team is there.

The team investigates for a couple of days.

The result? 1 bug and 4 false positives.

Sometimes couple of days might turn into a week and what that mean more people in to understand the consequence of the issue.

Managers are left juggling timelines, explaining delays to stakeholders, and hoping the release doesn’t bleed into the weekend.

Developers and testers context-switch from building things to fight fire.

For teams operating in microservices architectures, this isn’t a one-off nightmare—it’s a recurring challenge.

Weekly or fortnightly releases get bogged down, and instead of delivering value to customers, you’re spending precious time firefighting.

Why Does This Happen?

The root of these challenges lies in the very thing that makes modern systems so powerful: microservices architecture.

In a microservices setup, your application is no longer a monolith; it’s a collection of smaller, independent services working together. While this brings scalability and flexibility, it also introduces complexity—each service depends on others, and any mismatch or downtime can cause cascading failures, especially during E2E tests.

Let’s break this down:

1. Interdependencies - Microservices often rely on other services, databases, or external systems. If one of these isn’t available or has mismatched versions, tests fail.

2. Test Fragility - E2E tests need stable environments, but in dynamic systems, infrastructure, test data, or service availability can be inconsistent.

3. Troubleshooting Overhead - Pinpointing the root cause of a failure in a web of services takes time and coordination, delaying releases further.

So, how do you address this?

Contract Testing

One way to reduce reliance on E2E tests is by adopting contract testing.

What is Contract Testing?

Contract testing focuses on verifying the interaction between two services. Instead of testing the entire system, it ensures that a service (the consumer) and its dependency (the provider) agree on how they will communicate.

Here’s how it works:

• The consumer defines a contract specifying the API calls it will make and the responses it expects.

• The provider validates this contract to ensure it meets the consumer’s expectations.

Benefits of Contract Testing

• Faster Feedback - You can test interactions without spinning up the entire system.

• Reduced Fragility - Tests don’t rely on all services being up and running.

• Clear Ownership - Each team owns its contracts, making troubleshooting more focused.

• Scalability - Contract tests scale better than E2E tests in large systems with many services.

By implementing contract testing, you can ensure your services work well together, even if they’re deployed independently.

But contract testing alone cannot solve logic changes in downstream systems.

For example, if a shared service like an authentication system updates its logic, it might still pass its contract tests but fail in actual integration scenarios.

Traceability Matrix

To address logic changes and ensure comprehensive testing, you need a traceability matrix.

What is a Traceability Matrix?

A traceability matrix maps requirements, features, or changes to the tests that validate them. In the context of microservices:

• It links services and their dependencies to specific test cases.

• It identifies which tests to run when a particular service or feature changes.

How It Works

• When a shared service updates, the traceability matrix identifies all dependent services and relevant integration tests.

• Instead of running the entire E2E suite, you execute only the impacted tests, saving time and effort.

Benefits of a Traceability Matrix

• Targeted Testing - Run only the tests that matter, reducing execution time.

• Simplified Debugging - Developers and testers focus on the exact areas impacted by changes.

• Faster Releases - By avoiding full E2E runs, you streamline deployments.

As business logic grows and tests multiply, maintaining the traceability matrix becomes increasingly complex.

Over time, there’s a real danger of maintainers adding everything into the matrix to cover all possible scenarios.

This leads to the same problem you were trying to solve: running all E2E tests for every release, negating the benefits of targeted testing.

Leverage Domains

One way to keep the traceability matrix manageable is by organizing it around domains.

A domain represents a logical grouping of services and their associated tests within your organization.

For example, you might have domains like Payments, User Management, or Notifications, each with its own traceability matrix.

How Domains Help

1. Focused Ownership - Each domain has clear owners—teams responsible for maintaining its traceability matrix and ensuring its accuracy.

2. Simplified Maintenance - By limiting the scope of each matrix to a domain, you reduce its complexity, making it easier to manage and update.

3. Better Visibility - Domain-specific matrices provide a clear view of dependencies and test coverage within that domain, helping teams identify gaps or redundancies.

Challenges of Using Domains

1. Boundary Definition - Defining clear boundaries between domains can be tricky, especially in systems with overlapping responsibilities.

2. Cross-Domain Dependencies - Interactions between domains may require additional coordination, especially when logic spans multiple areas.

3. Initial Overhead - Setting up domains and assigning ownership requires time and effort, particularly in large organizations with legacy systems.

The Combined Power of Contract Testing, Traceability Matrix, and Domains

Each solution—contract testing, traceability matrix, and domains—addresses a specific aspect of the E2E testing problem. However, their true strength lies in using them together.

1. Contract Testing ensures service-to-service communication is reliable, reducing the need for full-system tests.

2. Traceability Matrix targets logic changes, ensuring only the necessary tests run, saving time and effort.

3. Domains keep the matrix manageable, preventing it from becoming a monolithic structure that’s hard to maintain.

By combining these approaches, you create a robust deployment strategy that balances speed and reliability.

Challenges and Open Questions

While these solutions address many pain points, they aren’t without challenges:

1. Tooling - What tools can help automate and maintain traceability matrices across domains?

2. Training - How do you ensure all teams understand and adopt these practices effectively?

3. Governance - Who oversees cross-domain dependencies and ensures alignment?

4. Scalability - How do these approaches scale as the organization and system grow further?

These open questions highlight the need for continuous refinement and adaptation of your deployment strategy.

Conclusion

End-to-end testing failures shouldn’t derail your releases.

By adopting contract testing, implementing a traceability matrix, and leveraging domains, you can address the root causes of these delays and deliver faster, more reliable releases.

These approaches empower your teams to focus on delivering value to customers rather than firefighting test failures.

While challenges remain, taking the first step towards modernizing your testing strategy is the key to staying agile in today’s fast-paced development environment.

With this combination, you’re not just fixing a process—you’re laying the foundation for smoother, faster, and more confident releases.

The initial aspiration of this publication was that I would never monetize this. publication.

The good news is it is still the case despite Substack luring me into 100 different ways to do it. 😊

So I do ask you to support me by sharing the publication if you find this useful.

Share Weekend Developer

It has been an eventful journey for me as I found both the joy of publishing and the challenge of coming up with topics to write on.

I want to use this edition to reflect on my journey so far.

Reflections

I started posting videos as I felt it was easier for me to explain than a long post.

I also found doing videos more enjoyable. Hope you liked them as well. 😉

Initial posts were more about thinking (meta) about development. Recently, I have been more focused on how to do <X>.

Let me know what kind of post you prefer.

I did drop the frequency of my publication towards the end of the year.

This was partly due to launching a paid course on doing a software project and the day job taking its toll.

If you are interested in joining the course, you can join the waitlist here: Spring Boot Project Accelerator: Build A Microservice Project in Just 2 Weeks

I need to improve the quality of some of the posts. I know it is not up there. So that’s on me to improve for the year ahead.

If you find something that needs to be improved, I am just an email away. 📧

Future Roadmap

Now this is the exciting bit. 🚀

As a reader, I invite you to shape the future of this publication. I want your feedback on what kind of posts you want to read, learn and enjoy.

Send me ideas, brickbats anything that you feel is required to make this publication better for you.

I have some ideas as well to change the model.

• Start numbering the editions. 😂

• Have posts based on specific themes every month so that you get a deep dive in 1 area

• Doing office hours - planning to be online for 1 hour fortnightly once to have a chat. Planning to do it on Zoom. Let me know if you are interested.

• Doing some posts like this more with reflections and more stories

• The elephant in the room - AI. I have not talked about it but I guess I have done my research and it is time for sharing them.

Any thoughts, suggestions?

Top Post of the Year

1. I always thought this was something I needed it. I always had to look up. So this was a guide for myself as well.

2. Kafka - I love working on Kafka at work. I think more people need to know about this. There are pitfalls that you should be aware of. But that is for another post.

3. Design Patterns - There is so much focus on learning design patterns. But like everything else in technology, you need to be wary about using it for everything. There are no silver bullets

4. Tech Debt - In the hustle culture, we create tech debts. How do we balance tech debt with speed to market? It is the eternal question that we face as developers.

5. Github Case Study - Another one with Kafka. It shows how Github moved towards a more scalable architecture using Kafka

If you enjoyed them, share them ❤️

Share Weekend Developer

Maybe you’ve been told to “build more projects” if you want to stand out to employers.

So you build and build, adding projects to your portfolio with the hope that quantity will somehow lead to quality.

Along the way you find, you had to abandon few projects because you got stuck. Or you find that other people have done some cooler projects.

You also feel that your project is what everyone else is doing.

Or you may feel that you are not confident about how you created the project.

You’re not alone.

Many developers and job seekers are facing the same issues—putting their time and energy into projects they think will make them job-ready, only to find they’ve missed the mark.

The Real Problem Behind "Just Build More Projects"

Building projects can be valuable, but only if you’re building the right projects for where you are in your career right now.

Without a clear method to choose, it’s easy to end up working on projects that either

• don’t make a real impact,

• become overwhelming, incomplete burdens that lead to burnout rather than career progress.

So how do you know if a project is right for you?

Well, I have been looking over all the mistakes that I made in my career when looking for a job and also some of the right things that I did.

I wanted to create something that would provide a step-by-step approach so that you do not make the same mistakes that I made and achieve the results faster than I did.

The result.

PACE Framework.

The PACE Framework: Plan, Analyze, Create, Execute

PACE is a simple, four-step framework I developed to help job seekers and developers select projects that lead to results. Here’s how it works:

1. Plan

Yeah, that doesn’t sound insightful. But doing the boring stuff works.

Before you begin your project there are 3 essential steps you need to do:

• Market Research
  Identify the available opportunities in the kind of role that you are looking for in the specific location you are looking for. Typically, you want it to be in the city you are living in unless you are looking for a remote job.

• Learning Intention
  Identify your learning goals based on your market research.

• Project Selection
  Use the outputs from your previous two steps to select a project that aligns with the available opportunities and your learning goals.

2. Analyze

• Analyze requirements
  Create a list of requirements that will help you achieve your goals.

• Align architecture
  This is where you will have the first brush with technology. Think about how the tech stack that you are looking to build in the project will fit with your requirements. You will draw boxes and think about how these boxes will interact with each other.

3. Create

• Design Solution
  It is time to go deeper with your diagram. You will now develop on paper how these boxes interact with each other and in what sequence. This is where you get the bigger picture of how everything will look once you have built it.

• Breakdown into tasks/stories
  This is when you break the gigantic piece of work into small bits of tasks that you can do and create goals around. You created the map of what you have to do by designing the solution.
  
  This step will help you create milestones within the map so that you know where you are and how far you need to go.

4. Execute

The final step is to start writing code. You take each story and start building.

Did you see how different it is compared to 90% of the people who begin with writing code the first time they select the project?

These steps can help you take the guesswork out of selecting the right projects and build your portfolio with intention.

But there’s so much more that goes into this process.

That’s why I have created a free workshop where I will go deep with each of these steps so that you learn all the nuances and be ready to get the framework implemented in your current project.

You’ll learn more about what to look for in your own goals, how to tailor projects to your job search, and how to stand out in a competitive job market.

Workshop Title: PACE Yourself to a Dream Dev Job: 4 Steps to Standout Software Projects
Link to Register: Register here

If you’re ready to stop wasting time on projects that don’t pay off, this workshop is for you.

Let’s make sure that every project you build is one that can help you move forward.

Hope to see you there!

Register for free

🚨 Announcement 🚨
DM me to get a FREE code review session.

Subscribe now

You're a quality engineer.

You know your way around software, you’ve caught the bugs, optimized the processes, and saved your team from countless headaches.

But now, you’re eyeing that developer role—the one where you get to build, not just test.

The one where your ideas turn into code that shapes products. You want to move from a gatekeeper to a value creator.

Yet, every time you take a step forward, it feels like you’re lost in a maze of conflicting advice, never-ending roadmaps, and an overwhelming list of “must-know” technologies.

You’ve scoured the internet, read the blogs, watched the tutorials, and maybe even bookmarked roadmap.sh, only to be left feeling more confused than ever.

"Where do I even start? How long will this take? Am I learning the right things?"

It feels like you’re trying to drink from a firehose, with no clear direction, no real sense of progress, and no idea when you’ll be ready to make the leap.

It’s easy to get stuck in analysis paralysis, overwhelmed by the sheer volume of things to learn.

You might even think about throwing your hands up and diving straight into a project, hoping you’ll figure it out as you go—only to hit roadblocks that send you spiralling back to square one.

But what if I told you there’s a simpler path?

A path that starts with understanding exactly where you are, and maps out clear, actionable steps to get you to that full-time development role you’ve been dreaming about.

Not someday—sooner than you think.

This guide will help you doing just that.

It’s about cutting through the noise, focusing on what truly matters, and giving you the confidence to start building, learning, and applying for that dream job—all without getting lost in the endless sea of “shoulds” and “musts.”

Image by Gerd Altmann from Pixabay

Steps to Follow

Identify your starting point

Assess your skills.

Are you at the learning the loops stage? Or are you at a level where you can solve some problems in most of the key topics area of a language?

You know what to do if you are learning the loops or just getting started. You only need to focus on the fundamentals.

But what if you understand the language fairly well and only need to learn the skills that most mid-level engineers want to know?

This is where you face the conflicting information challenge.

What you can do here is build your programming muscle. You need to compete with other experienced developers who can write code without looking up the internet. So by solving simpler programming challenges, you can build the muscle to solve problems.

Try simple to medium complexity exercises on coding platforms such as Hackerrank, Codility, LeetCode.

Transitioning to Building Projects

After getting comfortable with solving coding problems, it’s time to start building real projects.

You’ll know you’re ready for this step when you can mentally map out solutions or feel a sense of boredom with repetitive coding exercises.

This indicates you’ve mastered the basics and are ready to apply your skills in a more meaningful way.

Start with Simple Projects

Begin with a small, manageable project that aligns with your goals, like a basic to-do app or a simple API service.

The key is to complete a project from start to finish rather than biting off more than you can chew with a complex, large-scale application.

Completing a project will build your confidence and give you a sense of accomplishment, which is crucial at this stage.

For common pitfalls to avoid when starting projects, you can check out my video where I cover the biggest mistakes new developers make.

Keep Practicing Problem-Solving

Even as you dive into projects, continue practising coding challenges at least once a week.

This habit will help you maintain your problem-solving skills.

It also keeps your coding speed sharp, which is vital for performing well in technical interviews.

Incorporate Libraries and Tools

One of the hallmarks of a seasoned developer is knowing when to leverage existing libraries instead of writing everything from scratch.

These libraries are used by thousands of developers and have been thoroughly tested in production environments, bringing robustness and efficiency to your projects.

Explore Useful Libraries

Identify commonly used libraries in your chosen tech stack that can make your code more concise and efficient.

For instance, in the Java ecosystem, Apache Commons offers a variety of utility functions that handle many of the repetitive tasks for you.

Integrating these libraries into your projects not only speeds up development but also teaches you how to rely on battle-tested code to solve common problems.

Identify and Address Skill Gaps

As you near the completion of your projects, take a step back and assess any gaps in your skill set. This might include missing technical skills, foundational concepts, or knowledge of software development processes.

The key here is to be honest with yourself about where you need improvement.

Create a Learning Plan

Address these gaps one at a time. You can extend your current project to practice these skills or start a new project specifically designed to target your weak areas.

For example, if you’re unfamiliar with certain libraries or need to brush up on data structures, make that a focus in your next project iteration.

Market Research and Applying for Jobs

Begin applying for entry-level developer positions, even if you feel you're not yet perfect.

The feedback you receive from job applications and interviews will provide invaluable insights into what employers are looking for and help you identify further gaps to address.

Conduct market research on job portals to keep up with the skills in demand for your desired tech stack.

Learn from Other Developer’s Code

Reading other developers' code is one of the fastest ways to learn.

It exposes you to different coding styles, best practices, and new tools.

Additionally, resources like roadmap.sh can offer more ideas and pathways to expand your skill set.

Leverage Your Experience

As you gain experience, it's time to capitalize on your hard work.

• Update your resume with your new skills and completed projects.

• Highlight the technologies you’ve used and the problems you’ve solved.

• Start applying for more roles

• Look to get interviewed to learn your skill-gaps

Rinse and Repeat

This journey is iterative.

After completing a project and addressing your skill gaps, repeat the process to continuously build on the knowledge you’ve gained:

Identify New Skills

Regularly reassess and pinpoint the next set of skills you need to learn.

This process is continuous and should continue even after you get a job.

Expand or Start New Projects

Either enhance your existing projects to incorporate new skills or start a new project that challenges you in different ways.

You should look to continue even after getting a job. Side projects keep you on your toes and you can experiment as much as you want.

At the job, you may not be able to play with the latest technologies all the time.

Incorporate New Tools and Libraries

Continuously refine your code by incorporating libraries and tools you discover through research or by reading other developers’ work.

Refactor and Improve

Refactor your code to improve readability and performance, demonstrating your growth and commitment to quality software development.

By following these steps, you’ll create a solid foundation, gain practical experience, and confidently transition from quality assurance to full-time software development.

Conclusion

You’ve made it this far, but this is just the beginning.

The path from QA to full-time developer isn’t some distant dream—it’s within your reach.

You’ve already got the foundation, the drive, and the grit to make this transition. Now it’s about taking action, making strategic moves, and never letting the overwhelm keep you stuck.

But let’s be real: You can’t do it all alone.

Trying to piece together bits of advice from a hundred different sources will only slow you down.

You need a clear, focused plan that keeps you on track and shows you exactly what to do next.

That’s why I’ve put together a free mind map outlining the entire process—a proven guide to take you from where you are now to where you want to be.

And no, I’m not dumping it in this post because I want it in the hands of people who are committed to moving forward, people who are action-takers and who are serious about moving from QA to Developer.

If you’re ready to be one of those people, click the link below to get your free mind map.

Get Action Plan

And if you’re ready to supercharge your progress, don’t just stop at the mind map.

I’m hosting a FREE workshop that will walk you through building your projects—projects that employers can’t ignore.

It’s will provide you with a solid framework that you can use to build project after project.

Even after you get a job, you can use this framework to deliver projects on time without bugs.

Don’t wait—spaces are limited, and you don’t want to miss out.

Register

This is your moment.

Your opportunity to stop dreaming and start doing.

Click the links, grab the resources, and let’s make your transition to software development a reality.

You’ve got this.

🚨 Announcement 🚨
DM me to get a FREE code review session.

Subscribe now

A project in Spring Boot is littered with such annotations across the whole project.

But do you know what problems these annotations solve?

Why were custom annotations introduced to begin with?

How to create spring boot custom annotations?

Today, I will cover:

• Why create custom annotations?

• Key benefits of annotation

• How to create custom annotations?

• When to use custom annotations?

• When not to use custom annotations?

• What are the disadvantages of using custom annotations?

🎯 Why Create Custom Annotations?

In Spring Boot, annotations are more than just a way to add metadata. They

• Simplify complex tasks

• Reduce boiler-plate code

• Enhance code-readability

Before Spring introduced custom annotations, configurations like email validation were typically managed using XML configuration files.

The XML configuration would define beans, validators, and other necessary components to perform tasks such as validating email addresses.

Here's an example of how email validation might have been configured using XML in a Spring application:

As you can see, this can easily become a nightmare where there are hundreds of classes with many of them relying on each other.

It also meant a developer has to go look-up this XML every time they have to add a new dependency.

Key Benefits of Custom Annotations

Simplification of Configuration

Spring introduced custom annotations to simplify configuration by allowing developers to use annotations directly in their code.

This reduced the need for extensive XML configuration, making the codebase cleaner and easier to maintain.

Support for Declarative Programming

Custom annotations in Spring enable a declarative approach.

Developers can use annotations like @Transactional, @Cacheable, or @Scheduled to declare desired behaviors without writing the underlying logic.

This results in more readable and maintainable code.

Handling Cross-Cutting Concerns

Spring's custom annotations, often used in conjunction with Aspect-Oriented Programming (AOP), allow developers to handle cross-cutting concerns in a centralized manner.

For example, the @Transactional annotation can be used to manage transactions across multiple methods or classes without scattering transaction management logic throughout the code.

Reducing Boilerplate Code

It reduces the need for boilerplate code by encapsulating common behaviors.

For instance, the @Autowired annotation simplifies dependency injection, allowing Spring to automatically inject dependencies, rather than requiring explicit constructor or setter methods

Improving Code Readability and Consistency

By abstracting configuration and cross-cutting concerns into annotations, Spring improves the readability of the code.

You and your peer developers can quickly understand the purpose of a method or class by looking at its annotations, and annotations help enforce consistency across the codebase.

Framework Flexibility and Extensibility

Custom annotations allows developers to create their own annotations tailored to specific needs, thereby extending the framework's functionality in a standardized way.

This flexibility has helped Spring remain relevant and powerful across different types of applications and architectures.

🚀 How to Create a Custom Annotation

Step 1: Define the Annotation

• Create a new annotation by defining an interface.

• Use @interface to declare it.

• Add meta-annotations to specify how the annotation should behave.

• @Target: Indicates where the annotation can be used (e.g., methods, classes).

• @Retention: Indicates how long the annotation is retained (e.g., runtime, compile-time).

Step 2: Create an Aspect to Handle the Annotation

You can create a custom logic to process the annotation using Spring’s BeanPostProcessor, Aspect, or custom annotation processing logic.

Step 3: Apply the Annotation

Apply your custom annotation to methods, fields, or classes as defined

Use Cases Where Custom Annotations Are a Good Approach

Cross-Cutting Concerns

Custom annotations are ideal for handling cross-cutting concerns like logging, security, transaction management, and caching.

These are concerns that affect multiple parts of an application but are not related to the core business logic.

The @LogExecutionTime annotation above is a good example as that can be used across all the methods and it does not have any business logic.

Declarative Programming

When you want to specify what should happen rather than how it should happen, custom annotations provide a clean and expressive way to do this.

Annotations like @Cacheable or @Retry allow developers to enable caching or retry logic declaratively, without writing the implementation code manually.

Framework or Library Integration

Custom annotations can simplify the integration of frameworks or libraries by hiding the complexity behind an easy-to-use annotation.

Annotations like @Autowired in Spring help in injecting dependencies without having to manually instantiate them.

Encapsulation of Complex Logic

When complex logic needs to be encapsulated in a reusable way, custom annotations can provide a clean API for applying this logic.

An annotation like @RateLimit could encapsulate logic to limit the number of times a method can be called, without cluttering the method's body with this logic.

Use Cases Where Custom Annotations Should Not Be Used

Simple or One-Off Logic

If the logic is simple or only needs to be applied in a single place, creating a custom annotation is overkill and can unnecessarily complicate the code.

Logic That Requires Dynamic Behavior

Annotations are statically defined at compile-time, making them unsuitable for scenarios where behavior needs to be dynamically determined at runtime.

If a method's behavior should change based on user input or external configuration, handling this with custom annotations can lead to overly complex solutions.

Business Logic

Core business logic should not be abstracted into custom annotations, as this can make the logic less transparent and harder to maintain.

Using an annotation to encapsulate a business process like @ProcessOrder might hide important business rules, making the code harder to understand and maintain.

Complex Interactions Between Annotations

If the behavior depends on complex interactions between multiple annotations, it can lead to unexpected results and make the code difficult to understand and debug.

Combining multiple custom annotations that affect the same method (e.g., @Retry, @Cacheable, @LogExecutionTime) can result in unpredictable behavior and is difficult to manage

Performance-Critical Code

Custom annotations often rely on reflection or proxy mechanisms, which can introduce performance overhead. They should not be used in performance-critical sections of code.

Using a custom annotation to add logging to a method that is called millions of times in a tight loop could significantly degrade performance.

💡 TDLR - When to Use Custom Annotations

Custom annotations are perfect for handling cross-cutting concerns like logging, security, and transaction management.

They're also great for scenarios where you need to apply the same behavior across multiple parts of your application.

However, for simple, one-off logic, or where fine-grained control and flexibility are required, custom annotations might not be the best approach.

Consider the trade-offs before you decide to implement them.

🌟 Final Thoughts

Custom annotations are a powerful tool in your Spring Boot arsenal, but like any tool, they should be used judiciously.

They offer a clean, reusable way to handle repetitive tasks and enforce consistency across your codebase.

But be mindful of the potential downsides, especially when it comes to complexity and performance.

📣📣 Announcement

10-day cohort-based course for software developers and aspiring microservices architects on designing and implementing rate-limiting service using Spring Boot and Bucket4j.

You'll learn:

✅ How to design and build a production-ready microservice

✅ In-depth knowledge of rate-limiting algorithms and their implementation

✅ Best practices in Spring Boot development, testing, and containerisation

But it is also about

✅ breaking down the project into specific tasks

✅ Being accountable to yourself

✅ Designing and Building the project right

It is targeted at software developers who want to design and develop a microservice which is a use case relevant to most companies.

It's ESPECIALLY for those earlier in their software developer career who might not have "project experience" but tons of passion and ambition.

If this is something that you think will help you or even if you are just curious to know more:

Register your interest and I will let you know the workshop details.

Register

Before You Go

Thanks for your continued support and I look forward to provide valuable content through this newsletter!

Remember, this newsletter is always going to be free as going paid was never the plan.

But there are people who might need additional support through a guided workshop. So that is why, I am reaching out today for help from my readers 🙂

Because I saw lot of interest and queries that came up on the back of the post, I decided to create a guided workshop.

I'm thinking about building a live, 10-day cohort-based course for software developers and aspiring microservices architects on designing and implementing rate-limiting service using Spring Boot and Bucket4j.

You'll learn:

✅ How to design and build a production-ready microservice

✅ In-depth knowledge of rate-limiting algorithms and their implementation

✅ Best practices in Spring Boot development, testing, and containerisation

But it is also about

✅ breaking down the project into specific tasks

✅ Being accountable to yourself

✅ Designing and Building the project right

It is targeted at software developers who want to design and develop a microservice which is a use case relevant to most companies.

It's ESPECIALLY for those earlier in their software developer career who might not have "project experience" but tons of passion and ambition.

If this is something that you think will help you or even if you are just curious to know more:

Register your interest and I will let you know the workshop details.

Register

PS: Now I know, you might be a person with decades of experience and may not need the workshop.

But if you have any feedback that will help me, please provide the feedback using the below button.

Provide Feedback

P.PS: If you know someone who will be benefit from this course, please share the link.

Share Link

Thanks for your continued support and I look forward to provide valuable content through this newsletter!

Remember, this newsletter is always going to be free as going paid was never the plan.

But there are people who might need additional support through a guided workshop. So that is why, I am reaching out today for help from my readers 🙂

Today, I will do something special.

If you subscribe to this newsletter, you will get a FREE code review session.

Subscribe now

Have you ever started a project, only to find yourself stuck midway and ultimately abandoning it?

You're not alone.

Many developers face feelings of overwhelm, frustration, and a lack of progress, leading to the abandonment of their projects.

But did you know that the root cause of these issues often lies in mistakes made even before you start?

Common Pitfalls to Avoid

Here are five common mistakes that can lead to feelings of being overwhelmed and stuck:

1. Lack of Learning Goals

One of the cardinal mistakes new developers make is not having clear learning goals. As Stephen Covey mentions in The 7 Habits of Highly Effective People, it’s crucial to "begin with the end in mind." Without defined learning objectives, you may lose sight of the purpose behind your project. Ask yourself:

• What do I want to learn from this project?

• What skills or knowledge will I gain?

2. Jumping In Without Preparation

Many developers skip essential background work and dive straight into coding after reading a blog or watching a video. Instead, break down your project into smaller, manageable chunks. This approach, often used in corporate environments, allows you to track progress and visualize your achievements, making it easier to identify when you're stuck.

3. Choosing a Complex Project

It's easy to underestimate the complexity of a project, especially if you’ve seen it executed by an expert. Remember, only an experienced developer can accurately assess a project's difficulty. If you take on something too complex, you may find yourself overwhelmed and unsure of how to proceed.

4. Using an Outdated or Cutting-Edge Technology Stack

Selecting the right technology stack is crucial. Using outdated technology may not be taken seriously by employers, while cutting-edge technologies can leave you feeling lost. If you're learning new technologies that few others have experience with, you might encounter unique challenges that are difficult to solve.

5. Lack of Mentorship

Working without a mentor can be detrimental. A mentor can provide guidance on whether your project is too complex, help you navigate challenges, and keep you on the right path. Without this support, you may struggle in isolation, missing out on valuable learning experiences.

The Consequences of Abandonment

Abandoning a project not only means losing the opportunity to learn but can also impact your resume and future job prospects. Some developers, feeling discouraged, default to easier problems that offer minimal growth, missing out on the significant achievements they could have gained from tackling more challenging projects.

Join Free Workshop!

I've seen these challenges affect many developers, which is why I'm hosting a free workshop to teach a specific framework that can help you overcome these obstacles.

If you're interested, email me to get the details..

And if you know someone else who might benefit from this workshop, feel free to share this message with them!

Thank you for your time, and I look forward to helping you achieve your project goals!

Before you go!

If you know someone who is looking to have their code reviewed for technical debts, code smell - look no further.

Help is here.

Just subscribe to this newsletter or reply to this email with word “REVIEW” and I will review your code

Subscribe now

Today, I will do something special.

If you subscribe to this newsletter, you will get a FREE code review session.

Subscribe now

The Biggest Mistake

Do you know what one of the biggest mistakes that most developers make when starting out is?

It's focusing too much on solving LeetCode problems and understanding Data Structure and Algorithms (DSA).

While these are important, they shouldn't be the sole focus of your learning journey. Here's why:

• Practical Experience
  Spending all your time on LeetCode and DSA may cause you to miss out on practical experience, which is crucial for your career growth.

• Job Requirements
  On the job, you'll be working on problems that span multiple systems. This requires a different set of skills that solving LeetCode does not provide.

• Reading and Research
  In a professional setting, you'll spend a lot of time reading API specs, requirement documents, language documentation, and library documentation.

The Value of Projects

Instead of solely focusing on LeetCode problems, consider building projects with specific learning objectives. Here's why projects are valuable:

• Real-life Experience
  Projects provide practical experiences that are more relevant to real-world job requirements.

• Integration and System Knowledge
  Through projects, you'll learn to integrate systems, understand domains, and gain valuable domain-specific knowledge.

• Interview Preparation
  Many companies prioritise practical skills and domain knowledge over advanced algorithms, making project experience more valuable in interviews.

Workshop Announcement

Now, if you are looking to build project I am in the process of creating a workshop that will help you in your journey to create relevant project.

Let me know if you are interested.

Thank you for reading and stay tuned for more valuable insights for developers!

Before you go!

If you know someone who is looking to have their code reviewed for technical debts, code smell - look no further.

Help is here.

Just subscribe to this newsletter or reply to this email with word “REVIEW” and I will review your code.

Subscribe now

Today, I will do something special.

If you subscribe to this newsletter, you will get a FREE code review session.

Subscribe now

If you've been in software development, you've likely come across the concept of loosely coupled design.

You may understand what it is, but have you seen how it's implemented in practice?

In this post, I'm going to show you a real-world example of how loosely coupled architecture can make a significant impact in a production environment.

The Urgent Issue

The other day at work, I was tasked with fixing an urgent issue due to a change in a vendor system that we integrate with.

Typically, this kind of scenario would require running an entire suite of regression tests and involving quality engineers or software testers.

However, because of our loosely coupled architecture, the change was minimal and only required a small unit testing, avoiding the need for extensive regression testing.

The Architecture

Our architecture consists of a vendor application with an internal database exposed via a public API, which is accessed through an integration API by the front end.

When the vendor system made a change, we only needed to update the mapping in the integration API without altering the contract between the front end and the integration API.

This meant that the front end did not require extensive regression testing, showcasing the benefits of a loosely coupled architecture.

The Alternative

I also want to illustrate the alternative scenario where the front end directly accesses details from the public API.

In this tightly coupled system, any change in the public API would require the front end to change, leading to the need for extensive regression testing and the front end taking on additional responsibilities such as authentication, error handling, and retries.

Benefits of Loosely Coupled Architecture

The contrast between the two scenarios highlights the benefits of a loosely coupled architecture:

Isolation of changes

A change in one system does not affect the entire system

Reduced blast radius

Changes are contained within specific components, minimizing the impact on the overall system

Abstraction of complexities

Authentication, error handling, and retries are handled in the integration layer, abstracted away from the front end

In conclusion, a loosely coupled architecture provides numerous advantages in software development, ensuring that changes are isolated and do not disrupt the entire system.

Thank you for reading! If you found this information valuable, please like and share to help others benefit from it as well

Before you go!

If you know someone who is looking to have their code reviewed for technical debts, code smell - look no further.

Help is here.

Just subscribe to this newsletter or reply to this email with word “REVIEW” and I will review your code.

Subscribe now

Today, I will do something special.

If you subscribe to this newsletter, you will get a FREE code review session.

Subscribe now

Two major IT outages occurred on Friday, throwing airports, aeroplanes and people staring at the blue restart screen.

The details of the issues are here:

The CrowdStrike Cybersecurity Software Issue

• An update sent out by CrowdStrike caused a bug that prevented Windows systems from starting up, leading to an endless loop of blue screens.

• The issue primarily affected Windows systems, while Mac and Linux users remained unaffected.

• The incident highlights the potential impact of software bugs on system functionality and productivity.

The Microsoft Azure Cloud Outage

• The Azure Cloud outage was more widespread, impacting systems accessing the centralized cloud services.

• The issue involved a blockage or disabled access between computer and storage resources, leading to system downtime.

• While the impact was limited to the US data centre, the incident raises concerns about the reliability of cloud services for businesses and organizations.

Preventing Future Outages

• Manual Intervention: Implementing manual recovery options, such as safe mode access and file deletion, can help address software-related issues.

• Alternate Backup Systems: Having standby options, such as utilizing multiple cloud providers, can mitigate the impact of cloud service outages.

• AI Automation: Leveraging AI for automated testing and recovery processes can provide efficient solutions, but it also poses long-term risks and dependencies.

The Dangers of Overreliance on AI

• While AI automation offers efficiency, there are concerns about potential knowledge gaps and dependencies on AI systems for critical operations.

• Overreliance on AI may lead to a lack of understanding and control over system issues, posing risks for future troubleshooting and recovery efforts.

Seeking Feedback and Solutions

Apart from adding processes to prevent manual slip-ups, what else do you think should get implemented to recover or prevent such incidents?

In conclusion, the recent IT outages serve as a reminder of the importance of proactive measures and contingency plans to prevent disruptions in critical systems.

By considering manual interventions, backup systems, and the potential risks of overreliance on AI, organizations can work towards minimizing the impact of IT outages and ensuring the resilience of their IT infrastructure.

What are your thoughts on preventing IT outages? Share your insights and suggestions in the comments below.

Thank you for reading and stay tuned for more discussions on IT resilience and recovery strategies.

Before you go!

If you know someone who is looking to have their code reviewed for technical debts, code smell - look no further.

Help is here.

Just subscribe to this newsletter or reply to this email with word “REVIEW” and I will review your code.

Subscribe now

Remember, all subscribers can get their code reviewed. This newsletter will always be free. So go ahead and click on the Subscribe button.

Subscribe now

Are you a passionate developer looking to learn complex software in a short amount of time?

This can happen if you have to transition to a new team or a new organisation.

The challenge is there would be a lot of information lying around and you have to make sense in a short time.

If you have not done this before, it feels daunting.

The other problem is that as you do not have all the context, some of the answers you get might be conflicting or confusing.

In this blog post, we'll discuss the steps you can take to navigate this challenge and come up to speed with a new technology stack.

Talking to People

The first step in learning complex software quickly is to start talking to people. By engaging in conversations with your colleagues, you can gain valuable insights into the processes and lingo used in the new technology stack. This can often uncover important information that may not be documented elsewhere.

Reading Documentation

While reading documentation is important, it's essential to complement this with conversations with your peers. By doing so, you can link the information you gather from documentation with real-world scenarios, helping you retain and solidify your understanding of the software.

Asking "Dumb" Questions

Don't be afraid to ask questions, even if they seem basic or "dumb." Asking questions can clarify concepts and uncover hidden assumptions, ultimately leading to a better understanding of the software.

Reading Pull Requests and Code

For developers, reading pull requests and code can provide valuable insights into how people collaborate and adhere to quality standards. This can also help you learn about new technologies and gain a deeper understanding of the software.

Pairing Up

If possible, try to pair up with a colleague who can guide you through the initial learning process. This can provide you with valuable insights and help build your confidence in working with the new technology stack.

Playing Around

Having access to a test environment can allow you to play around with the software, enabling you to learn through trial and error. This hands-on approach can deepen your understanding of the system architecture.

Understanding Data and Request Flow

To comprehend a complex software architecture, it's crucial to understand the data and request flow. By grasping how data moves through different processes and systems, you can gain a better understanding of the software's complexity and integration.

Maintaining an Engineering Log

Consider maintaining a log of your learning journey, documenting the concepts and insights you gather each day. This can serve as a personal knowledge repository, allowing you to refer back to previous learnings and track your progress.

By following these steps, you can effectively learn a complex software quickly and come up to speed with a new technology stack. Remember, learning by doing and seeking guidance from your peers can significantly accelerate your learning process.

Don't forget to like and share this blog post if you found it helpful. Sharing this information can benefit others who may be facing similar challenges.

Thank you for reading!

Before you go!

If you know someone who is looking to have their code reviewed for technical debts, code smell - look no further.

Help is here.

Just subscribe to this newsletter or reply to this email with word “REVIEW” and I will review your code.

Subscribe now

Remember, all subscribers can get their code reviewed. This newsletter will always be free. So go ahead and click on the Subscribe button.

Subscribe now

In a previous video, we discussed how GitHub improved its performance and reliability by incorporating Kafka into their architecture. If you haven't watched the video yet, you can find the link in the description.

What is Kafka?

To understand the role of Kafka in the microservices world, let's start with an analogy. Think back to the days of scheduled TV broadcasts, where missing a show meant you might never get to watch it again.

This is in stark contrast to today's streaming services like Netflix, where you can watch shows at any time with the click of a button.

itsKafka operates similarly in the microservices world, ensuring that systems remain consistent and robust even when individual services experience downtime.

How Kafka Works in Microservices

Consider a scenario with three services: order service, payment service, and stock service, each with its own specific function. In a normal operation, these services interact seamlessly. However, if the stock service were to go down, it could create a discrepancy in the system. This is where Kafka comes into play, ensuring that events are recorded and processed consistently, even when services experience downtime.

Using Kafka, the order service simply announces when an event occurs, such as a new order being placed.

The payment and stock services listen for these events and perform their respective functions accordingly. If the stock service were to go down, the payment service would generate an event indicating that the payment has been verified.

When the stock service comes back online, it can retrieve and process all missed events, ensuring system consistency.

Benefits of Kafka in Microservices

Kafka offers several benefits in a microservices architecture, including:

• Event-driven architecture: Kafka enables a decoupled, event-driven approach to microservices communication, ensuring that services can operate independently.

• Fault tolerance: With Kafka, services can recover and process missed events, maintaining system consistency even in the event of downtime.

• Scalability: As the number of services in a microservices architecture grows, Kafka provides a scalable solution for managing event processing.

Conclusion

Kafka plays a crucial role in ensuring the reliability and consistency of microservices architecture.

By providing a robust event-driven communication platform, Kafka enables seamless interaction between services, even in the face of downtime.

If you're interested in learning more about Kafka and its complexities, feel free to reach out to me.

If you found this content helpful, let me know in the comments or by liking the post.

Before you go!

If you know someone who is looking to have their code reviewed for technical debts, code smell - look no further.

Help is here.

Just subscribe to this newsletter or reply to this email with word “REVIEW” and I will review your code.

Subscribe now

Remember, all subscribers can get their code reviewed. This newsletter will always be free. So go ahead and click on the Subscribe button.

Subscribe now

If you have been following GitHub Engineering Blog, you would have seen how they changed their approach to processing 300 million daily pushes. 

If not, help is here.

300 million pushes per day is significant, and it’s fascinating to see how they tackled the challenges associated with such a large volume of operations.

In this video, I’ll be going through the key points from the blog and discussing how you can apply the learnings to your day-to-day work. 

It’s one thing to read about a company’s experience, but it’s another to understand how you can implement similar strategies in your own projects.

The blog highlighted the issues GitHub faced with their previous approach, where a monolithic process triggered by each push resulted in a sequence of 50+ tasks being executed.

This sequential process led to increased latency, a higher risk of system failure, and difficulties in troubleshooting and testing.

To address these challenges, GitHub introduced Kafka to create a job queue bridge. 

It split the monolithic job into multiple independent tasks that could be run in parallel. 

This approach led to several advantages, including improved performance, easier troubleshooting, and the ability to scale specific tasks as needed.

So, how can you apply these lessons to your own work? 

Even if you’re not dealing with the scale of GitHub, you may encounter similar issues with tightly coupled systems, complex classes, and difficult testing processes. 

Here are some key takeaways:

• Break down complex classes into smaller, more manageable pieces to make testing easier

• Consider making tightly coupled systems asynchronous to improve performance and reduce waiting times

• Break down large processes into modular components to simplify testing and maintenance

• Implement retry mechanisms for integrations with multiple systems, but be mindful of the potential impact on system load and performance

It’s important to learn from the experiences of companies like GitHub and adapt their strategies to your own projects. 

By addressing issues related to system complexity, testing, and performance, you can improve the overall reliability and efficiency of your own systems.

Have you faced similar challenges in your own work? How did you overcome them? 

 I’d love to hear about your experiences in the comments below.

And don’t forget to check out the original blog on the GitHub Engineering Blog for more in-depth information on their approach to processing 300 million pushes every day.

Before you go!

If you know someone who is looking to have their code reviewed for technical debts, code smell - look no further.

Help is here.

Just subscribe to this newsletter or reply to this email with word “REVIEW” and I will review your code.

Subscribe now

👋 Hi, this is Dishit with this week’s newsletter. I write about software engineering, clean code and developer productivity.

I am trying something new here. So let me know how this video podcast feels.

As an upcoming developer, you would have read posts about scaling to millions of users. The engineering approaches that big companies like LinkedIn, Facebook or Google took to scale to millions.

But you may be working for a company that is serving 100 customers a day. Maybe a 1000, 100,000 or even a million.

So you cannot apply those strategies for your code as it will become costly.

You do not want to drive a Ferrari to the grocery store.

The other problem is your organization wants to deliver fast. Your wife needs milk and eggs now. She doesn’t want to wait until you have enough money to buy a Ferrari.

So what can you do in your situation?

Well, the first thing should be how can you do the right thing for your small set of customers.

How will they feel when they use your product?

What will their journey look like?

Can a small car help you get the milk and eggs in time?

The second piece would be how your peers will look at the product you build. Is it easy to understand? Or will your code have them pulling their hairs out?

If you are not there, will your car be easy enough to drive for your wife?

The last bit is how it will help your organisation.

Are you making pragmatic choices that do not sacrifice speed to quality?
Are you building a robust product so that there are minimal issues when it goes to production?
Can your car be used for grocery shopping a thousand times without breaking down?
An engineer needs to walk the tightrope of balancing quality, speed and customer satisfaction.

All the big companies Facebook, Google, Netflix went through these phases and earned the customer's trust which gave them the problem to scale. And they scaled.

But for you, focus should be the foundation. 

Foundation includes understanding what makes the software maintainable, stable, performant, resilient and secure.

So going back to the initial question - Should you be reading about scaling?

Yes, and you also need to focus on the foundation so that you make your existing customers and organisation happy.

Drop a Y in the comments if having a strong foundation is important before scaling.

👋 Hi, this is Dishit with this week’s newsletter. I write about software engineering, clean code and developer productivity.

Remember, all subscribers can get their code reviewed. So go ahead and click on the Subscribe button.

Design patterns are powerful tools for building robust, maintainable software, but they have challenges.

It is all good to implement design patterns in the sample project. But it becomes a different beast when it comes to real-world projects.

Understanding these challenges can help you use design patterns more effectively.

A Quick Intro to Design Patterns

In software development, design patterns are crucial because they provide time-tested solutions to common problems.

As software projects grow in complexity, the need for a structured approach becomes evident.

Design patterns offer a shared vocabulary and understanding that can enhance collaboration among developers.

• Efficiency: Design patterns streamline the development process by providing standard solutions, reducing the need for reinventing the wheel.

• Maintenance: Well-implemented patterns lead to code that is easier to understand and modify.

• Scalability: Design patterns help build systems that can grow and adapt to changing requirements.

There are three main categories of design patterns:

1. Creational Patterns: Deal with object creation mechanisms, trying to create objects in a manner suitable to the situation.

   • Examples: Singleton, Factory, Builder, Prototype

2. Structural Patterns: Deal with object composition, forming larger structures from individual parts.

   • Examples: Adapter, Composite, Decorator, Proxy, Facade

3. Behavioral Patterns: Deal with communication between objects, defining how they interact and distribute responsibilities.

   • Examples: Observer, Strategy, Command, Chain of Responsibility

Design Pattern Challenges

While design patterns offer numerous benefits, they can also introduce complexities, especially for those new to the concept.

Recognizing these challenges can help in better navigating their implementation.

• Learning Curve: Understanding and correctly applying design patterns requires a solid grasp of object-oriented principles and experience.

• Overuse: Misapplying patterns or using them unnecessarily can lead to overly complex code.

• Contextual Fit: Not every pattern is suitable for every problem; choosing the right one is critical.

• Communication: Misunderstandings among team members about how or why a pattern is used can lead to inconsistencies.

Key Issues with Design Patterns

Overengineering

This is one of the biggest issues with design patterns.

Developers may implement design patterns where simpler solutions would suffice, leading to overcomplicated code.

Most often, it is the simple code that will get the job done.

Incorrect Pattern Selection

You can make the code complicated and inefficient by choosing the wrong design pattern for a specific problem.

A better approach would be to write simple code first and then let it marinate in production for a while.

As requirements become clearer, it becomes easier to select the pattern as now you can see the pattern forming.

Rigid Designs

The problem with implementing patterns earlier than required leads to the problem of rigid design.

Other developers tend to follow the existing design.

This creates hacks or workaround to get the requirement to fit the design.

It takes a brave developer to question and rewrite the code.

But that means more overhead in testing and loss of productivity.

Strategies for Effective Use of Design Patterns

• Invest time in thoroughly understanding each design pattern, its use cases, and its benefits.
  It takes a while to get a complete understanding of the patterns.

• Assess whether a design pattern is necessary or if a simpler solution will suffice. It is better to err on the side of simplicity as in the beginning there are lot of unknowns.

• Regularly review and refactor code to keep the code healthy.
  As requirements change, you will find some of the code can use design patterns. Similarly, you will find some patterns no longer fit the requirements and will need a change.

• Use common knowledge-sharing sessions to get other develoeper’s eyes on existing patterns or even before implementing a pattern

• Documenting the reason for a pattern can help future developers assess if the pattern still helps in meeting the requirements.
  

Design patterns are indispensable tools in the software developer's toolkit, providing proven solutions to common problems and fostering code that is robust, reusable, and maintainable.

However, like any powerful tool, they come with their own set of challenges.

Understanding these challenges and learning how to navigate them is crucial for leveraging the full potential of design patterns.

Take Action Today:

1. Deepen Your Knowledge: Dedicate time to study and understand various design patterns and their applications.

2. Practice Wisely: Implement patterns in your projects, starting with simple use cases and gradually tackling more complex scenarios.

3. Seek Feedback: Engage in code reviews and discussions with your team to refine your understanding and application of design patterns.

4. Reflect and Refactor: Regularly review your codebase to identify opportunities for improvement and refactoring using appropriate patterns.

   ---

Subscribe now and start building better, smarter software today! 🚀.

Before you go!

If you know someone who is looking to have their code reviewed for technical debts, code smell - look no further.

Help is here.

Just subscribe to this newsletter or reply to this email with word “REVIEW” and I will review your code.

Share Weekend Developer

Remember, all subscribers can get their code reviewed. So go ahead and click on the Subscribe button.

Subscribe now

Have you wondered when people talk about technical debts?

How can so many senior developers still write code that has technical debts?

You are proud of your work. But are you unsure of what constitutes technical debt?

Here is what all you need to know about “Technical Debt”

Origins

The term "technical debt" was coined by Ward Cunningham, an American computer programmer who developed the first wiki and was a co-author of the Manifesto for Agile Software Development

In the early 1990s, Cunningham was working on the WyCash portfolio management system.

The project required rapid development and deployment to meet business demands.

Cunningham needed a way to explain to non-technical stakeholders, the long-term implications of making quick and dirty fixes or taking shortcuts in the codebase.

Cunningham drew an analogy between financial debt and the quick solutions often implemented in software development.

He compared the shortcuts (such as writing suboptimal code to meet a deadline) to borrowing money.

Just as borrowing can accelerate financial growth temporarily but requires repayment with interest, quick coding solutions can speed up development but incur future costs in terms of increased maintenance and refactoring efforts.

The Famous Explanation

Cunningham famously explained the concept as follows:

"Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt."

How Is Technical Debt Created in Projects?

Despite best intentions, there will always be technical debts in software projects. It is like the battery which has its internal resistance. So the output a battery delivers is always minus its internal resistance.

Technical debt can sneak into your projects in several ways:

1. Rushed Development: When deadlines are tight, you might prioritise shipping features over writing clean, maintainable code.

   • Example: You copy-paste code instead of refactoring it into a reusable function.

   • Example: You take an informed decision as there could be a scenario where a dependent system might not be ready and you need to get a tactical fix done.

2. Lack of Documentation: Skipping documentation can speed things up, but it makes it harder for others (or future you) to understand the code.

   • Example: You skip writing comments and documentation thinking you’ll “remember it later.”

3. Poor Testing: Insufficient testing can lead to hidden bugs that need to be fixed later, adding to the debt.

   • Example: Tests are written towards the end of writing a feature. So some key tests might be missed in the excitement of coding the next feature.

4. Ignoring Refactoring: As new features are added, failing to refactor the codebase to accommodate them cleanly can create a tangled mess.

   • Example: You keep adding if-else conditions to handle new cases instead of redesigning the logic properly.

   • Example: Boiler-plate code is duplicated where a particular functionality is required. Using inheritance or other techniques this can be removed. But until then it adds technical debt.

5. Avoiding version upgrades: Versions of libraries or the used frameworks need to be kept updated. Each version upgrade also leads to the deprecation of some of the features.

   • Example: Certain methods and classes get deprecated whenever Java releases new versions. These need to be updated to ensure your codebase is robust as this could have security implications.

6. Lack of Developer Toolings: There are developer tools like sonar and spotbugs that can detect potential code smells and technical debt.
   
   Integrating them into the deployment pipeline can help you mitigate many of the issues, as these tools can raise flags for common issues.

What If There Is Too Much Technical Debt?

Just like financial debt, too much technical debt can become overwhelming. Here’s what can happen:

• Decreased Productivity: Developers spend more time fixing bugs and understanding convoluted code rather than building new features.

• Increased Bugs: A messy codebase is more prone to errors, leading to a more unstable product.

• Higher Costs: The longer you wait to address technical debt, the more expensive and time-consuming it becomes to fix.

• Team Morale: Working with bad code is frustrating and can lead to burnout among developers.

• Security Risk: Lack of upgrading to newer versions of libraries and frameworks can lead to security risks that can expose you or your organization to external threats.

Managing Technical Debt

So, how do you manage technical debt? Here are some practical tips:

1. Prioritize Refactoring: Set aside regular time for refactoring and code cleanup. Treat it as an essential part of your development process. Better still, add code clean-up time as a factor in project estimations.

   • Example: Allocate a day each sprint for code improvement tasks.

2. Write Tests: Invest time in writing unit tests and integration tests to catch issues early.

   • Example: Aim for a certain percentage of code coverage and stick to it. Block builds that does not meet the defined criteria.

3. Document as You Go: Maintain clear and concise documentation to make future maintenance easier.

   • Example: Use tools like Javadoc in Java to generate documentation from comments in your code.

4. Review Code: Conduct code reviews to ensure quality and catch potential issues before they merge into the main codebase.

   • Example: Implement a peer review system where every piece of code is reviewed by at least one other developer.

5. Communicate with Stakeholders: Make sure everyone understands the impact of technical debt and the importance of addressing it.

   • Example: Include technical debt discussions in your project meetings and reports.

In conclusion, technical debt is a natural part of the development process, but it’s crucial to manage it effectively.

By understanding why it happens and taking proactive steps to address it, you can keep your codebase healthy and your projects on track.

Before you go!

If you know someone who is looking to have their code reviewed for technical debts, code smell - look no further.

Help is here.

Just subscribe to this newsletter or reply to this email with word “REVIEW” and I will review your code.

Share Weekend Developer

👋 Hi, this is Dishit with this week’s newsletter. I write about software engineering, clean code and developer productivity.

Today, I will do something special.

If you subscribe to this newsletter, you will get a FREE code review session.

Subscribe now

Thank you for your readership 🙏 🎉

Are you afraid to make any changes to the code because it might cause production incidents?

Are you suffering from burnout with constant firefighting with the production code?

Do you find that software test engineers find the most bugs in your code?

The problem could be that you are not writing unit tests right.

It is a common problem in the industry as writing unit tests are treated as a chore in most organisations.

Teams want fast delivery and writing unit tests slows down the delivery.

The problem does not start there. The problem begins with the way programming is taught in most places.

Writing unit tests is one of the later chapters that you learn when learning programming.

As a developer, you do not value writing tests when you could already smash out code that works out of the box.

I understand that as I felt the same way. I also did not understand why you have to prove that your code works when you already know it works.`

So you tend to avoid it.

But once you start writing code in a job, you discover you need to write those unit tests along with the code.

But the problem is you have never learned it right.

You also do not have time to invest in learning to write tests.

So here are the 10 common mistakes most developers make:

1. Not Isolating Tests

Unit tests should test a single unit of code in isolation. Dependencies should be mocked or stubbed. Testing multiple units together turns it into an integration test.

Mistake

@Test
public void testServiceMethod() {
    Service service = new Service();
    Database database = new Database(); // Real database, not a mock
    
    service.setDatabase(database); // Injecting a real dependency
    
    assertEquals("ExpectedResult", service.methodUnderTest());
}

Fix

@Test
public void testServiceMethod() {
    Service service = new Service();
    Database mockDatabase = Mockito.mock(Database.class);
    
    Mockito.when(mockDatabase.getData()).thenReturn("MockData");
    service.setDatabase(mockDatabase); // Injecting a mock dependency
    
    assertEquals("ExpectedResult", service.methodUnderTest());
}

This could also lead to flaky tests.

Mistake

@Test
public void testDatabaseQuery() {
    Database database = new Database(); // Real database connection
    database.connect();
    
    List<User> users = database.query("SELECT * FROM users");
    assertEquals(10, users.size());
}

The problem in the above code is that if the values in the database change then the test fails. e.g. If someone adds a row without your knowledge above test will return 11 and the assertion will fail.

Fix

@Test
public void testDatabaseQuery() {
    Database mockDatabase = Mockito.mock(Database.class);
    List<User> mockUsers = Arrays.asList(new User("user1"), new User("user2"));
    
    Mockito.when(mockDatabase.query("SELECT * FROM users")).thenReturn(mockUsers);
    
    List<User> users = mockDatabase.query("SELECT * FROM users");
    assertEquals(2, users.size());
}

2. Ignoring Edge Cases

Ignoring edge cases can lead to missing bugs that occur under special conditions.

Mistake

@Test
public void testPositiveNumbers() {
    assertEquals(2, MathUtil.add(1, 1));
}

Fix

@Test
public void testAdd() {
    assertEquals(2, MathUtil.add(1, 1));
    assertEquals(0, MathUtil.add(-1, 1));
    assertEquals(-2, MathUtil.add(-1, -1));
    assertEquals(Integer.MAX_VALUE, MathUtil.add(Integer.MAX_VALUE, 0));
}

3. Not Using Assertions Properly

Failing to use proper assertions can lead to tests that pass even when the code is incorrect.

Mistake

@Test
public void testStringConcat() {
    String result = StringUtil.concat("Hello", "World");
    if (!result.equals("HelloWorld")) {
        throw new RuntimeException("Test failed");
    }
}

Fix

@Test
public void testStringConcat() {
    String result = StringUtil.concat("Hello", "World");
    assertEquals("HelloWorld", result);
}

4. Testing Implementation Details Instead of Behavior

Tests should focus on the behavior of the code rather than its implementation details. This ensures that tests remain valid even if the internal implementation changes, as long as the behavior remains the same.

Mistake

@Test
public void testSortingImplementation() {
    List<Integer> list = Arrays.asList(3, 2, 1);
    list.sort(Integer::compareTo);
    
    assertTrue(list.get(0) < list.get(1) && list.get(1) < list.get(2));
}

Fix

@Test
public void testSortingBehavior() {
    List<Integer> list = Arrays.asList(3, 2, 1);
    List<Integer> sortedList = SortUtil.sort(list);
    
    assertEquals(Arrays.asList(1, 2, 3), sortedList);
}

5. Ignoring Maintainability

Tests should be easy to read, understand, and maintain. Complex and convoluted test cases make it difficult to diagnose issues.

Each test should have 1 assert.

Each test should test one concept or 1 behaviour. If it tests multiple concepts, the test will be complex and hard to maintain.

You want your tests to be dumb.

Mistake

@Test
public void testComplexScenario() {
    Service service = new Service();
    service.setConfig("config1", "value1");
    service.setConfig("config2", "value2");
    service.initialize();
    
    assertTrue(service.isInitialized());
    service.performAction("action1");
    assertEquals("result1", service.getResult());
    service.performAction("action2");
    assertEquals("result2", service.getResult());
}

Fix

@Test
public void testInitialization() {
    Service service = new Service();
    service.setConfig("config1", "value1");
    service.setConfig("config2", "value2");
    service.initialize();
    
    assertTrue(service.isInitialized());
}

@Test
public void testPerformAction1() {
    Service service = new Service();
    service.initialize();
    service.performAction("action1");
    
    assertEquals("result1", service.getResult());
}

@Test
public void testPerformAction2() {
    Service service = new Service();
    service.initialize();
    service.performAction("action2");
    
    assertEquals("result2", service.getResult());
}

6. Not Testing for Exceptions

Failing to test for expected exceptions can result in unhandled edge cases and bugs.

Test exception is hard. So simplify by minimising exceptions. If possible, only let the top-level service handle the exception. This depends on the context.

But not testing an exception can cause real pain so beware.

Mistake

@Test
public void testInvalidInput() {
    Service service = new Service();
    service.processInput("validInput");
    // No test for invalid input
}

Fix

@Test(expected = IllegalArgumentException.class)
public void testInvalidInput() {
    Service service = new Service();
    service.processInput("invalidInput");
}

7. Not Cleaning Up After Tests

Tests should clean up any resources they use to avoid side effects on other tests.

If cleaning up is not done, it will make your tests flaky.

The problem with flaky tests is they make your tests unreliable.

It is as good as if there are no tests.

Mistake

@Test
public void testFileCreation() throws IOException {
    File file = new File("testFile.txt");
    FileWriter writer = new FileWriter(file);
    writer.write("Test data");
    writer.close();
    
    assertTrue(file.exists());
}

Fix

@Test
public void testFileCreation() throws IOException {
    File file = new File("testFile.txt");
    try (FileWriter writer = new FileWriter(file)) {
        writer.write("Test data");
    }
    
    assertTrue(file.exists());
    
    if (file.exists()) {
        file.delete();
    }
}

Now these are some of the common problem that can be solved.

But this list is not complete as there might be some scenarios that will be unique to your situation.

So I am giving Free code review sessions if you subscribe to the newsletter.

Subscribe now

Existing Subscribers

Being an existing subscriber, you also get a FREE code review session. Reply to this email with “REVIEW” and I will send your the booking details.

Meanwhile, please recommend this newsletter if you liked the article.

Share Weekend Developer