DEV Community: Brix Mavu

5 Principles of Survival for Software Engineers

Brix Mavu — Sat, 06 Jun 2026 09:50:38 +0000

5 Principles of Survival for Software Engineers

Adapted from Leon Business School's "5 Principles of Survival"

Your stack won’t save you. Your principles will.

In the wild, survival isn’t about having the best gear. In software, survival isn’t about having the absolute best framework. It’s about how you operate when production is on fire, the roadmap shifts overnight, and AI just turned your "moat" into a weekend hobby project.

Here are 5 core principles that keep you alive in modern software engineering.

1. 🔥 Adapt or Perish

Change is not optional; it is the price of survival.

In the wild: The species that cannot adapt to winter dies.
In software: The team that cannot adapt to change dies slowly at first, then all at once.

"Localhost is for amateurs" used to be a strongly held belief. Now, Claude writes a full CRUD API in 30 seconds on localhost. "We’re a React shop" was a proud identity. Now, HTMX ships the same feature before your Webpack build even finishes.

Your identity as an engineer cannot be tied to a specific tool. Your identity is solving problems. The syntax is temporary. Agreement on what to build is what actually matters.

🛠️ Survival Action

Every quarter, deliberately kill one "we’ve always done it this way" rule in your workflow.

2. 🧭 Stay Calm Under Pressure

Panic is the first casualty of poor preparation.

In the wild: Panic burns critical calories and gets you lost.
In software: Panic causes a git push --force to main on a Friday at 4:59 PM.

Outages don’t kill companies. Panicked responses do. The team that has clear runbooks, relies on feature flags, and can execute a rollback in under 90 seconds stays calm. Why? Because they prepared when it was quiet.

If your first step in incident response is opening X (Twitter) or complaining in a public Slack channel, you have already lost.

🛠️ Survival Action

If you don't have a tested rollback plan, you don't have a deployment plan. Write it down before your next release.

3. 💡 Resourcefulness Over Resources

It’s never about what you have; it’s about what you do with it.

In the wild: You can survive with just a knife and a tarp if you know how to use them.
In software: You can ship and scale with a $5 VPS and SQLite if you understand the core problem.

We often call things "technical debt" when they are actually "imagination debt." You do not need Kubernetes to serve your first 1,000 users. You do not need microservices to test an early product idea. A Google Sheet paired with an Apps Script that texts your users is real, valuable software if it solves a real-world problem.

Resourcefulness is realizing that Excel is often just a localized SQL database, a localhost setup with a cron job can act as an IoT network, and the best tech stack is almost always the one you already know.

🛠️ Survival Action

Before adding another heavy dependency to your package file, ask: "Can I solve this with native Bash, Postgres, or standard library features?"

4. 🎯 Know Your Core, Never Lose It

When everything else is stripped away, what remains must be unbreakable.

In the wild: Your core needs are shelter, water, and fire. Lose those, and you lose everything.
In software: Your core is the user’s job-to-be-done. Lose that, and you are just burning investor cash.

"More features" is how products die of bloat. Conditional boolean flags for every single enterprise customer is how codebases die of complexity.

Your core has to be unbreakable:

For Google, it is search retrieval.
For Stripe, it is moving money safely.
For your side project, it is the one single feature your users would be angry to lose if it went offline.

Everything else is an abstraction. Delete the abstractions, never the core.

🛠️ Survival Action

Write your product’s "core value" in a single, plain sentence. If a proposed feature does not directly serve that sentence, treat it as noise.

5. ♾️ Outlast, Outthink, Outlive

Survival is a long game. Play it accordingly.

In the wild: The winner isn’t the fastest predator; it’s the one still standing after winter ends.
In software: The winner isn’t the first to integrate the latest hot library. It’s the one still shipping value long after the hype cycle has moved on.

The industry is cyclical. Code became a high-paying corporate profession; now, with generative tools, it is democratizing into a creative hobby again. Large corporations will always chase quarterly profits, but dedicated builders will always keep the web weird, functional, and alive.

Not all of us will remain pure developers, and not all developers will become system architects. But the engineers who survive the trends are the ones who owned the problem, not the syntax. They understand that automation is not about technology for its own sake—it is about simplifying human life.

🛠️ Survival Action

Choose utility over aesthetics. Lean on "boring" technology that is highly likely to still be actively maintained in 10 years.

The Real Tech Stack

Beliefs are tools, not absolute truths. These 5 principles are the ones that will serve you when your metrics are bleeding red, the funding runs out, and the only things left are your repository and your judgment.

A program is just what we agreed should be done, then automated.
Survival is just what we agreed cannot break, then defended.

Hold your users firmly. Hold your tech stack loosely. Outlast, outthink, outlive.

How to Choose Tech Decisions That Serve You (And the "This Must Be False" Rule)

Brix Mavu — Sat, 06 Jun 2026 09:24:57 +0000

Inspired by Nir Eyal's "beliefs are tools" framework

Beliefs are tools, not truths. Tech stacks are too. Pick the ones that work for you.

