I have a Kafka cluster running on my laptop right now, and I have not written a single line of Java against it yet. That was on purpose, and it is the best decision I made in this whole course.

Let me tell you what I found in there.

First, here’s the repo for you to practice with along the way, too.

THE MODEL YOU ARRIVE WITH

Most of us meet Kafka after years of something else. RabbitMQ. SQS. ActiveMQ.

So we arrive carrying a picture. A producer pushes a message in. A consumer pops it off. The message is gone.

It is a good picture. It is also the single biggest reason Kafka feels confusing.

Because if consuming destroys, then consumer groups look like bureaucracy. Offsets look redundant, since the message left already. And replay looks like magic, or worse, like a feature somebody bolted on.

Here is the truth: none of those are features. They are consequences.

Kafka is not a queue. Kafka is a log.

A queue destroys. Its entire job is to reach empty.

A log remembers. It is closer to a file that many programs append to and many programs read from, independently, at their own pace.

Nothing is removed when you read it. All you did was move a bookmark.

PICTURE IT

One partition. Six records, at offsets 0 through 5.

Your billing service has read as far as offset 2. Your search indexer has read all the way to 5.

One copy of the data. Two readers. Two different positions. Neither one aware the other exists.

Billing falling behind cannot slow the indexer down. The indexer racing ahead cannot delete anything billing still needs.

Records leave when a retention policy says so, after seven days or once the log outgrows a size limit. Never because somebody read them.

That is the entire pitch. And three things fall out of it for free.

You can replay. Shipped a consumer that mangled yesterday’s data? Fix it, move the bookmark back, reprocess. In a queue those records are ash.

You can add a reader later. A brand new service reads history from the beginning without asking permission and without touching anyone else’s position.

Reading is cheap and parallel. No coordination between applications, because nobody is competing to destroy anything.

THE PART WHERE I STOPPED TRUSTING THE DIAGRAM

Everything above is what the docs tell you. It is also what I would have happily repeated in an interview without ever having checked.

So I checked.

Here is the thing I wish someone had told me earlier: you do not need to create a topic to look inside a real Kafka log. Your broker already has one. It keeps its own cluster metadata in a partition, using exactly the structure the diagram promised.

docker exec kafka-1 ls /var/lib/kafka/data/

One directory comes back: __cluster_metadata-0. Named topic, dash, partition number. Every topic you ever create will add a directory with that same shape.

Go one level deeper and the abstraction gets physical.

docker exec kafka-1 ls /var/lib/kafka/data/__cluster_metadata-0/

A partition is not one enormous file. It is a series of segments, and each segment is three files sharing a name, and that name is the offset the segment starts at.

The .log holds the records. The .index is a sparse map from offset to byte position. The .timeindex is a sparse map from timestamp to offset.

Notice what those two index files are for. A log that is only ever appended to and read forward should not need them. But consumers do not always read forward from where they are. A consumer coming back from a restart says “give me offset 4711”, and without an index that means scanning the segment from byte zero.

Sparse, not complete. One entry every few kilobytes. Kafka trades a little scanning for a much smaller index, and gets seek-by-offset and seek-by-timestamp out of it.

Then I read the actual records.

docker exec kafka-1 kafka-dump-log --cluster-metadata-decoder \ 
--files /var/lib/kafka/data/__cluster_metadata-0/00000000000000000000.log \ 
| grep REGISTER_BROKER_RECORD

And there it was, at offset 12: my broker’s own registration, listing the two advertised addresses I had configured in Docker Compose that morning.

Sit with that for a second.

When your broker started, it did not write its identity into a config table or a registry. It appended a record. To a log. At an offset.

Kafka is built on its own abstraction. Cluster metadata is a log. Consumer positions are a topic. Both get the same durability machinery as your data, because as far as the storage layer is concerned they are your data.

That was the moment the design stopped looking arbitrary to me.

THE EMPTY SCREEN THAT TAUGHT ME SOMETHING

Next I opened Kafka UI, expecting a dashboard tour and nothing more.

Topics: zero. Not “empty except the internal ones”. Genuinely zero, with internal topics shown.

But Lesson 01 said consumer positions live in a topic called __consumer_offsets. Both statements are true, and the gap between them is the lesson.

Kafka creates its internal topics on first use, not at startup. Nothing had consumed yet, so no group had committed a position, so the topic to hold positions did not exist.

Which means you can watch it be born.

THREE COMMANDS, AND THE MODEL GOES CONCRETE

Create a topic. One partition, one copy.

docker exec kafka-1 kafka-topics \ 
--bootstrap-server localhost:9092 \ 
--create --topic lessons-demo \ 
--partitions 1 --replication-factor 1

Type three records into the console producer. Read them back with the metadata attached.

docker exec kafka-1 kafka-console-consumer \ 
--bootstrap-server localhost:9092 \--topic lessons-demo --from-beginning --max-messages 3 \
--formatter-property print.partition=true \
--formatter-property print.offset=true

There is the model, made of your own typing. One partition, offsets counting from zero, in the order you wrote them.

Now run that same command again and leave off --from-beginning. It hangs, printing nothing.

That is the most common “Kafka is broken” moment there is, and it is not a bug. A brand new consumer has no committed position, so auto.offset.reset decides where it starts, and the default is latest. It is sitting at the end of the log waiting for a record that has not been written yet.

Then look at the topic list one more time.

__consumer_offsets

lessons-demo

You never created the first one. Your console consumer did, indirectly, by joining a group and committing a position. The broker made a topic to hold the bookmark.

Empty screen in Lesson 02. Two topics in Lesson 03. Same cluster, and you caused it.

WHAT ACTUALLY CHANGED HERE

I did not learn a single new API in three lessons. I learned that one sentence, “a log remembers”, is load bearing, and I stopped taking it on faith.

The trade is worth naming plainly. Doing it by hand is slower. Nobody’s demo gets more impressive because they ran kafka-dump-log.

But in Part 2 I am going to call kafkaTemplate.send and something will go wrong, because something always does. And when it does I will know whether to suspect my serializer, my Spring config or the broker, because I have already seen what the broker does on its own with no framework in the way.

Nobody pours the foundation of a house and then decides where the bathroom goes.

HOMEWORK

Tonight, before you write any Kafka code, do exactly one thing.

Start a single broker with Docker Compose, create a topic with three partitions, and produce five records to it with no key. Then consume them back with print.partition=true.

Here is a material I am using to learn.

You will almost certainly find all five sitting on one partition, and probably not partition 0. Three were available. The producer used one.

Write down your explanation before you go looking for the answer. Getting that prediction wrong is how partitioning finally sticks.

Until next time,

Keep building.

I have been living inside RabbitMQ for a few weeks now, and I want to tell you about the single realization that finally made the entire ecosystem click for me.

Here it is: A producer never talks to a queue.

If you have used RabbitMQ before and that sentence surprises you, stay with me. It surprised me too, and I had already shipped production code with it. Let us break down why our mental models are broken, and how fixing them saves us from the worst kinds of production bugs.

The Lie We All Start With

Ask most backend developers to draw a message queue and you get the exact same picture every time:

• A box on the left called the Producer.

• A box on the right called the Consumer.

• A straight pipe between them called the Queue.

It is a clean picture. It is also completely wrong in the one place that actually matters.

There is an entire architectural layer sitting right in the middle of that pipe. Every hard RabbitMQ problem you will ever debug lives inside it: messages that vanish into thin air, consumers that never fire, or a queue that stays completely empty while your application logs insist you just successfully published a hundred payloads.

All of it comes back to the layer nobody drew.

The Real Problem: Durability Over Speed

Picture this scenario: You are building a checkout system.

Someone clicks pay. Your controller charges the card, writes the order to the database, generates a PDF receipt, sends a confirmation email, pings the analytics service, and finally returns a 200 OK response.

Total time: Four seconds. Maybe six on a bad day.

The card charge only took 300 milliseconds. Everything else was heavy, asynchronous work that the customer did not need to sit around waiting for.

So, you do the obvious thing first. You wrap the slow execution blocks in a Java thread pool and return the response early. You ship it to production.

It works beautifully, right up until the server restarts mid-receipt. That in-memory thread pool is instantly wiped. The receipt is gone, no record of it exists, there is no automatic retry, and you have no way to recover it.

That is your bottleneck. It isn’t speed; it is durability. You need a landing zone for asynchronous work that outlives the web request, outlives the thread pool, and outlives the application process itself.

That somewhere is a queue. But to use it properly, you have to understand the layer nobody drew.

The True Shape of RabbitMQ

Before writing a single line of Java code, start the broker locally. One container, two exposed ports:

docker run -d --name rabbitmq \
  -p 5672:5672 \
  -p 15672:15672 \
  rabbitmq:4-management

• 5672 is the AMQP protocol port. That is where your Spring Boot application connects.

• 15672 is the management UI. Open localhost:15672 in your browser and log in using the default credentials: guest / guest.

If you click around the tabs, you will find several exchanges already sitting there that you did not create: amq.direct, amq.fanout, amq.topic, and one with an empty name shown as (AMQP default).

Those exchanges are the layer nobody drew. Here is the real architectural pipeline:

[Producer]  -->  [Exchange]  --(Binding / Routing Key)-->  [Queue]  -->  [Consumer]

The producer publishes exclusively to an Exchange, stamped with a Routing Key. That is the entire contract. The producer has absolutely no idea which queues exist, who is listening, or if anyone is listening at all.

