It’s not by chance that you’re here. Maybe you’ve just landed a new role, and suddenly you’re expected to master a framework you’ve never touched. Or perhaps your entire team decided  that the entire codebase will be migrated to a new framework or ported to a completely different language. Either way, you’re not alone, we've all been there.Actually you’ve landed in the right hands. Just by being here, you’ve solved half the problem.

See, Software engineering isn’t just plug and play, it’s problem-solving, adapting, learning, unlearning and relearning. One approach might work for someone else but totally miss for you, depending on your context.Its the nature of this craft and  that’s the beauty of it.

In this article, I’ll try to break down the ins and outs I’ve observed over the past three years of my programming journey. I genuinely want to share what I’ve learned along the way, and hopefully, you’ll be able to 

cherry-pick the parts that work best for you

Every pro knows something that we don't. I would say they have a secret sauce/recipe that works for them iregardless of the huddles they face.

So whats the goal here?? Its actually to develop a sense of  direction.

Universal Principles That Apply to Any Language

You are wise enough to reduce overeliance of  LLMs in this learning process.

 urge to actually understand has become greater than mere interest.

 them, see them in action, and know how they solve real problems.

 language or framework you’re trying to wrap your head around. 

probably already built something, struggled with docs

rehash the basics but to help you think differently

 so you can move faster and more confidently irregardless of the tech stack

You  have built a couple of cli tools.If not yet 

 in that tool. Once you learn how to accept input, you're going to 

learn how to filter that data, how to return the data

 - Variables, functions, classes, and promises.

 - Understanding of modules,  and asynchronous programming

 - REST APIs, request/response cycle, and status codes.

Most developers have an wrong appraches eg:

Don't follow step-by-step tutorials. Instead, get requirements and figure out the implementation yourself.

. Third-party tutorials often omit crucial details.There is no other way no matter hard  try to skip this you  will end up here.

Embrace errors and debugging. That's where real learning happens.

learning happens through struggle and failure

, not through passive consumption of content

. A simple CRUD app won't teach you architectural patterns.Eg uplod service that ploads user images and serves  them via a CDN.

 You need to first  understand the core concepts—conditionals, loops, data models, error handling, and variables. 

What you need now isn’t a restart, but a bridge: a way to map what you already know onto any new language or framework.

3. Universal Principles That Apply to Any Language

Well we all know that frameworks are just a wrapper of the main language therefore always relate new concepts to languages you already know:

What is the Framework you are using trying to achieve?? Remember every language/framework has its own  design principles

: Enterprise patterns, dependency injection, modular architecture, built-in security features, and clean separation of concerns.

: Simplicity, explicit error handling, composition over inheritance

: Memory safety, zero-cost abstractions, ownership model

c. Build the Same Project in Different Languages

Use a consistent project (like an interpreter or web server) across languages to highlight differences:

Learning a new programming language/framework doesn't have to be overwhelming. Instead of hoping things stick, you need a structured approach that builds real understanding through some hands on experience.

forcing your mind to map familiar concepts onto unfamiliar territory

. Its like ptting yourself in using vim for the first time on a daiily basis.

learning through active problem-solving, 

not passive reading or watching. It’s about doing, failing, debugging, and doing again.Only until the language begins to feel like second nature.

Building the muscle memory is tiring and requires strategy.

 using documentation and error messages -

The foundation of effective learning is understanding core concepts through hands-on problem-solving. Lets destructure all of this problems 

Start with algorithmic challenges that force you to use essential language features. Every language needs to handle these fundamentals:

Start by selecting a problem set that touches on the basics every language must handle:

 (understand how your language/framework reports and handles errors)

Here's how this looks in practice with NestJS:

Dive into our programming articles for insights and tips. Covering a range of topics, they're perfect for learners at any level eager to expand their knowledge.

Dive into our programming articles for insights and tips.

Articles

Master Any Framework: The Mindset Shift That Actually Works

. From your keyboard to your screen, from memory to disk, from one program to another. Understanding this flow is the key to understanding the whys, hows, whats etc. 

 the temporary rest stops in your data's journey. Your

 exists in three different states simultaneously namely : the

).We barely even realize this happen just within our precious machines."

What a buffer is and how it works under the hood.

How files are stored and retrieved from disk.

How to convert between a file and a buffer in Node.js.

Why and When youtube Api uses streams and buffers interchangeably.


This guide assumes you have some interest in tech and looking forward to having a deeper understanding of what actually happens under the hood ...
Basic understanding of NodeJs

e.g when u want to transfer water to a bottle from a jerrican you first transfer it to a jug then u can now transfer it to a bottle with minimal loss.

Have you ever wondered what are these table like numbers  in the  browser's "Network Requests  Tab"

 - data moves continuously in one direction, piece by piece. You can't stop the belt to rearrange items, you can't go backwards to grab something you missed, and you process each item as it comes. 

 - it sits there permanently, you can access it whenever you want, rearrange its contents(spanner,spark plug), add or remove things, and it stays exactly as you left it until you decide to change it again.

Well then the big question is whats actually:

 is a container for raw bytes where a byte contains 8 bits (0's and   1's) so you maybe familiar with this number 00110101 or 0x000000.