Most "tech debt" is actually "belief debt". We hold onto frameworks, patterns, and processes long after they stop serving the product. To build great software, we need to introduce a core rule: If a tech belief or "best practice" doesn’t solve a real problem for you right now, it must be treated as false.

Here is how to audit your tech beliefs using 5 filters.

1. ARE THEY USEFUL?

The real question isn’t "Is this the best tech?" It’s "Does this serve the user?"

Tools are tools. Keep the ones that ship.

Bad belief (Treat as False): "We need Kubernetes because it’s the industry standard."
Useful belief (True for Now): "A $5 VPS serves 10k users. We’ll use K8s when we have a scaling problem, not a resume problem."

If your architecture choice doesn’t make the core loop faster, cheaper, or simpler for users, it’s not serving you. Delete it.

2. ARE THEY TESTED?

A useful stack holds up when the world pushes back. Pay attention to production, not the trending blog posts.

Bad belief (Treat as False): "Microservices are inherently more scalable"—said before you even have 2 concurrent users.
Tested belief (True for Now): "Our monolith handles 50 req/s perfectly. We’ll split services only when latency exceeds 300ms in prod."

Load test it. Dogfood it. If it only works in a conference slide deck, it’s a story, not a tool.

3. ARE THEY OPEN?

A tech choice you can’t change has stopped being a tool and has become a cage. Hold opinions firmly, but hold implementations loosely.

Bad belief (Treat as False): "We’re a React shop forever."
Open belief (True for Now): "React serves us today. If HTMX lets us ship this feature in 2 days instead of 2 weeks, we’ll use HTMX."

In a famous study on hope, Curt Richter’s rats swam for 60 hours when they believed rescue was coming. Your team will grind for years on a legacy stack if they believe it can actually be refactored. Lock-in kills hope. Escape hatches keep teams swimming.

4. ARE THEY HONEST?

If keeping the stack means looking away from your core metrics, it’s costing you money and sanity.

Bad belief (Treat as False): "Our GraphQL layer is incredibly flexible" (while your TTFB is 2.1s and junior developers can’t query it).
Honest belief (True for Now): "GraphQL is slowing us down. A basic CRUD API will let us ship tomorrow."

Drop stacks that require you to lie to yourself during retrospectives. If you’re constantly explaining away bugs, customer churn, or onboarding delays, the belief itself is the bug.

5. ARE THEY LIBERATING?

Some architectures open doors. Others quietly close them. Keep the ones that give your team agency.

Bad belief (Treat as False): "We can’t launch until the event-driven saga pattern is architected perfectly."
Liberating belief (True for Now): "A cron job and Postgres gets us 80% of the way there. We’ll ship today and refactor when scale demands it."

A Columbia University study showed a 75% drop in depression symptoms for people who felt a sense of personal agency. Teams with agency ship code. Teams trapped by dogmatic "best practices" drown in meetings.

WHAT TECH BELIEFS CAN DO

Impact metric	The Reality behind the Metric
60 Hours	How long a team will debug a flaky E2E test suite if they blindly believe "100% coverage" will save them. (Teams with simple tests but high trust can ship a fix in 15 minutes).
7.5 Years	How much longer codebases last when built with simple, boring tech. It is a far bigger predictor of software longevity than rewriting in Rust or Elixir.
75%	The drop in support tickets and feature requests when you delete bloated settings pages. For most products, configuration is a tax on users who just want the defaults to work.

UPGRADE YOUR TECH BELIEFS

Dimension	Old Belief (Treat as False)	New Belief (Useful Tool)
Action	"We need a fully approved RFC before we write a single line of code."	"We can ship a spike in 2 days and learn from production telemetry."
Difficulty	"If it’s hard to build, our architecture must be wrong."	"If it’s hard, we are simply tackling real-world, inherent complexity."
Failure	"We tried NoSQL once before and it failed to scale."	"Our previous attempt taught us where our actual system constraints lie."
Identity	"We are strictly a TypeScript company."	"We use types when they prevent critical bugs and speed up developer velocity."
Ability	"I’m just not a DevOps person."	"I haven’t found the medium where Infrastructure-as-Code clicks for me yet."

The Point

A program is just what we agreed should be done, then automated. Your stack is just a belief about how to do it.

Excel is SQL.
localhost is production if it automates your house.
A Google Sheet that texts your users is real software.

Beliefs that serve you look like: shipping fast, using simple CRUD APIs, and deleting dead code.

Beliefs that do not serve you look like: arguing over aesthetics, waiting for perfect alignment, and calling simple solutions "amateur."

Hold your users firmly. Hold your tech loosely.

Agreement is the only real tech stack.

From Excel to AI: We Were Always Programmers

Brix Mavu — Fri, 05 Jun 2026 19:21:11 +0000

Times change. Tools change. But the fundamental question of software development never does: What are we actually agreeing to build?

In the age of generative AI, where the barrier to writing code is collapsing, we need to reframe how we view our craft. The future of software isn't about hoarding syntax; it's about establishing alignment.

1. The Full Cycle of Code: From Syntax to Intent