The Binding is the contractual link that decides where the message actually lands based on that routing key. No binding, no delivery.

The One Exception: The (AMQP default) exchange automatically routes messages to a queue whose name matches the routing key exactly, requiring no explicit binding bean. It is highly convenient, but it is also the exact reason why a lot of basic tutorials get away with never explaining exchanges at all.

The Minimal Spring Boot Topology

To build this cleanly in Spring Boot, we only need to declare three structural beans.

@Configuration
public class RabbitMQConfig {

    public static final String QUEUE       = "hello.queue";
    public static final String EXCHANGE    = "hello.exchange";
    public static final String ROUTING_KEY = "hello.routing.key";

    @Bean
    public Queue queue() {
        // true = durable (survives broker restarts)
        return new Queue(QUEUE, true); 
    }

    @Bean
    public DirectExchange exchange() {
        return new DirectExchange(EXCHANGE);
    }

    @Bean
    public Binding binding(Queue queue, DirectExchange exchange) {
        return BindingBuilder
                .bind(queue)
                .to(exchange)
                .with(ROUTING_KEY);
    }
}

Notice the explicit true flag on the Queue constructor. This configures durability. Without it, your queue vanishes into memory space when Docker restarts.

Notice the string constants as well. Network configuration strings cannot be verified at compile time. A simple typo in a raw string will result in a message that silently routes to nowhere. Using constants turns a midnight production mystery into a compile-time safety check.

Best of all, you aren’t creating these resources manually in the UI. Spring Boot scans these beans and automatically declares the topology on startup if it doesn’t already exist.

The Producer

@Component
public class HelloProducer {

    private final RabbitTemplate rabbitTemplate;

    public HelloProducer(RabbitTemplate rabbitTemplate) {
        this.rabbitTemplate = rabbitTemplate;
    }

    public void send(String message) {
        System.out.println("Publishing: " + message);
        rabbitTemplate.convertAndSend(
            RabbitMQConfig.EXCHANGE, 
            RabbitMQConfig.ROUTING_KEY, 
            message
        );
    }
}

Look closely at the rabbitTemplate.convertAndSend() signature: (exchange, routingKey, payload). There is no queue argument. There never was.

The Consumer

@Component
public class HelloConsumer {

    @RabbitListener(queues = RabbitMQConfig.QUEUE)
    public void receive(String message) {
        System.out.println("Received from queue: " + message);
    }
}

If you run this application and fire a message, it processes so quickly it will never visibly sit in the UI.

Now, do the experiment that actually teaches you something: comment out the @RabbitListener annotation and restart the app. Fire five messages at the endpoint.

With no active consumer, open the Management UI and check your queue. You will see Ready: 5. Five messages sitting on disk, waiting patiently. Uncomment the listener, restart the app, and all five process instantly.

This is the ultimate core benefit: The producer and the consumer never have to be alive at the same time. The queue bridges the temporal gap, ensuring your critical data survives infrastructure instability.

Scaling Beyond Round-Robin Bottlenecks

Let us go back to our checkout scenario. The receipts are moving through the queue safely, and our HTTP response time is down to a crisp 300 milliseconds.

Then, your platform traffic suddenly triples.

A single consumer thread processes one message at a time. If generating a complex PDF receipt takes three seconds, one consumer tops out at 20 receipts per minute, regardless of how fast the underlying broker is. The queue depth will begin climbing rapidly, creating consumer lag.

The instinctive fix is to scale out horizontally by adding more concurrent workers to the same queue:

@RabbitListener(queues = RabbitMQConfig.QUEUE, concurrency = "2")
public void receive(String message) {
    // Concurrent processing logic
}

This spins up two listener threads within your JVM. They will successfully compete for messages, and each message will still be delivered to exactly one thread.

However, out of the box, this doesn’t scale perfectly. If you send ten tasks of wildly different processing sizes, you will notice one worker finishes its share quickly and sits idle, while the second worker grinds through a massive backlog.

By default, RabbitMQ distributes messages using Round-Robin pre-allocation. It hands out messages up-front before the worker has even completed its current task. If Worker 2 gets pre-allocated four highly intensive tasks while Worker 1 gets swift ones, Worker 1 cannot step in to help clear the backlog.

The fix is a single configuration line on your container factory:

@Bean
public SimpleRabbitListenerContainerFactory rabbitListenerContainerFactory(
        ConnectionFactory connectionFactory) {
    SimpleRabbitListenerContainerFactory factory = new SimpleRabbitListenerContainerFactory();
    factory.setConnectionFactory(connectionFactory);
    
    // The magic line for fair dispatch
    factory.setPrefetchCount(1); 
    return factory;
}

Prefetch specifies how many unacknowledged messages the broker will push to a single worker. By setting this to 1, the broker stops guessing. No worker receives a new payload until it explicitly acknowledges (ack) that it has finished the previous one.

Fast workers pull work rapidly; slow workers pull work as they are able. This is Fair Dispatch, and it is the key to running highly efficient, horizontally scaled consumers.

What Actually Changed Here?

By moving away from standard synchronous execution and embracing a structured routing layer, you gain three significant architectural advantages:

1. Complete Decoupling: Your producer no longer knows, nor cares, who is consuming its events or how they are configured.

2. Resilience: Your state survives application service restarts because it lives inside a managed, durable broker.

3. Elastic Throughput: You can scale processing capacity up or down simply by adjusting consumer counts, without modifying a single line of producer code.

The cost is real: you now have to manage a broker, declare a topology, and design for a hidden layer where misconfigured routing keys can drop messages into nothingness.

But that isn’t an architectural flaw; it is simply the price of admission for building scalable distributed systems. When things go wrong, always go back to the blueprint and ask the exact same three questions: Which exchange, which routing key, which binding?

Homework

Take ten minutes tonight to break your system on purpose.

Go into your HelloProducer and change the routing key to a value that does not exist, wrong.key will do perfectly. Fire a message.

You will receive no error, no exception, and no warning logs. The Java application will report a successful operation. Yet, if you check the queue, it will remain completely empty.

Open up the Management UI, navigate to the Exchanges tab, click into hello.exchange, and look closely at the Bindings section until you can explain exactly why that message evaporated.

A successful message publication and a successful message delivery are two entirely separate infrastructure promises. Recognizing that gap right now will save you days of debugging down the road.

👉 Get the Code: spring-rabbitmq on GitHub

Until next time, go break something small on your local machine.

Keep building.

I hope the code has been kind to you. I hope your builds are green, your production is quiet, and the weekend ahead is actually a weekend. And if this week hasn't been kind, if you've been staring at something that runs but doesn't quite feel right, then pull up a chair. This one is for you.

Because today I want to talk about the quietest skill in all of engineering. The one nobody puts on a course syllabus. The one that makes certain developers look like they were simply born knowing things.

You know the type. You watch them work and the logic just appears. Their fingers barely pause. And somewhere in the back of your mind a small unkind voice whispers, “I will never think that fast.”

Here’s the truth, and I need you to really hear it: they were not born that way. That speed you’re admiring is not talent. It is judgment. And judgment, unlike talent, is something you can build on purpose, one small question at a time.

That question is: why this way?

Let me show you what I mean.

The moment we all rush past

Picture it. You’ve been handed a small feature. You write it. You run it. The tests go green. The app does the thing it was supposed to do.

And you ship it.

Nothing wrong with that, my friend. Truly. Making the code work is the whole job when you’re starting out, and every one of us lived there for a good while. But here is the thing I wish someone had told me earlier: “it works” is the lowest bar in this entire craft. Almost anything works if you push on it long enough. A tangle of loops and if-statements will make the tests pass. That tells you the code runs. It tells you nothing about whether it will survive real traffic, or the next engineer who has to read it, or you, six months from now, at midnight.

The developers who look like wizards ask one more question after the code runs. A small one. What did I give up to make it work this way, and was that the right trade?

Think of it like packing a bag for a trip. A backpack and a rolling suitcase will both carry your clothes. Neither one is “correct.” It depends entirely on whether you’re hiking a trail or gliding through an airport. Code is exactly the same. Nearly every decision you make is a trade-off, and the skill is not memorizing the one right answer. The skill is simply noticing you made a choice at all.

Let me show you how gentle this can be, with a real piece of code.

One tiny example, and the whole idea hiding inside it

Say you’re building a checkout feature. VIP customers get a discount. You’ve got a pile of orders, and a collection of VIP customer IDs. Here’s the natural first draft, the one your fingers reach for without thinking:

List<Long> vipCustomerIds = loadVipCustomerIds();

for (Order order : orders) {
    if (vipCustomerIds.contains(order.getCustomerId())) {
        applyDiscount(order);
    }
}

It works. The tests pass. The VIPs get their discount. Ship it, yes?

Wait. Just for a moment. Ask the question.

Why is vipCustomerIds a List?

Sit with that, because there’s something quietly expensive happening here. When you call contains on a List, Java has no clever trick. It walks the collection one item at a time, top to bottom, until it finds a match. If you have ten thousand VIP IDs, that’s up to ten thousand checks.

And you’re doing that for every single order.

Ten thousand orders, each triggering up to ten thousand checks. That’s a hundred million comparisons hiding behind three innocent lines. On your little test array, it feels instant. On a real checkout on a real busy day, it crawls, and you won’t understand why.