Anytime your program wants to communicate with outside itself, it needs to work through bytes, that’s what every single language understand, that’s what every single language is build on top.

 in a computer is a storage space set aside to hold data before it gets processed.

is anything that is loaded into the memory which is going to be used in the immediate future.

With tools like  Vim, it means any file that you have opened in Vim that is stored in the memory for editing.

 -  A file is a collection of data that is stored permanently on your disk (hard drive, SSD, etc.) 

Examples include :document.txt, image.png all of this just sit on your disk waiting to be accessed  

Files persist even when your computer is turned off - they're your permanent storageA file has a name, location, and contains data that doesn't change unless you explicitly modify it 

 -  A stream is a sequence of data that flows continuously from one point to another.Its like data either coming 

Unlike buffers and files, streams are all about movement - data is always flowing, never static. You can only read a stream in one direction (forward) and you can't go back to re-read previous data

Data in a stream is processed piece by piece as it arrives, not all at once

, applies transformations (like find-and-replace), and writes to another stream.

It scans and processes fields (columns) based on patterns.It doesn't read  the entire file at once but just streams through it line-by-line.

1.What is a buffer and how does it work under the hood?

At its core, a buffer is just a chunk of memory that holds raw bytes.Think of it like reserving a parking lot with numbered spaces - each space can hold one byte (8 bits), and you know exactly where each piece of data sits.

Imagine you're writing data to a file character by character without any 

"practice of preloading and storing a portion of a media file in the buffer or temporary memory of a device that enable media playback without jitter or stuttering"

 Every single character you write triggers a 

 Lets asume we wanna write the word "hello"

 are really expensive since  it requires switching from 

, you make just 1. The buffer acts like a shopping cart - you collect all your items (data) first, then make one trip to the checkout (disk write).

Data is written to disk only when the buffer is full msot efficient for throughput.

Data is written when a newline character is encountered mainly used for terminal output.

Balances efficiency with real-time feedback

Data is written immediately and mainly used for error streams where you need immediate output

Memory Layout: How Buffers Actually Store Data

When you create a buffer in Node.js with 

" These slots are filled with zeros initially, like 

The magic happens in how buffers handle different data types. When you write the string "hello" to a buffer, it doesn't store the word "hello" - it

 The letter 'h' becomes the number 72, 'e' becomes 101, and so on.

Each memory address holds exactly one byte. The buffer maintains two crucial pointers:

Modern computers read memory most efficiently in 

 (usually 4 or 8 bytes at a time). Buffers are typically aligned to these boundaries to maximize performance. This is why you might see buffer sizes like 4096 bytes (4KB) - it's optimized for the underlying hardware.

2.How files are stored and retrieved from disk

While buffers exist in fast RAM, files are stored on much slower but permanent storage like SSDs or spinning hard drives.

 your operating system doesn't just dump the data randomly onto the disk. 

It maintains a file system, essentially a detailed map that tracks where every file is located, how big it is, when it was created, and what permissions it has.

The OS checks its file system map, finds the physical location on disk, moves the read/write head to that spot (on spinning drives), and transfers the data sector by sector into memory. This process is thousands of times slower than accessing data already in memory, which is why the buffer exists as a middle layer. 

: Checks the file system table to find physical locations

: On HDDs, moves the read/write head to the correct track

: Reads data sector by sector (usually 512 bytes or 4KB chunks)

 What Makes Buffers,Streams and Files Different?

When a Distributed Systems Class Becomes a Career Catalyst

Picture this: I'm sitting in my Distributed Systems exam, heart racing as I face a ten-mark question about Remote Procedure Calls. The question demands a diagram, and my mind scrambles to recall some bit of knownledge I heard about gRPC, Protocol Buffers, and bidirectional communication patterns for me to put something down. Despite my best efforts to sketch something coherent, I know my answer barely scratches the surface of what's required.

You know that feeling when you've missed the target even before seeing the results? Yeah, that was me in that moment.

Rather than brushing it off and moving on, the experience lit a fire under me. What exactly was an RPC? Why was it important in distributed systems? How does it differ from the REST APIs I'm comfortable with?

The more I researched, the more I discovered about software architectures I hadn't fully understood:Here are some of the findings:

: Software organized in horizontal layers, with each layer communicating only with adjacent ones.

: Kernel, drivers, system calls, applications

: Enables programs to call procedures on remote systems as if they were local.

: Google's high-performance RPC framework

: Remote method calls between Java objects

: Applications structured as loosely coupled services with standardized interfaces.

: Separate services for accounts, loans, investments

: Business modules integrated through service interfaces

: Small, independent services developed and deployed individually.

: Hundreds of services for recommendations, authentication, content

: Thousands of services for distinct business capabilities

: Systems where components communicate through events from producers to consumers.

: Market data events triggering analysis and trades

: Sensor events activating connected devices

No Theory Goes without a Practical Application Behind It :The Challenge

Learning without application is like reading about swimming without ever getting wet. I needed a real project to cement my understanding.

That's when it hit me – why not convert one of my most familiar integrations, the M-Pesa Daraja API, from REST to RPC?