AI represents the closing of a massive loop. We have transitioned from punching physical cards, to writing low-level assembly, to wrestling with massive framework boilerplates, and now, finally, to simply describing what we want in plain language.

[Punch Cards] ➔ [Assembly/C] ➔ [High-Level Frameworks] ➔ [Intent-Driven AI]

Syntax matters less with every passing year. What matters now is the agreement between stakeholders: users, developers, businesses, and communities.

Code started as a necessity born of military and academic research. It evolved into a highly specialized corporate profession. Now, with AI democratizing creation, it is circling back to being a hobbyist medium once again. And that is incredibly healthy.

The Corporate Developer ships because they must hit a quarterly profit target.
The Hobbyist Creator writes because they genuinely care about solving a problem.

Both motives are valid, but when the market crashes and the venture capital dries up, it’s always the hobbyists and the open-source community who keep the web alive.

2. Code as Literacy: Profit vs. Necessity

Corporations are brilliant at scaling ideas. But profit alone cannot be the ultimate metric for the existence of software development. If a tool serves communities, it should be treated as a basic societal necessity—like basic mathematics, or reading.

"We don't debate whether literacy is profitable. We teach people to read and write because it makes everyday life navigable. Code is heading toward that exact same status."

Not everyone will become a professional software architect, just as not everyone who learns to write becomes a published novelist. But almost everyone sends messages, fills out spreadsheets, and runs logical steps in their mind daily.

If you can think logically, you are already executing runtime logic. That is programming.

3. Ownership Is the Real Divide (And Yes, Excel is Programming)

I often meet professionals who sheepishly say, "Oh, I don’t understand code," right before showing me an incredibly complex financial model they built from scratch in Excel.

Here is the secret we don't say out loud enough: Excel is SQL. It is functional programming.

=VLOOKUP() is a function call.
A Pivot Table is a database query.
Cell dependencies are a reactive state graph.

=IF(A1="Yes", VLOOKUP(B1, DataRange, 2, FALSE), "Pending")
// This is not "just a spreadsheet." This is a conditional database query.

Technologically underserved communities or countries don't lack engineering talent; they lack ownership of the identity. They have been gatekept into believing that "code" is a mysterious artifact created only by people in Silicon Valley. Meanwhile, they are already building complex logical workflows to run their businesses without the label.

The gap isn't skill. It's the agreement on what counts as "real" development.

4. What Is a Program, Really? (Stop Gatekeeping Localhost)

At its absolute core, a program is nothing more than an agreement on what should be done, translated into automation.

That’s it.

# A cron job running on a Raspberry Pi in your closet:
0 8 * * * curl -s "http://localhost:5000/water-plants"

You can run your own local IoT server on localhost to automate your home. No cloud, no venture capital, no internet connection required. Yet, our industry has trained us to look down on "localhost" projects. We are told that "real" software must be deployed to AWS, scale to millions of concurrent users, and utilize a complex Kubernetes cluster.

We forgot that automation is about simplifying human life, not satisfying cloud providers.

If a single cron job on a $35 Raspberry Pi waters your garden, that is real software. If a shared Google Sheet automatically texts your mother a daily reminder to take her medicine, that is world-class engineering. The cloud didn't make those solutions valid. The fact that they solved a real-world problem did.

5. The New Compromise: Intent Over Syntax

We waste endless energy arguing about "our data," yet we signed it away years ago. Every social media Terms & Conditions screen made it clear: if the service is free, your behavior is the product. That ship has sailed.

The new frontier isn't about hoarding data; it's about establishing a compromise on what we choose to automate, for whom, and why.

AI closes the loop by allowing non-technical domain experts to self-solve. You describe the problem, receive the functional logic, and deploy it—either locally for yourself or globally for your community.

The circle is complete when a non-developer can solve their own operational bottleneck without needing to ask a gatekeeper for permission. That is the moment coding becomes as natural as reading: a basic utility of modern life.

Summary: The Syntax-Free Future

Times change, but the necessity of human compromise and alignment never will. AI is not going to replace software developers; it is going to replace the outdated idea that only developers are allowed to write software.

The future isn't a world where 8 billion people are sitting around debugging memory leaks. The future is a world where everyone can clearly articulate what they want automated, and use whatever tool—be it an LLM, a spreadsheet, or a local script—to make their lives simpler.

Ownership of the problem will always beat ownership of the syntax. Every single time.

What do you think?

Does Excel count as programming in your book? Are we gatekeeping "real" development too much in the age of AI? Let's discuss in the comments below!

The Battle of the Senior Dev: Why AI Gives You Wings But Only If You're Ready to Pilot

Brix Mavu — Sat, 23 May 2026 07:19:10 +0000

The struggle of building solutions that actually hold up

Forget factory tools and manufacturing jargon. The real struggle is this: AI can write code faster than you can think, but it can’t tell you what’s worth keeping. That’s where senior devs get their edge.

Here’s how it works, using what actually happens in the trenches:

1. The Quality of Your Question Decides the Quality of Your Solution