Now watch. Change one word.

Set<Long> vipCustomerIds = loadVipCustomerIds();

for (Order order : orders) {
    if (vipCustomerIds.contains(order.getCustomerId())) {
        applyDiscount(order);
    }
}

Almost nothing changed on the page. But a HashSet doesn’t walk the collection one by one. It jumps very nearly straight to the answer, so each contains check is roughly instant no matter how many VIPs you have. That hundred million comparisons quietly becomes about ten thousand.

Think of a List like finding a friend’s number by reading every name in your contacts, top to bottom, until you hit theirs. A HashSet is like flicking straight to the “M” section. Same phone book. A completely different amount of effort.

And here’s what I want you to notice, gentle reader. You didn’t learn a fancy algorithm. You didn’t need a computer science degree. You just asked why the code was using a List when all it ever does is ask “is this ID in here?”

That one small question is the entire skill.

The habit that builds the instinct

Now, you might be thinking, “that’s lovely, but I’d never have spotted it.” Not yet. That’s the whole point. It’s a habit, and you build it faster than you’d believe. You don’t even have to go reading terrifying source code to start.

You just change one small thing about how you work.

The next time you use a method and you’re not quite sure what it’s really doing, don’t just trust it and move on. In your IDE, hold Ctrl (or Cmd) and click into it. Peek. You will not understand all of it, and that is completely fine. The point is simply to stop being afraid of the inside. The people who write great code are not scared of the source, and neither should you be.

Then, whenever something feels slow or clunky, resist the urge to shrug and say “it’s just slow.” Ask why. Half the time, like our little List, the fix is a single word once you can see the cause.

And once a month or so, open something you wrote three months ago. Read it. Ask what you’d change now. If you can spot even one thing, my friend, that is your judgment growing, in real time, right in front of you.

One “why this way?” a day. That’s all. In a year you’ll have hundreds of these small lessons baked so deep you won’t remember learning them.

The lovely part: you stop starting from scratch

Here’s the reward for all that gentle questioning. After a while, you stop seeing a hundred unrelated problems and start seeing the same few shapes wearing new hats.

“I need to check if something’s in here, fast.” That’s a Set or a Map. “I need to keep things in order.” That’s a List. “I need to react when something happens.” That’s an event, a listener. You’re not memorizing anything anymore. You’re recognizing an old friend and reaching for the tool that fits.

This is the real reason strong developers pick up new languages and frameworks so quickly. They aren’t smarter than you. They already know the patterns. They’re just learning where the new tool keeps its buttons. Tools come and go every couple of years. The patterns underneath barely change in a decade, which is exactly why your effort there pays off for the rest of your career.

One quiet word on focus

None of this works if you can’t sit still long enough to practice it, so let me leave you with the gentlest version of the usual advice. You don’t need iron willpower. You just need to make distraction a little harder than focus. Put the phone in the other room, not face-down on the desk. Turn off the notifications while you code, because every ping yanks the whole problem out of your head and rebuilding it costs you real time. Close the extra tabs before “one quick video” eats your afternoon.

Protect the quiet, and the practice quietly takes care of itself.

So, your homework

Here’s the truth I’ll leave you with: the slow, deliberate question is the fast path. The developer who ships in a hurry and never asks “why this way?” is the one who ends up debugging a crawling checkout on a bad day, with no idea where the time went. You don’t have to be that person.

So tonight, pick one thing you wrote recently. Something that works. Read it, and ask, out loud if you like, “why this way? What did I trade?” Just once. Find the choice hiding in your own code.

It’ll feel a little silly at first. Do it anyway. In a couple of weeks, it stops being a question you ask and becomes the way you think. And one day someone will watch you work, and admire how fast you are, and never know it was just a thousand quiet “why this way?”s stacked on top of each other.

You weren’t born a wizard. You just asked better questions than everyone staring at their phones.

That’s it from me. Go find one trade-off. Bye!!

Learn today, Teach tomorrow. Java, DevOps, Education.

How are you holding up in this fast-paced AI era? Are you still grinding through Data Structures and Algorithms, or have you quietly shelved it, figuring an LLM can just generate all the execution blocks for you?

If you’re still in the trenches, or if you’ve been questioning the point of the grind lately, let me share something that might reframe the whole journey.

Here’s the truth: this framework goes far beyond DSA. It isn’t a checklist for gaming a technical interview loop. It’s a repeatable, disciplined system of architectural thinking, the exact process that separates engineers who mindlessly type out syntax from the real problem-solvers who design high-performance systems under pressure.

And it all starts in a place you might not expect.

The biggest mistake I see engineers make in a technical interview happens in the first sixty seconds.

Picture it. The interviewer finishes reading out the problem. The last word is still hanging in the air, and the candidate is already typing. Head down, fingers flying. Nested loops appear. Random variables get declared. There’s a quiet, desperate prayer humming underneath all of it: maybe if I just type fast enough, the answer will show up on its own.

It almost never does.

What usually happens instead is this. About three minutes in, they hit a wall. The logic doesn’t hold. They freeze. The panic creeps up the back of the neck. And they spend the rest of the interview staring at a screen full of code that’s going nowhere, watching the clock quietly run out the door.

Here’s the thing I wish someone had told me earlier: jumping straight into code isn’t a sign that you’re fast. It’s a sign of a process that hasn’t been built yet.

No senior backend engineer designs a system without a blueprint first. Nobody pours the foundation of a house and then decides where the bathroom goes. So why would you write code before you have a solution in your head? Speed in an interview doesn’t come from typing quickly. It comes from knowing exactly what you’re about to type before your fingers touch the keys.

So let’s build you that process.

For the next two weeks of your prep, I want you to write these ten steps down, physically and explicitly, for every single problem you touch. Yes, all of them. It’s going to feel painfully slow at first, like you’re filling out paperwork before you’re allowed to think. Do it anyway. By around week three, something quietly clicks. The steps stop being a checklist and start being instinct. And you walk into interviews calm, almost a little bored, completely unbothered.

Let’s look at the framework first. Then we’ll take a real problem and walk it through, step by step, so you can see exactly how it feels in practice.

The 10-Step Problem-Solving Framework

1. Read the problem carefully. Don’t scan it. Read every word. Then restate it out loud in your own words. If you can’t explain what’s being asked without looking back at the prompt, you don’t understand it yet.

2. Identify inputs and outputs. Define exactly what’s coming into your function and what has to leave it. What are the data types? What does success actually look like?

3. Clarify constraints and edge cases. Ask about the boundaries. How big can the input get? Can it be null, empty, or negative? Are there duplicates? These questions aren’t stalling. They signal that you think like an engineer.

4. Work through an example by hand. Pen and paper. Trace a sample input all the way to its expected output. Don’t simulate code in your head, simulate the logic. You’re looking for the pattern, not the syntax.

5. Think brute-force first. What’s the simplest, most naive thing that would work? Even if it’s embarrassingly slow, get a correct solution on the board. A slow, working answer beats a clever, broken one every time.

6. Identify the bottleneck. Now look hard at that brute-force solution. Where is it wasting effort? Is it scanning the same data over and over for no reason?

7. Think about data structures. Which structure, a HashMap, a Stack, a Queue, a Tree, is built to kill that exact bottleneck? This is usually where the real solution hides.

8. Recognize the pattern. Does this look like something you’ve met before? A sliding window? Two pointers? A modified binary search? Most problems are old friends wearing a new hat.

9. Code the solution. Now, and only now, you open the IDE or pick up the marker. You’re not inventing anything at this point. You’re translating a blueprint you already trust into clean, idiomatic code.

10. Test and optimize. Dry-run your code against the edge cases from Step 3. Walk it line by line. Then state your final time and space complexity out loud, like you own it.

That’s the whole thing. Ten steps. Notice that nine of them happen before you write a single line of code.

The Framework in Action: Cracking the Complement Search

Theory is comforting, but it doesn’t hold up under interview pressure. So let’s run a real problem through the framework and watch what happens when you trust the process instead of your fingers.

The scenario: You’re building a feature for an e-commerce checkout system. Given an array of item prices and a target wallet balance, find the indices of the two distinct items whose prices add up exactly to the target.

Let’s go.

Step 1, Read and restate

“Okay. I’m being asked to find two distinct numbers in an array that add up to a specific target. And I need to return their positions, the indices, not the numbers themselves.”

That last sentence matters. Half of the wrong answers in this problem come from returning the values instead of the indices. Restating it out loud catches that before it bites you.

Step 2, Inputs and outputs

• Inputs: an integer array of prices (int[] prices) and a target integer (int target).

• Output: an integer array holding the two indices, e.g. int[]{ i, j }.

Already we’ve made a quiet decision: the answer is a pair of positions, so a two-element array is the natural shape to return.

Step 3, Clarify constraints and edge cases

This is your moment to sound senior. Ask:

• “Is there always exactly one valid pair, or could there be none, or several?”

• “Can the same element be used twice?” (No, the two items must be distinct positions.)

• “Can prices be negative or zero?” (In a wallet, probably not, but ask anyway. It changes nothing here, but it shows you check.)

• “How large can the array get?” (This tells you whether an O(n²) answer will survive.)

For our walkthrough, let’s assume exactly one valid pair exists, and we can’t reuse the same item.

Step 4, Work through an example by hand

Grab the pen.

prices = [2, 7, 11, 15]
target = 9