: Google's high-performance RPC framework using Protocol Buffers

: End-to-end typesafe APIs made easy, built for TypeScript developers

After weighing the options, I chose tRPC. Why? Because who doesn't love the 

? The promise of type safety across frontend and backend was too good to pass up.

Move Fast and Break Nothing. End-to-end typesafe APIs ...

 : his is waht trpc means to every eveloper that adopts it....

For those not familiar, tRPC (TypeScript Remote Procedure Call) creates end-to-end typesafe APIs without schemas or code generation. Unlike traditional REST APIs where you need to manually maintain type definitions, tRPC leverages TypeScript's type inference to ensure full type safety across your client and server.

The key advantages that led me to choose tRPC for this integration:

: Full end-to-end type safety without any code generation

: Autocompletion and compiler checks catch errors before runtime

: No need for separate API documentation or validation libraries

: Handle authentication and token management with tRPC middleware.

: Build secure and efficient API calls using TypeScript.

: Implement clean and straightforward client-side logic.

: Discover the advantages of tRPC in reducing bugs and improving documentation.

Basic understanding of Mpesa-Daraja Api (Reference this article  && great should out to the author Mary Maina 

 requires a specific authentication flow:

It uses the username and password to obtain an accesstoken that u can progressively use in the other subsequent invocations.....

Obtain an access token from their authorization API

Use this token in subsequent API calls (STK Push, B2C, C2B, etc.)

In my original REST implementation, I used Express middleware to handle this authentication flow:

For reference i will be  using my own implementaion that i did back then 

The middleware would fetch the token and attach it to the request object, making it available to downstream handlers. But how would this work in the tRPC paradigm?

The frontend makes a request to initiate payment with a phone number and amount

The backend authenticates with the M-Pesa API

The server sends an STK Push request to M-Pesa

M-Pesa sends a payment prompt to the user's phone

The user confirms payment by entering their PIN

M-Pesa sends the result back to our callback URL

Before diving into implementation, it's important to understand the key differences:

HTTP-based with explicit routes and HTTP methods

Authentication typically handled through middleware

Request and response formats vary (JSON, form data, etc.)

Below is an illustration of the Rest Architecture pattern 

Middleware works differently than in Express

MPesa Daraja 2.0 + TRPC 

Authentication is one of the ways of securing your applications (the communication between the client and server) and one effective method is 

, which ensures users can securely access protected resources

This guide explains how token authentication works, focusing on 

This is a method where users authenticate once and receive a token, which is then sent with every request to verify identity. Unlike session-based authentication, which relies on storing session data on the server, tokens allow for 

There are different kind of authentication methods, which are:

 - Single Sign-On via third parties like Google, Microsoft, etc.

 Hardware devices like YubiKeys, smart cards

 (email & password) on the client side, by filling in a form.

The client sends it to the server, which is then validated

 securely (e.g., in memory or HTTP-only cookies).

 in the request header for protected routes.

One of the widely used methods for securing API authentication. They provide a stateless way of authenticating users, allowing applications to verify identity without storing session data on the server.

 is a compact, URL-safe token format that encodes JSON objects to form a secure way in which data is transferred through two parties. It mainly consists of three parts:

 - Specifies token type and signing algorithm that is used.

 - Contains claims (usually data about the user or entity). like user ID, role, and expiration time.

 - Ensures token integrity using a secret key. A signature is created using the algorithm specified in the header to sign a combination of the encoded header, the encoded payload and a secret. The secret helps us verify that the token hasn’t been tampered with and should be kept somewhere safe (you can use env variables)

NOTE: You should not always include sensitive data in the payload, since it isn't secured by default unless there is additional encryption.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Authentication flow: in-depth explanation

Validate and sanitize input (e.g., check email format, ensure fields aren’t empty, enforce strong passwords).

Package the data into a JSON object and send it to the signup endpoint.

Hash and salt the password using a library like 

Check for duplicate users (if needed) and save the user details in the database.

NB: Enhance the authentication flow by redirecting users directly to the app after signup instead of the login page. Since we already have the user’s credentials, we can issue an access token upon signup, just like during login.

Collect user credentials and validate input (e.g., check email format, ensure fields aren’t empty).

Package the data into a JSON object and send it to the login endpoint.

Compare the stored hashed password with the one provided by the user.

Using a JWT library, generate two tokens:

Short-lived (expires in minutes or hours).

Contains essential data like user ID, roles, and permissions.

Used to generate new access tokens when the current one expires.

Sent back to the client as a JSON response.

Stored in memory using state, context, or variables (e.g., in React).

Used in the Authorization header for all protected requests.

Search For

Master Any Framework: The Mindset Shift That Actually Works

What Makes Buffers,Streams and Files Different?

MPesa Daraja 2.0 + TRPC

Token-Based Authentication Guide

Learning S3 Lifecycle Policies for the AWS SAA exam

Mastering Application Load Balancers for the AWS SAA Exam

Mastering AWS Security Groups for the AWS SAA exam

Machine Learning Services for the AWS SAA-C03 Exam

Real-Time Data Processing with Amazon Kinesis

Practice Frontend, Android and iOS by building real world projects.