AI is a mirror. Ask it "my code doesn’t work" and you get garbage back.

Good programmers do this instead:

Narrow the problem: "Auth breaks after 10 min, only in Safari."
Give context: Specify the framework, what you expect, and what’s actually happening.
Show what you tried: "I checked the token expiry, tried localStorage, but it still fails."
Share the error: Paste the exact stack trace—don’t paraphrase it.
State assumptions: "I assume the session cookie is expiring."

Why? Asking effective questions saves time, speeds up debugging, streamlines collaboration, and makes AI genuinely useful. Garbage in, garbage out. Question quality = answer quality.

2. Knowing When to Stop Coding Is the Real Skill

Here’s the trap: More code = more productivity. It feels true, but it’s backwards.

Reality: More code = more maintenance.

Every feature, abstraction, and layer you add is something you’ll have to debug at 2 AM six months from now. Experienced engineers know when to stop.

The better solution is usually to:

Remove complexity rather than adding it.
Delete logic you don't actually need.
Use a tool that already exists.
Reduce the number of moving parts.

The shortest code that reliably solves the problem is almost always the easiest to maintain. Elegance isn’t about being clever; it’s about being boring in a good way.

3. Stay Calm When Everything’s On Fire

Beginners panic when production goes down. They:

Change random files hoping something sticks.
Introduce three new bugs while trying to fix one.
Ignore the error message staring them in the face.
Make assumptions instead of checking facts.

Skilled engineers have developed emotional discipline. Their debugging process is systematic:

Observe: What exactly broke?
Reproduce: Can you make it happen again locally?
Isolate: What changed? Narrow down the delta.
Test assumptions: Is the database actually down, or is it just the connection pool?
Verify: Fix the issue, then confirm it’s actually resolved.

Stress causes tunnel vision. Calm gets you to the root cause faster.

4. Naming Things Is Half the Job

There’s a classic computer science joke for a reason: "There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors."

// Hard to read, raises cognitive load
let x;
let data2;
function processThing() {}

Good names remove confusion, cut onboarding time, reduce bugs, and save valuable mental effort:

// Intent is immediately clear
let customerProfile;
let invoiceTotal;
function calculateMonthlyRevenue() {}

Code is read 10x more than it’s written. If you can’t tell what processThing() does without opening it up and reading its internals, you’ve already lost. Clear names matter more than clever algorithms.

5. Manage Your Energy, Not Just Your Time

Programming is mentally expensive. You can work an 8-hour day and get absolutely nothing done if you are distracted, sleep-deprived, or context-switching every five minutes. Time management is completely useless if your brain is fried.

Consider the difference:

Developer A: Distracted, sleep-deprived, context-switching constantly. Result: 8 hours worked, 0 progress.
Developer B: Focused, rested, working in protected deep work blocks. Result: 4 hours worked, high-quality features shipped.

Elite devs don't just manage calendars; they manage cognitive capacity. They protect:

Sleep and physical health.
Focus and deep work periods.
Strategic breaks (knowing when to walk away from a screen).

Burnout destroys productivity faster than a lack of knowledge ever will. AI won’t fix this for you. If you’re fried, you'll just use AI to generate more garbage, faster.

💡 So How Does AI Fit Into This?

AI gives you wings, but only if you’re already a pilot.

Use it to narrow problems: "Here’s the error, here’s what I tried, what am I missing?"
Use it to stop over-coding: "Is there a simpler way to do this?" Let it challenge your abstractions.
Use it to stay calm: Paste the error and ask, "Walk me through debugging this step-by-step." Let it be the calm voice in a crisis.
Use it to name things: "Give me 5 better names for this function that explain what it does."
Use it to save energy: Let it write the repetitive boilerplate, basic tests, and documentation so you can spend your brainpower on the hard architecture decisions.

The struggle of creating a worthy solution isn’t writing more code. It’s knowing what to delete, when to stop, and how to think clearly when everything is broken. AI can’t do that for you. But if you’ve got those skills, AI makes you 10x faster at executing them.

6. Break Giant Problems Into Tiny Pieces

Junior devs see "Build an e-commerce platform" and freeze. Experienced devs shrink the scope immediately:

User Authentication
Product Model & Schema
Cart Functionality
Payment Gateway Integration

Programming is, at its core, decomposition. Huge, complex systems are just collections of tiny, solved problems.

With AI: Don't ask it to "build me an e-commerce platform." Ask it to "write a localized cart reducer in TypeScript with unit tests." Small chunks lead to better AI output and lightning-fast feedback loops.

7. Understanding Human Behavior Is an Engineering Skill

Software is built for people, but many developers only think about machines.

Understanding human behavior helps you predict:

Common user mistakes.
Confusing user interfaces.
Team communication bottlenecks.
Evolving product expectations.
Customer frustrations.

Technical skill without human understanding creates systems that are mathematically correct but practically unusable. Empathy is an engineering skill. AI can write code, but it can’t tell you if a user will actually find your layout intuitive. That’s on you.

8. Learning to Estimate Work Accurately

New devs often say, "That feature should take about an hour."