Walking it manually: 2 + 7 = 9. The 2 sits at index 0, the 7 at index 1. So the answer is [0, 1].

Simple. But notice what your brain actually did. You didn’t add up every possible pair. You looked at 2 and instantly asked, “what number do I still need to reach 9?” The answer was 7. Then you went hunting for a 7.

Hold onto that. That little move is the entire solution.

Step 5, Think brute-force first

Before we get clever, let’s get correct. The most naive approach: take every number, and compare it against every other number.

It works. For every item, we check it against every item that comes after it. If a pair hits the target, we return both indices. It’s honest and it’s correct, and that’s worth a lot when you’re under pressure.

But it’s slow. Two nested loops means O(n²) time. On a small array, fine. On a checkout with a hundred thousand line items, you’ve got a problem.

Step 6, Identify the bottleneck

Look back at the brute-force loop and ask the one question that unlocks everything: what work am I repeating?

For every single number, we walk the rest of the array looking for its partner. We’re searching, over and over, for one specific value: the complement (the number we still need to hit the target). That repeated linear search is the whole cost.

Which leads to the obvious wish: what if finding the complement were instant, instead of a full scan?

Step 7, Think about data structures

When you hear “I wish lookups were instant,” your brain should answer with one word: HashMap.

A HashMap gives you near-constant-time lookups. So instead of searching the array for each complement, we can store what we’ve already seen in a map and check it in O(1).

The plan writes itself:

• As we walk the array, for each price, calculate the complement (target - price).

• Check the map: have we already seen that complement?

• If yes, we’ve found our pair, and the map already holds where we saw it.

• If no, store the current price and its index, and keep walking.

Step 8, Recognize the pattern

Pause and name it. This is the complement search pattern, sometimes called the “seen so far” HashMap trick. The moment a problem says “find two things that combine to make a target,” your instinct should reach for a map of what you’ve already passed.

Once you’ve named the pattern, you’ve seen this problem before, even if you haven’t. That’s the quiet confidence the framework is building.

Step 9, Code the solution

Only now do we touch the keyboard. And because the thinking is already done, the code almost writes itself:

One pass. For each price we ask, “have I already seen the number that completes this pair?” If we have, we’re done. If not, we remember this price and where it lives, then move on.

Notice we store the price after checking. That’s deliberate. It guarantees we never accidentally pair an item with itself.

Step 10, Test and optimize

Don’t declare victory yet. Dry-run it against our example:

prices = [2, 7, 11, 15], target = 9

i = 0  ->  price = 2, complement = 7. Map empty. Store {2 -> 0}.
i = 1  ->  price = 7, complement = 2. Map has 2! Return [0, 1].

It lands exactly where the hand-trace did. Now run the edge cases you asked about in Step 3. What if no pair exists? The exception fires. Good.

Then say the complexities out loud, because the interviewer is waiting for them:

• Time: O(n). We touch each element once.

• Space: O(n). In the worst case, the map holds almost every element.

We traded a little memory for a huge speed win, turning an O(n²) crawl into an O(n) walk. That trade-off, stated clearly, is exactly what separates a candidate who got the answer from one who understands the answer.

What actually changed here

Look back at how that went. We spent eight steps thinking and just one step typing, and the code came out clean, correct, and fast on the first try. No panic. No wall. No clock anxiety.

That’s the secret nobody tells you: the slow, deliberate process is the fast one. The candidates who freeze are the ones who skipped straight to Step 9 and tried to reason and type at the same time. You don’t have to be one of them.

So here’s your homework. Pick a problem tonight. Don’t open your editor. Get a pen, write the ten steps down the side of a page, and fill each one in by hand. It’ll feel slow. It’ll feel like overkill.

Do it anyway. In two weeks, this becomes the way you think. And the next time an interviewer finishes reading a problem, you won’t reach for the keyboard.

You’ll reach for the pen, and smile.

That’s it from me. Bye!!

I have been learning AWS. Yes, I have used Azure before and deployed a couple of projects there, but it was time to try something new. On Azure, I got free credits since I was an MLSA. That time ended, just joking, I am on the free tier on AWS too🥲.

I guess it was the right time for me to try exploring something new. Most job descriptions mention AWS and specific services for AWS. My goal is to be conversant with the cloud and DevOps, so AWS is part and parcel of the journey.

So, here are the services I have learnt so far. First is understanding what AWS is all about. Then comes the various services it offers and how they are significant for your startup company, etc.

But before that, let’s answer a simple question.

What Actually is AWS?

Amazon Web Services (AWS) is a massive cloud computing platform provided by Amazon. Instead of buying physical hardware and keeping a noisy server rack in your office, AWS lets you rent computing power, storage, and databases over the internet on a pay as you go basis.

Whether you are hosting a simple website, training machine learning models, or building a complex microservices architecture, AWS gives you the exact tools you need in data centers located all around the world.

So let’s start here. AWS has over 200 services at least that’s what Google says, or rather I should have asked Amazon Q. Amazon Q is their AI integrated assistant that helps you figure things out how to use various services, could give you commands etc.

And yes, AWS is full of abbreviations. Even AWS itself is an abbreviation.

At first, it feels overwhelming. Then slowly, it starts feeling like vocabulary.

The Cloud Landscape: Who Uses What?

To understand why AWS is such a big deal, it helps to see where it stands compared to the other major cloud providers like Azure and Google Cloud Platform (GCP). While there are smaller players for simpler hosting, the global tech industry is largely dominated by the Big Three.

• AWS (Amazon Web Services)

  AWS is the undisputed pioneer and market leader, currently controlling roughly 28 to 30 percent of the global cloud market. It is the default choice for fast scaling startups and massive tech enterprises. Companies like Netflix, Airbnb, and Slack rely on AWS to power their entire global infrastructure.

• Azure (Microsoft Azure)

  Holding around 21 to 25 percent of the market, Azure is incredibly popular with established corporations that already use Microsoft software. Because of existing enterprise agreements, giants like Walmart, FedEx, and Starbucks run massive portions of their operations on Azure.

• GCP (Google Cloud Platform)

  Sitting at around 11 to 14 percent market share, Google Cloud is heavily favored for its advanced data analytics, artificial intelligence capabilities, and container management tools. Tech heavy companies like Spotify, Snap, and HSBC leverage GCP to process massive amounts of user data.

By focusing on AWS right now, you are positioning yourself directly where the highest volume of startup and DevOps jobs live, making it a crucial tool in your engineering toolkit.

Learning AWS does not mean ignoring the others.

It just means starting where most job opportunities currently sit.

One Thing That Changed Everything

Before diving into the servers and databases, I quickly learned that none of it matters if your environment isn’t secure. That brings us to IAM.

IAM (Identity and Access Management)

IAM is the foundation of security in AWS. It answers a simple question: Who is allowed to do what? Without IAM, everything else would be chaos.

IAM introduces a few core ideas:

• Users: Individual identities for people or applications.

• Groups: Collections of users with shared permissions.

• Policies: Rules written in JSON that define what actions are allowed or denied.

• Roles: Temporary identities that AWS services or users can assume without storing long-term credentials. For example, an EC2 instance can assume a role that allows it to access an S3 bucket without hardcoding access keys into the application.

One principle stood out immediately: The Principle of Least Privilege. Only give the permissions that are absolutely necessary. Nothing more.

IAM is not flashy. You do not “see” it working. But it quietly controls everything. In many ways, IAM is the gatekeeper of AWS.

AWS Free Tier

One thing I appreciate as a learner is the AWS Free Tier.

It allows you to experiment with services like EC2, S3, and RDS without immediate cost.

Key word: carefully.

Because nothing teaches discipline faster than a surprise billing alert at 3 AM.

Here are the core features I have covered so far:

Compute and Storage

EC2 (Elastic Compute Cloud)

The famous EC2 you have definitely heard about this, if not no worries I gatchu. So basically EC2 is a VM that Amazon gives you. You rent a server, pick an operating system like Ubuntu or Windows, choose your RAM and CPU size, and use it to host things like a SpringBoot or Node.js backend or an Nginx web server.

If AWS is a city, EC2 is the apartment where your application lives.

EBS (Elastic Block Store)

This is the hard drive you attach to your EC2 virtual machine. If you need to store files locally on your server, install an operating system, or host local databases, the data goes here.

You can detach an EBS volume from one server and plug it into another, and you can take point in time snapshot backups to keep your data safe.

Think of it as the hard drive for your cloud machine.

S3 (Simple Storage Service)

Unlike EBS, S3 is an infinite bucket specifically for storing objects and files. You use S3 to store user profile pictures, video uploads, application backups, or even to host frontend React website builds. You only pay for the exact gigabytes you upload.

If EC2 is a house, S3 is the warehouse that never runs out of space.

Management and Security

AWS CLI (Command Line Interface)

Instead of clicking through the AWS website, you type commands directly in your terminal. For example, typing aws s3 cp uploads a file from your laptop straight to your cloud storage. It is essential for writing scripts to automate your daily deployments.

SSM (Systems Manager)

The Session Manager feature inside SSM lets you securely log into your EC2 instances directly from your browser or terminal. You do not need to open port 22 or manage complicated SSH keys. It also logs every single command you type, which makes it incredibly secure for team environments.

Networking and Scaling

ELB (Elastic Load Balancing)