They forget that actual delivery includes:

Writing the code.
Debugging and local testing.
Writing unit and integration tests.
Handling unexpected edge cases.
Preparing the deployment.
Addressing pull request revisions.

The actual time: 8 hours.

Good estimation builds trust with clients, product managers, and teammates. Experienced devs always build a buffer for uncertainty because they know things always break.

AI Tip: Before committing to an estimate, ask the AI: "What are the hidden architectural gotchas or edge cases for this feature?" It will frequently surface things you forgot to account for.

9. Write Notes for Future-You

Memory fails. Over time, "future-you" essentially becomes a stranger.

Great programmers document:

Why specific tradeoffs were made.
Architectural decisions (ADRs).
Non-obvious setup steps.
Debugging discoveries.
Workarounds for unusual legacy bugs.

If you don’t document your work, you will spend hours re-learning what you already figured out last month. AI can easily help with this if prompted: "Write a README section explaining why I chose library X over library Y here."

10. Recognizing Patterns Is Where Speed Comes From

Programming eventually becomes an exercise in pattern recognition.

With enough years of exposure, you instantly spot:

Repeated architectural smells.
Common security vulnerabilities.
Performance bottlenecks.
Recurring bugs in standard flows.

This isn’t magic; it's accumulated experience. When you've watched twenty authentication systems break the exact same way, you can diagnose the problem in 30 seconds.

With AI: AI can generate design patterns fast, but you are the gatekeeper who must say, "Wait, I’ve seen this pattern cause a memory leak in high-concurrency environments." Reading and reviewing code is now a much more critical skill than simply generating it.

11. Know When Not to Reinvent Everything

Developers love to rebuild tools—sometimes for learning, but often for ego.

Common traps include:

Writing custom cryptographic or auth packages.
Creating a bespoke database engine.
Building a custom frontend framework for a simple landing page.

While building from scratch teaches you a lot, it can also waste weeks of valuable project time. Strong engineers ask: "Does this need to be custom, or does a mature, tested library already exist?"

Because AI makes generating custom code so effortless, this question is more critical than ever. Default to proven tools unless you have a highly specific, business-critical reason not to.

The pattern here: Senior devs win because they manage their mental bandwidth, break problems down, empathize with users, estimate realistically, document for the future, and avoid unnecessary work. AI amplifies these habits, but it cannot replace them.

12. Debugging Through Elimination, Not Guessing

Beginners debug by guessing. They think, "Maybe it’s the database?" and change five different configurations. When it remains broken, they’ve only succeeded in adding chaos to the system.

Effective debugging is scientific detective work:

Formulate hypotheses: Is the DB connection failing? Is the API payload malformed? Is local state out of sync?
Isolate and eliminate: Use tests, targeted logs, or breakpoints to test each hypothesis one by one until only the true cause remains.

Systematic elimination beats random experimentation every single time. AI is a fantastic brainstorming partner here—paste your logs and ask, "What are 5 possible causes for this error?"—but you must still systematically verify them.

13. Communication Is a Programming Skill

Many people picture coding as a solitary activity. In reality, modern software development is deeply collaborative.

You communicate constantly through:

Clear Pull Request descriptions.
Well-structured technical documentation.
Active participation in meetings.
Meaningful code comments.
Constructive code reviews.
Clear issue reports.

A developer who can explain complex ideas clearly will almost always outperform someone who is technically brilliant but impossible to collaborate with. Communication scales your technical expertise.

Rule of thumb: If you can't explain your AI-generated code in a PR, you don't actually understand it. Delete it and try again.

14. Focus on Fundamentals over Frameworks

Technology moves fast. Frameworks evolve, languages shift, and hyped tools can disappear overnight. If you only learn the API surface of the latest trendy library, your knowledge has an expiration date.

Strong engineers focus on the underlying fundamentals:

HTTP protocols, networking, and security basics.
Data structures, system design, and algorithmic thinking.
Clean architecture principles that transcend any single language.

When you understand how systems work at a fundamental level, transitioning from React to Svelte, or from Node to Go, becomes a minor syntax adjustment rather than a career crisis.

15. Master Meta-Learning (Learning How to Learn)

The ultimate survival skill in tech is meta-learning. Eventually, every programmer hits a wall where there is no tutorial, no StackOverflow post, and no step-by-step guide for the problem at hand.

To learn efficiently:

Build projects, don't just watch videos: Avoid the "tutorial purgatory" trap where you feel productive but cannot write code on a blank canvas.
Experiment often: Break systems on purpose to see how they fail and how they behave under stress.
Build robust mental models: Understand why things work, not just how to copy-paste them.

AI changes this game entirely. You can use it to explain complex concepts, generate scaffolded practice projects, and summarize dry documentation. But remember: AI cannot build the mental model for you. You still have to do the hard cognitive work of learning.

Final Thoughts: The Real Upgrade

The biggest career upgrades rarely come from memorizing syntax. They come from these invisible habits:

Thinking clearly: Breaking large, scary problems down.
Communicating well: Making complex ideas understandable to anyone.
Simplifying systems: Removing unnecessary complexity.
Controlling emotions: Staying objective and calm when production is down.
Managing energy: Ruthlessly protecting your focus and cognitive capacity.
Learning continuously: Adapting quickly when the technical landscape shifts.

Frameworks change every few years, but these core habits remain valuable for decades. They are what separate developers who merely write code from true software engineers.

AI gives you speed, but these habits give you direction. And without direction, speed just gets you lost faster.

Getting Started with Hyperswitch, Nodejs, and Express for Payment Processing

Brix Mavu — Fri, 11 Oct 2024 19:52:44 +0000

Introduction

Welcome to this step-by-step tutorial on using the Hyperswitch API with Express and Node.js! In this first part, we'll walk you through creating a basic app using Node.js and Express. Later, in part two, we’ll integrate multiple payment gateways with the help of Hyperswitch.

Why Hyperswitch?

Hyperswitch allows you to connect to various payment processors and payment methods, making it easier to manage transactions. Meanwhile, Node.js enables you to run JavaScript on the server side, and Express simplifies the process of building web applications and APIs.

Requirements

Before we start, make sure you have the following:

Node.js installed on your system
Hyperswitch API keys
A text editor (I’ll be using Vim on Termux, but feel free to use your favorite editor like VS Code)

Step 1: Create a "Hello World" Application

Open your terminal.
Create a new folder for the project:
```
mkdir hyperswitch
```
Navigate to the folder:
```
cd hyperswitch
```
Initialize a Node.js project by running:
```
npm init -y
```
This will generate a package.json file that manages your project’s dependencies and configurations.

Create a server file.
You can create it using your text editor’s UI or in the terminal:

touch app.js

Since I’m using Vim, I’ll run:

vim app.js

and paste the "Hello World" code from the Express documentation:

const express = require('express');
const app = express();
const port = 3000;

app.get('/', (req, res) => {
res.send('Hello World!');
});

app.listen(port, () => {
console.log(`Example app listening on port ${port}`);
});

Save and exit the editor (in Vim, this would be :wq).
Install Express by running:
```
npm i express
```
Run the app and open your browser at http://localhost:3000/. You should see "Hello World!" displayed.

Step 2: Connecting to Hyperswitch

Now that you have a basic app running, let’s connect it to Hyperswitch.

Sign up for Hyperswitch.
For a smoother experience, it’s best to complete the sign-up process on a desktop or laptop.
Get your API key from the settings. This key will allow your app to interact with the Hyperswitch API.

Note: For this tutorial, we’ll paste the API key directly into our code. However, this is not recommended for production environments. We’ll cover a more secure method later.

Update your code to create a customer through Hyperswitch. Replace the previous code in app.js with the following:

const express = require('express');
const app = express();
const port = 3000;

app.get('/', (req, res) => 
{
/* Fetching the API key from 
Hyperswitch to create a 
customer */
  const options = {
  method: 'POST',
  headers: {
  'api-key': '<api-key>', 
  'Content-Type': 'application/json'
},
body: JSON.stringify({
  email: 'guest@example.com',
  name: 'John Doe'
})
}; 
fetch('https://sandbox.hyperswitch.io/customers', options)
.then(response => response.json())
.then(response => console.log(response))
.catch(err => console.error(err));
res.send('Customer creation initiated.');
});

app.listen(port, () => {
console.log(`App listening on port ${port}`);
});

Insert your API key by replacing with the actual key from Hyperswitch:

headers: { 'api-key': 'snd_xxxxxxxxxxxxx', 'Content-Type': 'application/json' }

Save the changes to app.js and run the server:
```
node app.js
```
Refresh your browser and check the terminal. You should see your first customer entry logged!

That’s it for part one! Now you’ve created a basic Express app and connected it to Hyperswitch to create customers. In the next part, we’ll dive deeper into handling payments and managing multiple gateways.

Stay tuned!

Setting Up Termux and Node.js on Android for Web Development

Brix Mavu — Fri, 22 Jul 2022 20:35:27 +0000

Want to start web development on your Android phone? This guide will show you how to use Termux and Node.js to set up a web development environment and create your first project.

Step 1: Install Termux and Node.js

Download Termux
Termux is a powerful terminal emulator for Android. Download it from F-Droid, and make sure to get the latest APK file from the bottom of the page.
Update Termux
Open the Termux app and run the following commands to update the package list:
```
$ pkg update && pkg upgrade
```
Install Git
Git is essential for version control. Install it by running:
```
$ pkg install git
```
Install Vim
Vim is a popular text editor for developers. Install it by running:
```
$ pkg install vim
```
Install Node.js
Node.js is a JavaScript runtime that allows you to run JavaScript outside the browser. In this tutorial, we will use Node.js to run http-server , a simple tool to serve your web projects locally. To install Node.js, run the following command:
```
$ pkg install nodejs
```

Step 2: Start Your First Project