If your app suddenly gets 10,000 visitors, a single server will crash. ELB acts as a traffic controller. It receives all the incoming web traffic and splits it equally across multiple EC2 servers so no single machine gets overloaded.

Auto Scaling

This works directly with your load balancer. If your application starts getting heavy traffic, Auto Scaling automatically launches new EC2 instances to handle the load. When traffic drops at night, it deletes the extra servers automatically so you stop paying for idle machines.

Monitoring and Databases

CloudWatch

This is your central monitoring dashboard. It tracks exact hardware metrics like CPU utilization or memory usage and collects your application error logs in real time. You can set alarms to send you an email alert if a server’s CPU stays above 80 percent for more than five minutes.

RDS (Relational Database Service)

Instead of manually installing PostgreSQL or MySQL on an EC2 server, AWS sets it up for you. RDS provides a clean database endpoint for your app to connect to. It automatically handles software patching, performs daily automated backups, and can copy your database to another location for disaster recovery.

You focus on writing queries and building features. AWS handles the operational burden.

You can read more about the services here

How It All Comes Together

At first, AWS feels like a collection of random services. Then it starts to form a system.

Imagine building a simple photo-sharing application:

1. A user sends a request, which hits an Elastic Load Balancer.

2. The load balancer distributes traffic across multiple EC2 instances running your application.

3. Those EC2 instances store structured data in RDS and upload images to S3.

4. Each EC2 instance uses EBS for system storage.

5. Auto Scaling ensures the number of EC2 instances adjusts based on traffic.

6. CloudWatch monitors everything and alerts you when something goes wrong.

7. SSM allows secure management of the infrastructure.

8. AWS CLI helps automate deployments and operations.

9. IAM ensures only the right people and services can access the right resources.

Slowly, the system stops feeling like abbreviations and starts feeling like architecture.

See You in the Next One

These are just some of the things I have learned so far, and honestly, I feel like I have barely scratched the surface. There is still IAM in deeper detail, VPCs, Route 53, Lambda, ECS, EKS, CloudFormation, Terraform, Docker deployments, CI/CD pipelines, and many more layers waiting ahead.

What I enjoy most is not memorizing services. It is seeing how they come together to build systems that can scale from a small idea to something used by millions.

The cloud can feel overwhelming at first. But one service at a time, the picture becomes clearer.

I hope you enjoyed the read. If you’re also starting your AWS journey, we are probably learning together.

See you in the next one.

We have spent a lot of time recently discussing career roadmaps, language fundamentals, and the cutting edge of Spring AI. But today, I want to take a deliberate step back to fix a foundational pain point that quietly breaks the confidence of intermediate developers alike.

Most developers learn OOP through pure performance art. They memorize definitions for a technical interview, pass the test, and immediately return to writing procedural code wrapped inside Java classes. They can recite definitions for encapsulation or polymorphism from memory, but the moment they sit down to design a multi-tenant billing service or a modular fleet telemetry engine, their architecture collapses into a tangled web of tightly coupled classes and side effects.

OOP is not a set of rules designed to make your life difficult. It is simply a way of organizing code. To understand why it became the dominant paradigm for enterprise software, we first need to understand the structural problems it was designed to solve.

The Evolution of Paradigms: Before OOP

Computers do not care about paradigms. At the hardware level, everything is Von Neumann architecture: instructions are fetched from memory and executed sequentially, manipulating values in registers and RAM. Paradigms exist purely for human sanity, allowing us to manage complexity as codebases grow.

Before OOP became the industry standard, two major paradigms shaped how we wrote software.

1. The Imperative / Procedural Paradigm

In early programming languages like Fortran or C, software was structured as a sequence of linear instructions grouped into procedures (functions). Data sat in one place, and functions sat in another, reaching out to mutate that data directly.

Let us look at a simple procedural implementation in C for managing a retail order discount:

The Breakdown: The data inside struct Order is completely naked. Any function anywhere in the entire codebase can modify totalAmount or customerType to an invalid state without the structure knowing about it. As systems grow to millions of lines of code, tracking down which function corrupted your data state becomes an absolute nightmare.

2. The Functional Paradigm

Functional programming takes the opposite approach. Instead of mutating global state, it treats computation as the evaluation of mathematical functions, completely avoiding state changes and mutable data.

Here is how you would process a list of transactions using a pure functional style in Haskell:

The Breakdown: Functional programming is incredibly elegant for data transformation pipelines and concurrent environments because code without mutable state cannot have side effects. However, modeling highly stateful, interactive real-world systems (like a complex corporate banking application or an aircraft simulator) purely through immutable mathematical functions can introduce significant mental overhead for large, distributed engineering teams.

Enter the Object-Oriented Paradigm

OOP emerged to merge data and behavior into single, cohesive structures called Objects. Instead of functions acting on passive data, objects hold their own private state and expose public behaviors.

According to the Java Language Specification (JLS) §4.3.1, an object is a dynamically created class instance or an array. Reference values in Java are references to these objects. When you invoke a method, you are not simply executing a global function; you are passing a message to a specific instance, asking it to execute an operation on its private state.

The Blueprint and the Instance: Classes and Objects

The classic textbook analogy tells you that a class is a blueprint and an object is the house built from it. That is a fine starting point, but in software engineering, a class is a user-defined data type that binds state and behavior together into a single cohesive unit.

When you write a class, you are telling the Java Virtual Machine exactly how much memory to allocate and what operations are legally permitted on that memory structure.

Consider a system tracking vehicle telemetry data. We do not just want a loose collection of floating variables drifting through our application context. We want a structured type.

The class TelemetryPing defines the structure. The object is the actual allocated segment of heap memory containing a specific vehicle id and coordinate set at a distinct moment in time.

The Four Pillars Under the Hood

1. Encapsulation: Guarding the State

Encapsulation is frequently explained in tutorials as making fields private and generating getters and setters. That definition is wrong. If you make an internal variable private but blindly expose a public setter for it, you have completely destroyed encapsulation.

According to the JLS, access control modifiers (private, protected, public) are enforced at compile time and verified by the JVM at class-loading time to ensure structural integrity. Real encapsulation means hiding the internal state mechanics of an object and exposing only explicit, validated behaviors.

Consider a production-grade banking ledger implementation:

2. Abstraction: Defining Boundaries

Abstraction means separating what an operation does from how it is implemented. In Java, this boundary is enforced via interfaces and abstract classes.

Per JLS §9.1, an interface is a reference type whose members are constants and abstract methods. It specifies a contract that implementing classes must fulfill.

Any component in your system can depend directly on PaymentGateway. Whether the actual underlying engine connects via REST to Stripe or uses gRPC to communicate with an internal banking ledger is completely hidden from the caller. The complexity is safely contained behind the interface boundary.

3. Inheritance: Structural Relationships

Inheritance allows a class to derive state and behavior from an existing class. In Java, this is achieved using the extends keyword, which sets up a strict parent-child relationship (JLS §8.1.4).

Java uses single inheritance for classes to avoid the famous “Diamond Problem” found in languages like C++, where a subclass inherits conflicting implementations from multiple parent classes.

We extend this base structure to provide concrete vendor-specific logic:

4. Polymorphism: Dynamic Method Dispatch

Polymorphism allows us to treat different objects as instances of a common supertype while executing their own specific overrides at runtime.

Under the hood, Java achieves this via Dynamic Method Dispatch (JLS §15.12.4.3). When you call a method on an interface or superclass reference, the compiler cannot know the exact code to execute. Instead, the JVM looks at the actual object instance on the heap at runtime, references its internal virtual method table (vtable), and calls the specific subclass implementation.

This completely eliminates messy, unmaintainable if-else type checks:

Why Spring Boot Depends Heavily on These Pillars

If you rush straight into learning Spring Boot without anchoring yourself in these runtime mechanics, the framework will feel like pure, incomprehensible magic.

When you configure a service bean and use dependency injection via @Autowired or constructor injection, you are leveraging Abstraction and Polymorphism. Spring requests the interface type, inspects its internal ApplicationContext container to locate the concrete implementation bean, and hooks it up seamlessly.

When you apply the @Transactional annotation to a service method, Spring uses Java dynamic proxies or CGLIB byte-code manipulation. It constructs a dynamic subclass or wrapper around your component at runtime, leveraging Inheritance and Polymorphism to intercept your method call. It opens a database transaction, executes your exact code, and safely commits or rolls back the changes based on your execution outcome.

Frameworks do not replace object-oriented design; they amplify it.

Moving Beyond Shallow Practice

The reason most developers get stuck in a loop of shallow understanding is that they avoid building real, stateful applications. You cannot master object design by simply reading slides or looking at basic code samples.

To truly make this click, challenge yourself to build a self-contained system without reaching for an external database or a framework first. Write a clean, terminal-based library catalog or a vehicle fleet tracking simulation using nothing but pure Java core classes.

Force yourself to design the boundaries carefully:

• Secure your class states against negative inputs or invalid mutations.

• Hide your storage mechanics behind clean interfaces.

• Use dynamic polymorphism to handle variations in system actions instead of nesting complex switch blocks.

Once you can orchestrate a clean architecture using standard, plain old Java objects, stepping up to microservices, enterprise design patterns, and enterprise frameworks will feel like a natural extension of your skills instead of an uphill battle.

Signing off,
your_javaguy

I know… I disappeared for a little while.

Not because I forgot about all of you, but because the past few weeks have been wonderfully chaotic.

I was helping organize JavaConnectKE, and I am still smiling thinking about how successful it turned out to be.

To everyone who attended, supported, spoke, volunteered, shared posts, asked questions, or simply believed in what we were trying to build, thank you.

What started as planning calls, logistics spreadsheets, venue preparations, and moments of “will this actually work?” eventually became a room full of developers, learners, conversations, laughter, and shared passion for Java and engineering.

And honestly?

Seeing the community come together like that reminded me why I love tech spaces so much.
Back in 2024, I made this tweet after watching talks from Venkat Subramaniam on X

At the time, it felt like one of those internet moments you smile at and move on from.

Fast forward to JavaConnectKE… and somehow, that moment became real.

Wearing Multiple Hats

This event was special for me because I got to experience it from multiple angles.

I was not only involved in organizing it, but I also had the opportunity to:

• MC the event

• Speak about Spring AI with my friend

• Moderate the panel discussion

And somehow survive all of that without my voice filing a resignation letter.

Being the MC was both exciting and slightly terrifying. One moment you are confidently introducing speakers, the next you are hoping your brain remembers the next schedule item correctly.

Thankfully, the energy in the room made everything easier.

Speaking About Spring AI

One of my favorite moments from the event was speaking about Spring AI together with my good friend, Newton Wamiti.

We did a deep dive into:

• Retrieval-Augmented Generation (RAG)

• MCPs

• Tool Calling

• Chat Memory

• Agentic Workflows with Embabel

AI is rapidly becoming part of modern software engineering workflows, and seeing Java confidently enter that space is genuinely exciting.

Now… let me confess something.

At some point during the demo, things decided to become “interesting.”

And by interesting, I mean:
the demo briefly refused to cooperate.

A timeless engineering tradition.

Nothing humbles a developer faster than a live demo deciding to explore free will in front of an audience.

But strangely enough, moments like that are part of what makes live tech events memorable. Engineering is not perfection. It is adapting, debugging under pressure, and continuing anyway.

Thankfully, we recovered well, and the session ended strongly.

Learning from Incredible Speakers

One of the biggest highlights of JavaConnect was hearing from incredible speakers who brought both depth and practical experience to the stage.

Venkat Subramaniam

Venkat spoke about:

• Modern Concurrency in Java

• Records and Pattern Matching

• Functional Programming Done Right

Watching him break down complex ideas into understandable concepts was honestly inspiring. Some people teach Java. Others make Java feel alive.

Ivar Grimstad

Ivar covered:

• Jakarta EE

• The evolving enterprise Java ecosystem

His session gave a strong perspective on where enterprise Java continues to grow and adapt in modern software engineering.

Elvis Parsaloi Nakuoh

Elvis spoke about:

• Spring Modulith

A topic that sparked many interesting conversations around modular application design and maintainable architectures.

Moderating the Panel Discussion

I also had the opportunity to moderate the panel discussion, and this may have been one of my favorite parts of the entire event.

The panel featured:

• Venkat Subramaniam

• Nelly Nakhero

• Ivar Grimstad

• George Okumu

• Patrick Musembi

• Baraka Mbugua

Together, we explored conversations around:

• The future of Java

• Artificial Intelligence

• Backend engineering

• Developer growth

What I loved most was how honest the discussion felt.

Not polished corporate answers.

Real experiences.
Real lessons.
Real opinions.

And I think those are the conversations developers connect with the most.

What This Experience Reminded Me

This event reminded me of something important.

Communities matter.

Technology grows faster when people grow together.

Sometimes we focus so much on code, frameworks, deployments, and certifications that we forget how powerful human connection is in this field.

Conversations matter.

Mentorship matters.

Shared experiences matter.

And spaces like JavaConnect create room for all of that.

One More Important Thank You

Behind every successful community event is a group of people solving problems quietly in the background long before attendees ever walk into the venue.

I genuinely want to appreciate the incredible organizing team that helped make JavaConnectKE possible:

Phenny Mwaisaka, Lenny Dennis, Rose Wambui, Stephen Omondi, Newton Wamiti, Silas Abel, Kennedy Muchiri, Samuel Owino, Dalton Lemaiyan, and Cosmas Gikunju.

From coordination and logistics to communication, planning, troubleshooting, and making sure everything kept moving, this event was truly a collaborative effort.

Some Extra moments from the event capturing me ofcourse:

What Happens Next?

Now that the dust has settled a little, I am back to writing consistently again.

We still have many bricks to lay together:

🧱 Java fundamentals
🧱 Spring Boot
🧱 DevOps adventures
🧱 AI explorations
🧱 Engineering lessons
🧱 The occasional “this bug almost finished me” stories

And yes, more stories from the road as well.

Thank you once again for being here.

Truly.

Until next time,

Keep building. 🧱

I have not forsaken you, I remember about all of you. Still contemplating on the kind of content that would best fit all of you.

If you are reading this, thank you for making me reach 100+ subs.

In the previous write-up I did a guide on the topics I would learn when starting out in Java before touching a framework. I missed out on Java Database Connectivity, which is a good topic too.

That’s not why we are here today, but I thought you should know that.

What will we be covering today? The basics of Java you need, the so-called verbose syntax (although Java 25 is making things easy), variables (how we store data), the supported data types, and possible methods. Kind of a quick crash course to get you started.

Grab a coffee. Or tea. Or water. Whatever keeps you awake. Let’s get into it.

The “Verbose” Reputation (And Why Java 25 Is Changing That)

If you’ve spent any time around developers, you’ve probably heard someone say, “Java is verbose.” And honestly, they weren’t lying. For years, just printing “Hello World” required you to write something like this:

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello World");
    }
}

That’s a lot of ceremony for one line of actual work. A beginner looks at this and thinks, “Why do I need a class? What is public static void main? What’s String[] args?” And those are fair questions. You came to print a message, not to decode ancient runes.

Here’s the good news. Java 25 gives us something beautiful. With the new simplified source files, you can now write this:

void main() {
    IO.println("Hello World");
}

That’s it. No class declaration. No public static. No String[] args that you don’t understand yet. Just the thing you actually wanted to do. The Java team finally heard us, and they’re letting beginners focus on learning the language instead of wrestling with boilerplate.

You can still write the old-style code, and you’ll see it everywhere, so don’t worry, you’ll learn both. But while you’re starting out, Java 25 lets you breathe a little.

Variables: How We Store Data

Think of a variable as a labeled box. You put something in the box, you give the box a name, and later when you need that thing, you just call the box by its name. That’s literally it. Don’t let anyone over-complicate it for you.

In Java, when you create a variable, you usually tell Java three things: what type of thing it is, what you want to call it, and what value it should hold.

void main() {
    int age = 25;
    String name = "Ian";
    double salary = 1500.50;

    IO.println("My name is " + name);
    IO.println("I am " + age + " years old");
    IO.println("I earn " + salary);
}

Read that slowly. int age = 25 means “create a box of type integer, call it age, and put the number 25 inside.” Simple. The word on the left is the type (what kind of data), the word in the middle is the name (what you’ll call it), and the value on the right is what goes in the box.

Now here’s something useful. Java is smart. Since Java 10, if Java can figure out the type on its own, you can just write var instead:

void main() {
    var age = 25;           // Java knows this is an int
    var name = "Ian";       // Java knows this is a String
    var salary = 1500.50;   // Java knows this is a double

    IO.println(name + " is " + age);
}

var is not a new type. It’s just you saying, “Java, you figure it out.” And Java does. Use it when the type is obvious from the value. Don’t use it when it makes your code harder to read. That’s the rule.

The Data Types You Actually Need to Know

Java has two families of data types. Primitives and Non-primitive(Reference or Objects). Don’t panic, I’ll explain.

Primitives are the simple, raw building blocks. They hold a single value and nothing else. No fancy features. They’re fast and lightweight. Here are the ones you’ll actually use:

• int holds whole numbers like 1, 42, or -100. It’s your go-to for counting things, indexing, ages, quantities, anything that doesn’t need decimals.

• long is just like int but bigger. Use it when your numbers get really large, like storing a timestamp or counting grains of sand on a beach. You mark them with an L at the end: long bigNumber = 9000000000L.

• double holds decimal numbers like 3.14 or 99.99. Use it for money, measurements, percentages, anything with a fractional part.

• boolean holds only two values: true or false. Use it for yes/no questions your program needs to answer. “Is the user logged in?” “Is the cart empty?” boolean handles that.

• char holds a single character like ‘a’ or ‘9’ or ‘?’. Notice the single quotes. Single quotes for single characters, always.

Then we have objects, and the one you’ll meet on day one is String. A String holds text, like “Hello” or “Nairobi” or “I love Java”. Strings use double quotes, not single. Mix these up and the compiler will let you know in a very unfriendly way.

void main() {
    int count = 10;
    long population = 54000000L;
    double price = 199.99;
    boolean isJavaFun = true;
    char grade = 'A';
    String message = "Java is actually pretty cool";

    IO.println(message);
    IO.println("Is Java fun? " + isJavaFun);
    IO.println("Your grade is " + grade);
}

One thing I want you to notice. We used + to join strings together. In Java, when you use + with a String, it glues things together instead of adding them. This is called concatenation. It’s a small word for a simple idea: stick these things together to make one big String.

Putting It All Together

Let’s write one tiny program that uses everything we’ve covered. Nothing fancy, just a little profile of a person using the types we just learned.