Set Up Storage Access
To access your phone’s internal storage in Termux, run:
```
$ termux-setup-storage
```
Navigate to the Internal Storage
After running the above command, you can navigate to the storage directory by typing:
```
$ cd storage/shared
```
Create a Project Folder
Create a new directory for your project:
```
$ mkdir project
$ cd project
```
Create Your First Files
Now, create the HTML and CSS files for your project:
```
$ touch index.html style.css
```

Step 3: Writing Your First HTML Page in Vim

Open the HTML File in Vim
Use Vim to open and edit your index.html file:
```
$ vim index.html
```

Add Boilerplate HTML Code
Copy and paste the following code into index.html:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<title>My Website</title>
<link rel="stylesheet" href="./style.css">
</head>
<body>
<h1>My First Heading</h1>
<p>My first paragraph.</p>

<script src="./script.js"></script>
</body>
</html>

Add Some Basic Styling
Next, open the style.css file and paste this CSS code to style your HTML elements:
```
h1 {
color: red;
}

p {
color: blue;
}
```

Step 4: Serve Your Project Locally

Install HTTP Server
To preview your project, you need to use a lightweight web server. You can run one easily using npx:
```
$ cd storage/shared/project
$ npx http-server
```
Access Your Website
After running the command, Termux will display a local address (e.g., http://127.0.0.1:8080). Open Chrome or any web browser and paste the address into the URL bar to see your website in action.

You’ve successfully set up your Android phone for web development and created your first project! You can now experiment and build more complex websites using this setup.

Day 5

Brix Mavu — Mon, 04 Apr 2022 21:45:41 +0000

Make use of templating engine - I will use Handlebars

Introduce a generated base for quick development - express-generator

Reason for express generator we can't always built things from scratch the plan is to start from a base.

In terminal run

npx express-generator --view=hbs --git day5

cd day5

npm i

If problems arise just run:

npm audit --force

Start server

npm start

You can check the command in package.json

When server is running open browser and open :

localhost:3000

From day4 prject copy authenticate folder and files inside public folder

style.css will be replace the one in /public/stylesheets

script.js goes inside /public/javascripts

add script tag inside /views/layouts.hbs file

Inside /views/index.hbs file add html forms from day4/index.html

Inside /views/index.hbs login form tag change action tag must be action="users/login"

Day 4

Brix Mavu — Mon, 04 Apr 2022 06:19:00 +0000

The idea is to make a simple login with express

copy day3 folder into day4 folder

moving just contents from one folder into next folder in same root folder in terminal

cp -r folder1/* folder2

create folder authenticate

mkdir authenticate

Inside authenticate folder create new file login.js

touch login.js

Paste this code

const login = function (user,password) {
    if(user==="brix" && password==="brix"){
        return true;
    }
    else{
        return false;
    }

}

module.exports = login

Edit

You have to add the two lines below to start working with json in express
app.use(express.json());
app.use(express.urlencoded({ extended: false }));

app.js should look more like this

const express = require('express')
const path = require('path')
const login = require('./authenticate/login')

const app = express()
const port = 3000

app.use(express.json());
app.use(express.urlencoded({ extended: false }));
app.use(express.static(path.join(__dirname, 'public')))

app.get('/',(req,res) => {
  res.sendFile(path.join(__dirname,'public/index.html'));
})

app.post('/login', function (req, res, next) {
    const user = req.body.username
    const pass = req.body.password
    let loginResult = login(user,pass)

    if(loginResult) {
      //show main content
      res.send('Hello World Again!')
    }else{
      //show error 
    }

})

app.listen(port, () => {
  console.log(`Example app listening on port ${port}`)
})

Day 3

Brix Mavu — Sun, 03 Apr 2022 11:08:29 +0000

Requirements

NodeJS installed

To do

Inside Workspace folder create folder day 3

mkdir day3

Enter day3 folder

cd day3

Running Express

Run commands inside terminal to install express

npm init -y

npm i express

touch app.js

copy and paste Hello World Example
inside app.js file

const express = require('express')
const app = express()
const port = 3000

app.get('/', (req, res) => {
  res.send('Hello World!')
})

app.listen(port, () => {
  console.log(`Example app listening on port ${port}`)
})

Inside your terminal type

node app.js

In browser go localhost:3000

Static Files e.g. html, CSS and JavaScript

Inside day3 folder - create new folder - public

mkdir public

Inside public paste project files from day 2.

Files

index.html

style.css

script.js

Inside app.js remove

app.get('/', (req, res) => {
  res.send('Hello World!')
})

and add

const path = require('path')
app.use('/', express.static(path.join(__dirname, 'public')))

Learn more about express.static

The code should look more like this

const express = require('express')
const path = require('path')

const app = express()
const port = 3000

app.use('/', express.static(path.join(__dirname, 'public')))

app.listen(port, () => {
  console.log(`Example app listening on port ${port}`)
})

Check again localhost:3000

Day 2

Brix Mavu — Fri, 01 Apr 2022 06:03:25 +0000

I will use Scrimba please check out the platform if you want to learn programing interactively.

Biggest reason of using scrimba is it make playing with code easy.

Check the banner to see coding in action

Day 2 code on Scrimba Code

The Plan

Copy code from day 1

Make login and registration toggle using js

Link *.js page to the index.html file

<script src="./*.js"></script>

Inside *.js file create two functions next() and prev()

The idea is to toggle between login interface and registration interface

By default we see login interface when click event is clicked we see registration interface

Just changing CSS propeties via JavaScript

Currently in style.css
#registration{
   display: none
}
JavaScript will dynamically add css style to #login and #registration
#login{
   display: none
}

#registration{
   display: block
}
The inverse happens when click event is clicked again

JavaScript code to achieve that

function next() {
   document.getElementById('login').style.display = "none";
   document.getElementById('registration').style.display = "block";
}
function prev() {
   document.getElementById('registration').style.display = "none";
   document.getElementById('login').style.display = "block";
}

In index.html we setup for the click event on the event on a new user

anchor tag inside Login form add onclick="next()"

You don't have an account yet? Register Here

anchor tag inside Registration form add onclick="next()"

You have an account already? Login Here

Day 1

Brix Mavu — Thu, 31 Mar 2022 16:18:41 +0000

Create Login and Registration page

Souce code can be found on github

Technologies used

Bash - HTML - CSS - JavaScript

Create a project folder

mkdir project

Enter project folder

cd project

Create project files

touch index.html style.css script.js

From code editor explorer open index.html

Inside index.html file paste Sticky Footer code from mdn github repo

Rearrange code

Add new heading :

100 days of code

Add copyright to footer

© 2022

Add login and registration forms inside index.html file forms

I have added a video check the banner which is audio-less it's due to the fact it got heavy on my PC. I'm using the xbox game bar app on Windows. The focus is to show how I went about my solution in 8 minutes Day 1. Session 1. YouTube

100 Days of Code

Brix Mavu — Thu, 31 Mar 2022 11:48:07 +0000

Please join me on my journey of writing code for 100 days.

As this is to motivate me or someone out there, I will try my best to write simple code.

These are not tutorials, it just my comeback in writing code and showing off 😂 😂 😂 .

Simplicity is the ultimate sophistication. ― Leonardo da Vinci

All the code will be available on github

DEV Community: Brix Mavu

5 Principles of Survival for Software Engineers

5 Principles of Survival for Software Engineers

1. 🔥 Adapt or Perish

🛠️ Survival Action

2. 🧭 Stay Calm Under Pressure

🛠️ Survival Action

3. 💡 Resourcefulness Over Resources

🛠️ Survival Action

4. 🎯 Know Your Core, Never Lose It

🛠️ Survival Action

5. ♾️ Outlast, Outthink, Outlive

🛠️ Survival Action

The Real Tech Stack

How to Choose Tech Decisions That Serve You (And the "This Must Be False" Rule)

1. ARE THEY USEFUL?

2. ARE THEY TESTED?

3. ARE THEY OPEN?

4. ARE THEY HONEST?

5. ARE THEY LIBERATING?

WHAT TECH BELIEFS CAN DO

UPGRADE YOUR TECH BELIEFS

The Point

From Excel to AI: We Were Always Programmers

1. The Full Cycle of Code: From Syntax to Intent

2. Code as Literacy: Profit vs. Necessity

3. Ownership Is the Real Divide (And Yes, Excel is Programming)

4. What Is a Program, Really? (Stop Gatekeeping Localhost)

5. The New Compromise: Intent Over Syntax

Summary: The Syntax-Free Future

What do you think?

The Battle of the Senior Dev: Why AI Gives You Wings But Only If You're Ready to Pilot

1. The Quality of Your Question Decides the Quality of Your Solution

2. Knowing When to Stop Coding Is the Real Skill

3. Stay Calm When Everything’s On Fire

4. Naming Things Is Half the Job

5. Manage Your Energy, Not Just Your Time

💡 So How Does AI Fit Into This?

6. Break Giant Problems Into Tiny Pieces

7. Understanding Human Behavior Is an Engineering Skill

8. Learning to Estimate Work Accurately

9. Write Notes for Future-You

10. Recognizing Patterns Is Where Speed Comes From

11. Know When Not to Reinvent Everything

12. Debugging Through Elimination, Not Guessing

13. Communication Is a Programming Skill

14. Focus on Fundamentals over Frameworks

15. Master Meta-Learning (Learning How to Learn)

Final Thoughts: The Real Upgrade

Getting Started with Hyperswitch, Nodejs, and Express for Payment Processing

Introduction

Requirements

Step 1: Create a "Hello World" Application

Step 2: Connecting to Hyperswitch

Setting Up Termux and Node.js on Android for Web Development

Step 1: Install Termux and Node.js

Step 2: Start Your First Project

Step 3: Writing Your First HTML Page in Vim

Step 4: Serve Your Project Locally

Day 5

Day 4

Edit

Day 3

Requirements

To do

Running Express

Static Files e.g. html, CSS and JavaScript

Day 2

The Plan

JavaScript code to achieve that

Day 1

Create Login and Registration page

Technologies used

100 Days of Code

Countdown