void main() {
    String firstName = "Dearest";
    String lastName = "Reader";
    String fullName = firstName + lastName; // concatenation
    int age = 25;
    double height = 1.78;
    boolean lovesJava = true;
    char initial = 'I';

    IO.println("FirstName: " + firstName);
    IO.println("LastName: " + lastName);
    IO.println("Full name: " + fullName);
    IO.println("Initial: " + initial);
    IO.println("Age: " + age);
    IO.println("Height: " + height + " meters");
    IO.println("Loves Java? " + lovesJava);
}

Run this in your head before you run it on a computer. That’s a habit I want you to build. Read the code, predict what will happen, then run it and see if you were right. This is how you learn to think like a programmer.

Every line is a variable you now understand. Every output uses concatenation you now understand. No mystery, no magic, no hand-waving. That’s genuinely the foundation.

Don’t rush. Write this yourself. Change the values. Add a new variable. Break it on purpose by putting a String value into an int, or by using single quotes where you should use double quotes. When you break something, read the error message carefully. The compiler is not your enemy, it’s your first teacher. It tells you exactly what’s wrong, you just have to learn its language.

A Free Companion Guide for You

Reading is one thing. Actually writing code is where the learning happens. So I put together a repository called Java for Everyone that goes hand in hand with articles like this one. It has organized notes on each topic, small exercises to practice what you just read, and full mini-projects you can build to tie everything together. You can use it as your self-study workbook alongside these write-ups.

You’ll find it here: Java For Everyone

Go give it a star while you’re there. It genuinely helps more people discover the repo, and it gives me a little nudge to keep adding to it. If you spot something missing, open an issue. If you want to contribute an exercise, even better. This is meant to be a community resource, not a one-man show.

What’s Next?

You now know enough Java to store and display data. That sounds small, but honestly, almost every program you’ll ever write is built on top of exactly these ideas.

From here, the next thing you want to learn is how to make your program make decisions. That’s conditionals: if this is true, do that, otherwise do something else. After that, loops, which let you do things over and over without copy-pasting. Then we’ll talk about methods, which are how you package code so you can reuse it, and that’s where your programs will start to feel like real programs.

And remember my teaching philosophy: Learn Today, Teach Tomorrow. Once something clicks for you, try explaining it to someone else, even if that someone else is your rubber duck. If you can teach it, you understand it.

Until next time. Keep coding.

— Ian, your_javaguy.

Was wondering what I should write today.

Should I jump directly into Spring Boot and list resources?

Or should I take a step back and share my thoughts on the kind of topics one needs to be comfortable with in Java before touching frameworks like Spring, Jakarta or Quarkus ?

We will not be having wars on which is better or not. Whichever makes you feel better and gets the work done is what you opt for.

I use Spring Boot.

Now that that is said and done, how would I learn Java if starting out? What topics would I ensure I have at my fingertips before touching a framework?

The most fundamental thing every developer needs is the basics; being comfortable with syntax, variables, and data types.

These are things one should always be comfortable with in any language.

A joke is normally made that those who move from language to language are syntax masters. And there is some truth in that. Syntax is the doorway but it is not the house.

First Brick — Syntax, Variables, and Data Types

Before anything fancy, you must be comfortable writing Java without fear.

Not memorizing.
Not guessing.
Comfortable.

This includes:

• Variables

• Primitive data types

• Reference data types

• Basic operators

• Type conversions

These are the letters of the alphabet in the language of Java. If these feel shaky, everything else will feel heavier than it should.

Rome was not built in a single day.

It took brick after brick. But what really mattered was the foundation beneath those bricks.

Would it really hold the entire building?

The same concept applies in your software engineering journey.

How strong are your basics?

Because complex concepts do not appear from nowhere. They are built on top of fundamental concepts.

Second Brick — Control Flow

Once syntax feels natural, the next question becomes:

How does your program decide what to do?

That is where control flow comes in.

Control flow is what allows us to control how our programs are executed.

Are there conditions to be met? That gives birth to conditional statements.

Here we have:

• if statements

• if-else statements

• else if statements

They help us move around various conditions that determine which pieces of code should run.

But here is something worth remembering.

When you ever find yourself having many if-else-if statements, it does not mean you are wrong; it may simply mean there is a tool you are not using yet.

That tool is:

Switch expressions.

They help you write cleaner code and avoid clogged code, if I may call it that.

Third Brick — Loops (Making Code Repeat Without Complaining)

Next up, we have the tools that help us execute code multiple times.

We can control repetition.

These tools are called loops, or as some would call them, iterators.

Here we have:

• for loops — executes a known number of times

• while loops — runs while a condition remains true

• do-while loops — executes at least once

• Enhanced for loop — useful when you do not need to mutate data while looping

Loops are like the engine of repetition. Without them, you would write the same line of code again and again — and trust me, keyboards deserve mercy too.

Fourth Brick — Object-Oriented Programming (The Heart of Java)

Now we arrive at the place where Java truly begins to feel like Java.

Object-Oriented Programming — OOP.

If Java were a city, OOP would be its roads, buildings, and traffic systems.

This is where many developers either grow strong… or remain stuck.

OOP is not optional.

It is foundational.

Here are the concepts you must understand deeply:

• Classes

• Objects

• Constructors

• Encapsulation

• Inheritance

• Polymorphism

• Abstraction

Let me stress this clearly:

Spend time here. A lot of time here.

Do not rush past OOP.

Frameworks like Spring Boot are built heavily on OOP principles. If OOP feels confusing, frameworks will feel magical and magic is dangerous when you do not understand the trick.

You do not want magic.

You want mastery.

Fifth Brick — Collections Framework

Once you understand objects, you need ways to manage groups of data.

That is where collections come in.

You should understand:

• Lists

• Sets

• Maps

• Iteration through collections

• Basic sorting

Collections teach you how to handle real-world data — not just single values.

Because real applications rarely deal with one item. They deal with many.

Sixth Brick — Exception Handling

Programs fail.

Not sometimes. Often.

What matters is how gracefully they fail.

Exception handling teaches you to prepare for failure instead of being surprised by it.

Focus on:

• try

• catch

• finally

• throw vs throws

• Custom exceptions

Errors are not enemies.

They are teachers loud — ones.

Seventh Brick — File Handling and Basic I/O

At some point, your program must interact with the outside world.

Files are one of the simplest ways to start.

You should understand:

• Reading files

• Writing files

• Basic input/output operations

This is where programs stop being academic and start becoming useful.

So… When Can You Start Spring Boot?

Now the question everyone quietly waits for.

When is it safe to start Spring Boot?

You can start Spring Boot after you are comfortable with:

• Core syntax

• Control flow

• Loops

• Object-Oriented Programming

• Collections

• Exception handling

Once these feel natural — not perfect, but comfortable — you are ready.

That does not mean you ignore other topics.

Far from it.

Topics like:

• Multithreading

• Concurrency

• Streams

• Functional programming

These can come later.

You can always return to them.

Learning is not a race.

It is a layered process.

Additional Topics Worth Knowing Before Spring Boot

There are a few topics that are not always listed early — but make a noticeable difference once you step into real-world applications.

You do not need to master them completely before Spring Boot, but being familiar with them will make your journey smoother.

Eighth Brick — Streams and Functional Programming Basics

Modern Java relies heavily on functional-style programming.

You should be familiar with:

• Lambda expressions

• Method references

• Basic Stream operations:

  • filter()

  • map()

  • forEach()

  • collect()

Streams appear frequently in real-world applications.

Not knowing them does not stop you from starting — but knowing them removes friction.

Think of Streams as learning how to use power tools instead of hand tools.

Both work.

One just saves time.

Ninth Brick — Interfaces and Abstract Classes (Deep Understanding)

While Interfaces and Abstract Classes are part of OOP, they deserve special attention.

Spring Boot relies heavily on:

• Interfaces

• Dependency injection

• Contracts between components

You should understand:

• When to use interfaces

• Difference between interfaces and abstract classes

• How classes implement interfaces

Many Spring components are wired using interfaces.

Understanding this early prevents confusion later.

Tenth Brick — Basic Debugging Skills

Writing code is one skill.

Fixing code is another.

You should be comfortable with:

• Reading stack traces

• Using breakpoints

• Stepping through code

• Understanding error messages

Debugging is often the difference between frustration and confidence.

Eleventh Brick — Basic Build Tools (Maven or Gradle)

Spring Boot projects rely on build tools.

Focus on:

• What Maven or Gradle does

• Project structure

• Dependencies

• Running builds

• Packaging applications

Without this knowledge, Spring Boot may feel confusing before you even begin.

How Long Does It Take Before Starting Spring Boot?

This is one of the most common questions.

Not everyone learns at the same pace.

But having rough expectations helps set realistic goals.

Approximate Timeline Before Spring Boot

(Assuming 1–2 hours daily)

• Syntax, Variables, Data Types → 1–2 weeks

• Control Flow → 1 week

• Loops → 1 week

• Object-Oriented Programming → 3–5 weeks

• Collections → 2–3 weeks

• Exception Handling → 1 week

• File Handling → 1 week

• Streams Basics → 2 weeks

• Interfaces & Abstraction → 2 weeks

• Maven or Gradle Basics → 1 week

• Debugging Skills → Ongoing

Total Estimated Time Before Spring Boot:
➡️ 10–16 weeks (about 2.5 to 4 months)

Not perfection.

Comfort.

That is the real target.

For Those Who Want to Truly Master Java

Some developers do not just want readiness.

They want mastery.

That journey takes longer — and rightly so.

After starting Spring Boot, you can continue exploring:

• Multithreading

• Concurrency

• Synchronization

• Java Memory Model

• Advanced Streams

• Generics

• Reflection

• Annotations

• Design Patterns

• Networking

• Performance tuning

• JVM internals

• Garbage Collection

• Reactive programming

These topics move you from Java user to Java craftsman.

Not required to begin.

But powerful to pursue.

Final Thoughts — Build the Foundation First

Frameworks like Spring Boot are powerful.

But power without understanding becomes dependency.

Understanding without tools becomes limitation.

You need both.

But in the right order.

Build the foundation.

Lay the bricks.

Strengthen the base.

Because complex systems are not born from magic.

They are built — patiently — on fundamentals.

And when your foundation is strong, frameworks stop feeling mysterious… and start feeling like tools.

Tools you control.

Not tools that control you.

Learn Today. Teach Tomorrow.

Dearest gentle reader,
I am seated on my couch, legs crossed, thinking about what to write for my new subscribers.

I know the audience here is mixed. Some are beginners who are just starting their journey. Others have been in the Java or back-end space for a while and are trying to sharpen their skills.

I have a soft spot for beginners.

Not because it sounds nice to say, but because I struggled as one. I did not always have the right direction. At times I got confused, jumped between resources, and wondered whether I was even learning the right way.

At some point, I made a decision that changed everything.

I started teaching what I was learning.

Not because I was an expert, but because teaching forced me to understand. It exposed my weak spots. It made me think deeper. That simple shift gave birth to a philosophy that still guides everything I do today:

Learn Today. Teach Tomorrow.

And that brings me to the real question for today.

The Real Question

If I were starting Java today, in the era of AI tools and instant answers, how would I learn?

Would I still read documentation?
Would I let AI generate code for me?
Would I rely on YouTube videos?
Would I pay for a boot-camp?
Would I use AI to shortcut the journey, or to strengthen my understanding?

There is no single correct answer.

Learning is personal. Some people learn best by watching videos. Others prefer structured programs. Some thrive in communities. Others prefer self-paced exploration.

What matters is not the tool you choose.
What matters is how you use it.

First, I Would Still Learn the Fundamentals

Even in the AI era, fundamentals remain king.

No tool can replace understanding how things actually work.

I would focus on:

• Variables and data types

• Control flow (if statements, loops)

• Methods

• Classes and objects

• Collections

• Exception handling

These topics are not glamorous, but they are powerful. They were the bricks I laid before I ever built a house.

Without fundamentals, AI-generated code becomes dangerous. You may get something that works, but you will not understand why it works.

And that gap becomes expensive later.

Second, I Would Use Structured Learning Resources

One mistake beginners make is jumping between random tutorials without direction.

I would start with reliable resources that explain concepts clearly and consistently.

Here are some that I recommend.

Documentation and Learning Platforms

• Official Java learning site

• W3Schools Java tutorials

• Baeldung Java guides

• Java Developer Roadmap

These resources provide clarity and structure. They help you understand not just how to write code, but why code behaves the way it does.

Third, I Would Use YouTube — But With Purpose

YouTube remains one of the most powerful free learning tools available.

Not all channels are equal, though. Some explain concepts clearly and build strong foundations.

Two channels that I consistently recommend are:

• Amigoscode

• Telusko

Both channels explain Java in ways that beginners can follow without feeling overwhelmed.

Learning from videos works best when you:

• Pause often

• Code along

• Try variations

• Make mistakes

• Fix those mistakes

Passive watching does not build skill. Practice does.

Fourth, I Would Consider Structured Programs or Bootcamps

Some learners thrive in structured environments.

Bootcamps provide:

• Curriculum

• Mentorship

• Accountability

• Community

They reduce confusion and provide direction, especially for beginners who feel lost.

At the academy where I work, we offer structured training designed to help learners move from beginner to confident developer.

You can explore it here:

Amigoscode Academy
Bootcamps are not mandatory, but for many learners, they provide the consistency and support needed to stay on track.

Fifth, I Would Use AI — But Carefully

AI tools are powerful.

Used correctly, they accelerate learning. Used blindly, they weaken understanding.

If I were starting today, I would use AI in these ways:

• Ask for explanations

• Request examples

• Debug errors

• Compare solutions

• Understand unfamiliar code

Not:

• Copy full projects

• Skip thinking

• Rely entirely on generated answers

Here is an example of a prompt I would actually use:

Prompt:

You are a senior Java developer and teacher.

Teach me the concept of Java Classes and Objects step by step.

Follow this structure:

1. Explain the concept in simple terms like I am a beginner.

2. Give a real-world analogy.

3. Show a simple Java example.

4. Explain each line of the code.

5. Give me a small exercise to try on my own.

6. After I attempt it, provide the solution.

7. Suggest one small project where this concept can be applied.

Do not skip steps. Do not assume prior knowledge.

Make sure the explanation builds confidence and understanding.

AI should act like a tutor, not a replacement for thinking.

The strongest developers will not be the ones who generate code the fastest.

They will be the ones who understand their code the deepest.

Sixth, I Would Build Projects Early

Reading is useful. Watching videos is useful.

But projects change everything.

Projects expose gaps. They force decisions. They create experience.

Some beginner project ideas:

• CLI calculator

• Task manager

• File organizer

• Simple REST API

• Notes application

Start small.

Finish often.

Improve continuously.

Another Prompt I Would Use — Project-Based Learning

You are a senior Java developer mentoring a beginner.

Help me build a Simple Task Manager in Java.

Follow this approach:

1. Break the project into small steps.

2. Explain what we are building at each step.

3. Provide code only after explaining the idea.

4. Ask me questions to test my understanding.

5. Suggest improvements after each milestone.

6. Recommend how to extend the project further.

Act like a mentor guiding me through the process, not just writing the code for me.

That rhythm builds confidence faster than endless tutorials.

A Resource I Built for You

Along the way, I realized many beginners struggle because they lack structured practice.

So I created something to help.

Java for Everyone

It includes:

• Beginner-friendly Java explanations

• Sample code examples

• Markdown notes

• Exercises to test understanding

• Capstone projects to build confidence

You can explore it here:

Java for Everyone Repository

This resource is designed to help you move from theory to practice. The goal is not just to read code, but to write code and solve real problems.

If you are starting out, this is a strong place to begin building confidence.

Final Thoughts — The Path Still Belongs to You

Learning Java today is easier than ever.

Not because the language changed, but because the tools changed.

We have documentation, videos, communities, structured programs, and AI assistants.

The challenge is no longer access to knowledge.

The challenge is discipline.

If I were starting today, I would not rush.

I would focus on understanding.

I would build slowly.

I would ask questions.

And most importantly, I would teach what I learn.

Because when you teach, you clarify.
When you explain, you strengthen.
When you share, you grow.

That is still the heart of this journey.

Learn Today. Teach Tomorrow.

And if you are just starting, take your first step today. Not tomorrow. Not next week.

Today.

This idea is the main reason I decided to start Java & Beyond.

Why I Started This Newsletter

Over the past few years, I have spent time learning and working with Java, backend systems, DevOps tools, and artificial intelligence technologies(this I started exploring recently). Some concepts were easy to understand. Others took time, patience, and many attempts before they made sense.

During this process, I noticed something important. The moments when I learned the most were not when I was only reading documentation or watching tutorials. The real learning happened when I tried to explain what I had learned to someone else.

Writing and teaching forces you to think carefully. It helps organize ideas and reveals gaps in understanding. When something is difficult to explain, it usually means there is more to learn.

This newsletter is my way of continuing that process. It is a place where I will write about what I learn, what I build, and what I discover along the way.

What This Newsletter Will Cover

Java & Beyond will focus on practical lessons drawn from real work and real learning experiences.

Here are the main areas I plan to cover:

• Java development
  Core concepts, useful patterns, and practical techniques.

• Backend engineering
  Building APIs, structuring applications, and solving real system problems.

• DevOps practices
  Deployment processes, containers, automation tools, and lessons from real setups.

• Artificial intelligence integration
  Exploring how AI tools can be used in modern software systems, mostly around Spring AI and Embabel.

Some articles will focus on explaining technical concepts. Others will share lessons from mistakes, debugging sessions, or project work. Every article will aim to provide something practical that can be applied in real projects.

My Personal Goal

One of my main goals with this newsletter is to improve how I understand technical topics.

Writing about what I learn helps me slow down and think deeply. It encourages me to ask better questions and search for better answers. Over time, this creates stronger understanding and better problem solving skills.

This newsletter will also serve as a personal record of my learning journey. It will capture lessons from projects, experiments, and real challenges.

What You Can Expect

Java & Beyond will be published once every week.

Each issue will include one clear idea, lesson, or experience related to Java, backend engineering, DevOps, or AI. The focus will always be on clarity and usefulness.

The goal is simple. Learn better by explaining clearly, and help others learn along the way.

Thank You for Joining

If you are reading this, thank you for being here at the very beginning.

Whether you are learning Java, working on backend systems, exploring DevOps tools, or experimenting with AI, I hope this newsletter becomes a useful resource for you.

Welcome to Java & Beyond.