DEV Community: Adam Neves

Week 7 - You're not stuck, you just skipped the basics: Git beyond push

Adam Neves — Mon, 11 Aug 2025 01:39:38 +0000

Before we dive in, I want to apologize for the delay in continuing this series.

I’ve been overloaded with work and handling a lot of demands lately, which has left me with little time to write.

Thanks for your patience, let’s pick up where we left off.

Many people think they know Git because they learned git add, git commit, and git push.

The truth is, that's just the tip of the iceberg.

If you want to stop struggling and start using Git effectively, you need to understand what happens beyond the push.

Branches: much more than “a copy of the code”

A branch is just a pointer to a commit, but it gives you the freedom to work in parallel without messing up main.

Want to create a new feature?

git checkout -b my-feature

Keep branches short and focused, and don’t be afraid to create as many as needed.

Merge and Rebase: same road, different routes

Merge: joins paths and preserves history.

  git checkout main
  git merge my-feature

Rebase: rewrites history as if your work always started from the latest version.

  git checkout my-feature
  git rebase main

Rebase keeps history cleaner but requires caution in shared branches.

Stash: Git’s secret pocket

Started something and need to switch branches without losing work?

stash saves your changes without committing.

git stash
git checkout another-branch
git stash pop

Reflog: the time machine

If you “lost” a commit or reset something by mistake, reflog can save you.

It records everything your HEAD has pointed to.

git reflog
git checkout <hash>

Flow strategies: choose your map

GitHub Flow: simple, great for continuous deployment.
Trunk Based: focuses on integrating quickly, avoiding long-lived branches.
Git Flow: more formal, good for projects with defined release cycles.

The choice depends on the team, delivery pace, and coordination level.

Broken history: now what?

If a problematic commit made it into main, you can:

Revert: creates a new commit undoing changes (git revert).
Reset: deletes commits (dangerous if already pushed).
Cherry-pick: reuse only what’s useful from a lost commit.

In summary

Git is not just about storing code, it’s about telling your project’s story clearly and safely.

Mastering branches, merges, rebases, and tools like stash and reflog will make you much more confident in experimenting and fixing mistakes.

Next time you type git push, remember: that’s just the beginning.

My second week on Woovi: Getting into the swing of things (or almost there)

Adam Neves — Tue, 15 Jul 2025 23:36:37 +0000

A False Sense of Comfort

My second week at Woovi felt calmer. I started delivering more and understood the codebase better, although honestly, I probably understand only 1 percent of what I need.

What’s interesting is that even as things started to fall into place, I realized how much context and depth are still missing. Each day exposes new gaps, unexpected architectural decisions, and subtle product nuances that force you to slow down and truly think.

Growth Beyond Code

A clear pattern emerged: every day, someone taught me something, whether technical or related to soft skills.

At Woovi, everyone seems to have a superpower. Some are masters of communication, others have exceptional technical depth, and some have sharp product instincts that guide big decisions. You start to see how each strength blends into the culture and how these traits build an environment where questioning and debating ideas is not just allowed but expected.

One of the most interesting cultural lessons this week was about how learning is shared. For example, today I learned about eventual consistency, a fundamental concept in distributed systems. It means that while data updates might not be immediately visible everywhere, the system will eventually reach a consistent state. In practice, this forces you to think differently about user experience, error handling, and how to communicate system states clearly to users.

These small technical insights are passed around naturally, in PR comments, quick chats, or even casual messages. They aren't pushed in forced "knowledge sharing" sessions; they emerge as part of daily work.

This also reinforces a crucial point: growth here depends on you actively engaging. If you stay passive, you risk missing valuable lessons hidden in daily interactions.

Workflow Maturity

I noticed a significant evolution in our workflow. In the first few days, things felt a bit chaotic, with processes and responsibilities less defined. By the second week, communication aligned, priorities became clearer, and deliveries started to feel more predictable.

This transition from initial chaos to controlled speed shows that Woovi is constantly iterating. There is no static mindset of “we’ve solved everything.” The culture is shaped around continuous improvement, even in internal processes. Everyone is expected to contribute to refining how we work, not just what we build.

Motivation and Expectation

Watching the team operate at this level is energizing. It pushes you to deliver more, keep improving, and constantly challenge your own limits.

Are we moving toward excellence? For me, the answer is yes. But it’s not the kind of excellence that comes from rigid structure or strict guidelines. It’s an evolving, living excellence that requires self-drive, curiosity, and a willingness to get uncomfortable.

Key Takeaways

Progress can feel fast, but there is always deeper context to uncover.
Learning here is organic and requires proactive behavior.
Process improvements are constant and collective, not accidental.
The culture values questioning and sees discomfort as a growth catalyst.
Technical lessons like eventual consistency show how deep the rabbit hole goes, even in seemingly "simple" features.

Conclusion

The second week was not about settling in. It was about realizing how much there still is to learn, both technically and personally.

The main lesson? Onboarding never truly ends here, and that might be exactly the point.

Week 6 - You're not stuck, you just skipped the basics: What is a real database?

Adam Neves — Thu, 10 Jul 2025 00:37:01 +0000

Most beginners think “database” just means “a place to store data.” But a real relational database is designed to handle way more than that, correctness, consistency, and efficient querying at scale.

Why not just save data anywhere?

When you use a proper SQL database, you get:

ACID properties (Atomicity, Consistency, Isolation, Durability): you don’t want to half-update a payment or lose data after a crash.
Joins: data in the real world is related. Users have orders, orders have products, etc. You can join tables instead of duplicating data everywhere.
Indexes: searching without indexes is like scanning every page of a book to find a word. With indexes (B-Tree or others), you get faster lookups.
Data integrity: foreign keys, constraints, and types prevent accidental or corrupt data.

Normalization vs Denormalization

Normalization reduces duplication and enforces data consistency. You split data into multiple tables and relate them through keys.
Denormalization (often used for performance or analytics) duplicates data intentionally to avoid heavy joins.

Don’t just copy blog diagrams. Ask: Does my data really need to be fully normalized? How will I query it most often? These choices affect both correctness and performance.

ORM vs Manual Queries

ORM (Object-Relational Mapping): abstracts SQL into code objects. Faster to get started, easier migrations, but can hide what's really happening under the hood.
Manual SQL: gives you full control. You see exactly how joins and conditions work, and can fine-tune performance.

Beginners often think ORM is always “better”, it isn't. It depends on your project, team skill, and performance constraints.

How to design healthy data models

Understand your access patterns first. What queries will run most? Where are the bottlenecks likely to appear?
Choose keys carefully (avoid wide composite primary keys if you don’t need them).
Use constraints (unique, foreign keys) to keep your data correct.
Think about indexes from day one, adding them later when you already have millions of rows can be painful.

Your challenge this week:

Go beyond “I just save data somewhere.” Design a small relational schema for a fake app (a simple marketplace), sketch out relationships, and try writing actual SQL joins instead of only relying on your ORM.

Next week: Git Beyond Push: Real Version Control

My First 7 Days at Woovi: Learnings, Surprises, and Open Questions

Adam Neves — Wed, 09 Jul 2025 01:54:54 +0000

Starting at a new company is often romanticized: welcome coffees, a nicely packaged onboarding plan, and a slow ramp-up. My first week at Woovi turned out to be quite the opposite: a fast-paced, pragmatic environment where questioning is not only allowed but expected.

First Impressions

On day one, I realized the culture is heavily biased towards fast delivery and technical autonomy. Instead of following step-by-step tutorials, I was encouraged to explore real repositories, understand actual deployment flows, and challenge architectural decisions.

This breaks the common assumption that onboarding must be 100% guided and “hand-holding.” Here, you’re treated as someone who should contribute from day one, not just passively consume information.

The Fear of Not Being Enough

A hidden part of this experience was the fear of not being enough for the role. I came in wondering if I could really match the expectations, whether I would deliver fast enough, and whether I would truly add value.

Very quickly, I realized there was no way to simply "meet expectations" here. Woovi feels more like a high-level engineering school than a typical company. You could be the most senior engineer out there, and you would still get overwhelmed by the codebase. It’s the result of years of creation, iteration, and continuous learning.

This realization actually eased my anxiety. Instead of obsessing over "being enough," I shifted focus to learning fast and contributing incrementally. The expectation is not perfection on day one. The expectation is to keep moving, questioning, improving, and growing as part of the team.

The codebase will push you out of your comfort zone. But in return, it turns you into a better engineer, faster than any comfortable environment ever could.

Technical Challenges

During the week, I dived into the main stack, Node.js, Koa, TypeScript, GraphQL, Relay and integrations with financial systems like Pix and payment gateways. One surprise was how modular yet unopinionated the architecture is: there’s more room for customization, and fewer rigid patterns.

This requires critical thinking: you can’t just “do it like Google.” You have to weigh real trade-offs, performance vs readability, coupling vs delivery speed.

Team Integration

Most interactions happened asynchronously. Far fewer meetings than I expected. This forces you to write better, whether it’s commits, pull requests, or internal docs, and not rely on endless live clarifications.

Interestingly, this exposed a personal flaw: I underestimated how much poor written communication can slow down a project. If you don’t document well, everyone stops to answer your basic questions.

What I Still Question

Does a loose, self-guided onboarding work for everyone?
How much does full autonomy from day one increase the risk of mistakes or rework?
Does async culture, while efficient, alienate those who prefer real-time discussions?

These questions stuck with me all week. I don’t have final answers yet, but I’m watching closely how this affects long-term alignment and productivity.

Key Takeaways

Writing good documentation is as critical as writing good code.
Questioning architecture is not just tolerated, it’s actively encouraged.
Onboarding doesn’t need to be paternalistic to be effective.
Organizational performance is deeply tied to clear written communication.

My First 2 Days: Building a Centralized Onboarding Flow

During my first two days, I noticed something that might sound paradoxical: everything was documented, yet no one knew exactly how to navigate it.

The documentation was thorough, covering internal APIs, deployment workflows, local setup, and architectural decisions. But each piece was isolated, like having a pile of puzzle pieces with no reference picture.

New engineers often found themselves constantly asking, "In what order should I read these docs?" or "What’s the first thing I should run locally before touching feature X?"

Instead of just consuming the scattered docs and pinging people repeatedly, I decided to start drafting a centralized onboarding flow. The goal was to connect all these pieces into a clear sequence:

What to clone first.
Which scripts to run and in which order.
What services need to be up before running the app.
Where to look for environment configuration and secrets.
Key architectural diagrams to understand before jumping into PRs.

This initiative not only helped me get up to speed faster but also turned into a reusable asset for future newcomers.

It challenged the assumption that "more docs = better onboarding." In reality, structured narrative beats raw volume every time.

By proactively organizing this flow, I ended up learning the system more deeply and reduced the dependency on constant Slack or chat questions. And perhaps more importantly, I started contributing real value on day two instead of just passively absorbing information.

Special Thanks to the Woovi Engineering Team

One thing that stood out immediately and deserves a special mention is the quality of the people here. It genuinely feels like every developer was handpicked, and after experiencing it firsthand, I now understand why the selection process is so demanding and sometimes lengthy.

Everyone I've interacted with acted with an impressive sense of honor and strength, always pushing to help each other, no matter how busy they were. They deeply remember what it felt like to be new in the company, and they step up to assist with patience, without sarcasm or condescension.

I won’t mention names, but to all of you who joined calls with me during this first week, consider this a public tribute. You turned what could have been a chaotic start into an empowering, fast-learning experience.

This reinforced for me that a strong engineering culture isn't just about code quality or architecture; it's built on people who genuinely want each other to succeed.

Conclusion

My first week at Woovi was less about a “cute onboarding” and more about a pragmatic deep dive. I realized that in a team focused on speed and autonomy, the worst mistake is waiting passively for instructions.

If you’re about to join a fast-moving team, here’s a provocation:

Are you ready to swim without a float? Or are you still sitting on the edge, waiting for the manual?

Your Turn

Have you gone through an ultra-fast or hyper-structured onboarding before? What worked best for you? Share your thoughts in the comments.

Week 5 - You're not stuck, you just skipped the basics: Understanding the B-Tree

Adam Neves — Mon, 30 Jun 2025 14:42:22 +0000

When we hear about search algorithms and data structures, we often think of simple binary trees or hash tables. However, in the context of databases and large-scale systems, one structure stands out: the B-Tree. Let's explore what it is, why it matters, and how it impacts the performance of modern databases.

The basics of tree data structures

Trees are hierarchical structures that help organize data in a way that supports efficient lookups, insertions, and deletions. In a binary search tree (BST), each node has at most two children: left for smaller keys and right for larger keys. BSTs are simple but can become unbalanced easily, degrading their performance to linear time in the worst case.

To address this, self-balancing trees were introduced. The AVL tree is a well-known example. It maintains a strict balance condition to ensure that operations remain O(log n). AVL trees work well for in-memory data structures where individual node access is fast.

Introducing the B-Tree

The B-Tree is designed specifically for systems where disk access is a bottleneck. Instead of having only two children, a B-Tree node can have multiple keys and multiple children. This allows it to stay shallow, reducing the number of disk reads required to locate a value.

The "B" in B-Tree does not officially stand for anything, but it is often associated with "balanced" or "Bayer," after Rudolf Bayer, one of its inventors. Unlike AVL trees, which minimize tree height using strict balance conditions, B-Trees are optimized to minimize disk I/O by allowing more keys per node.

How B-Trees work

A B-Tree of order m has the following properties:

Each node can contain a maximum of m - 1 keys and m children.
All leaf nodes appear at the same depth.
All keys within a node are kept in sorted order.
Non-leaf nodes act as separation points, dividing the key space for their children.

When a node exceeds its maximum allowed keys during insertion, it splits into two nodes, and the middle key moves up to the parent node. This splitting ensures that the tree remains balanced while minimizing restructuring.

Why databases rely on B-Trees

Databases store massive amounts of data on disk. Each disk read is orders of magnitude slower than an in-memory operation. B-Trees are ideal because they minimize the number of disk reads required to find or insert data.

Most relational databases (like MySQL, PostgreSQL, and SQLite) use B-Tree or variants (such as B+Tree) for their indexing strategies. These indexes improve query performance by allowing the database to quickly locate rows matching specific conditions without scanning the entire table.

B-Trees vs binary and AVL trees

Binary trees and AVL trees are typically used in memory. They keep the height low but still require many pointer traversals, which are cheap in RAM but costly on disk.
B-Trees, with their wide nodes, reduce height dramatically. This allows a single node read to cover a larger key range, resulting in fewer disk I/O operations.
B+Trees, a variant of B-Trees, store all values in leaf nodes and maintain a linked list between leaves. This further optimizes range queries and sequential scans, which are common in database workloads.

Impact on query performance

Indexes built on B-Trees allow queries to run in logarithmic time rather than linear time. Without an index, a database must scan all rows to satisfy a condition. With a B-Tree index, it can navigate the tree structure and find matching rows with far fewer reads.

This design choice directly affects query latency, resource utilization, and overall database scalability. Choosing the right index and understanding its underlying structure is critical for designing performant database applications.

Final thoughts

While B-Trees might seem like a specialized data structure, they are fundamental to modern storage systems. Understanding them helps developers make better decisions about indexing, query optimization, and system architecture.

By grasping the difference between basic binary trees, self-balancing trees like AVL, and disk-optimized trees like B-Trees, we gain insight into how databases can scale to handle billions of rows without falling apart in terms of performance.

Next time: Git beyond pushing: true version control

Week 4 - You're not stuck, you just skipped the basics: Threads, processes and why your app “freezes”

Adam Neves — Sat, 21 Jun 2025 16:09:57 +0000

Ever clicked a button and your entire app just froze? You're not alone.

Let’s go back to the basics and unpack what’s really happening under the hood.

One thread to rule them all

In the browser, your JavaScript runs in a single thread by default. That means everything from rendering the UI to handling user input to executing your code happens in one sequence. If you block this thread, nothing else happens.

while (true) {
  // infinite loop — UI becomes unresponsive
}

Even animations, clicks, scrolls — they all wait for your code to finish.

Processes vs threads

A process is like a separate app: it has its own memory and runs independently. A thread is a unit of execution inside that process, sharing memory with others.

Modern browsers isolate each tab in its own process for security and stability. But inside each tab, your JS runs in one main thread.

Want more threads? You have to create them manually using Web Workers.

const worker = new Worker("heavy-task.js")

Web Workers don’t share memory. You communicate via messages (postMessage / onmessage). It’s like sending letters — safe, but a bit inconvenient.

Async is not parallel

Just because you write async doesn’t mean the work happens in parallel. JS uses asynchronous callbacks, not native concurrency (unless you go out of your way).

fetch('/data').then(() => {
  console.log('Done')
})
console.log('This runs first')

Here’s what really happens:

fetch() is handed off to a Web API.
Your thread keeps going — no waiting.
When the result is ready, it’s put in a callback queue.
The event loop picks it up when the thread is free.

Enter the event loop

The event loop is a behind-the-scenes mechanism that monitors two things:

the call stack (what's running now)
the callback queue (what’s waiting to run)

If the stack is empty, it picks something from the queue and runs it.

So if you freeze the stack with heavy code, nothing from the queue gets executed.

So why does your app freeze?

Because you didn’t give the event loop a chance to breathe.

Heavy loops, complex calculations, sync XHR, or just too much logic in one go — they all block the thread.

const now = performance.now()
while (performance.now() - now < 2000) {}
alert("UI frozen for 2s")

You can prevent this by:

Breaking work into smaller chunks
Using setTimeout(fn, 0) or requestIdleCallback
Offloading to Web Workers

Bonus curiosity: DOM isn’t thread-safe

Ever wondered why Web Workers can’t touch the DOM?

Because the DOM API isn’t designed for concurrency. It’s not thread-safe, meaning two threads accessing it could break things. That’s why rendering is tied to the main thread.

The basics you skipped

If you understand that:

JS is single-threaded
Async just delays work, it doesn’t parallelize it
The event loop needs space to operate

...then you stop writing code that accidentally sabotages your own UI.

Next time: Search algorithms and data structures: understand the B-Tree

The Skill That Can (Actually) Change Your Career

Adam Neves — Sat, 14 Jun 2025 20:51:40 +0000

You might have years of study, technical experience, certifications, mastery of the latest tools in your field. But if you don’t know how to handle conflict, your professional growth will eventually hit an invisible ceiling.

Yes, conflict. It’s inevitable. At some point, you’ll disagree with someone. You’ll feel disrespected, wronged, overlooked. And more importantly, at some point, you’ll be that person to someone else, even without realizing it.

1. Every Person Is a World

Backgrounds, upbringing, trauma, insecurities, values. No one sees the world the same way. And that doesn’t magically change in the workplace. What changes is how people express (or suppress) those differences.

Expecting everyone to react like you, interpret your words the way you meant, or automatically understand your intentions is a setup for frustration. Most conflict is born from mismatched expectations between people who are, in their own way, trying to do the right thing, just through very different lenses.

2. There Are Multiple Versions of You

You are a different person in the eyes of everyone who interacts with you. One person sees you as reliable, another as distant. Someone thinks you’re arrogant, another thinks you’re just direct. These perceptions depend on their history, context, and what they project onto you.

You can’t fully control how others perceive you, but you can control how you respond. How you deal with someone’s misunderstanding of who you are says more about your maturity than any certificate.

3. Conflict Isn’t the Problem, Avoiding It Is

Conflict itself isn’t the issue. The real problems are the silence afterward, the unresolved tension, the gossip that grows in the absence of honest conversation. When handled well, conflict brings alignment, clarity, and growth.

Avoiding conflict only delays the inevitable explosion, one that you may no longer be able to contain.

A Simple Tip: Be Who You Say You Are

There’s no point in acting like the “good guy” online if you’re a jerk in real life. Your post won’t erase your behavior in meetings. Your storytelling won’t cover up your lack of empathy. People feel it. And reputation spreads.

4. Respect Is the Foundation

Whether in projects, friendships, companies, or families, no real dialogue exists without mutual respect. Respect doesn’t mean agreement; it means acknowledging the other person’s perspective as valid, even when you disagree.

And that requires listening, something that’s becoming rare in a world full of fragile egos and absolute certainties.

5. Assuming Good Intentions Is a Smart Move

This isn’t about being naive. It’s about creating the conditions for resolution. If you assume someone is attacking you, you’ll respond with aggression. But if you assume they might just be having a bad day or misinterpreted something, you leave room for a conversation that builds.

Most people don’t wake up wanting to hurt others. They react to what they’ve lived, and not always in the best way. Understanding that and maintaining your composure is what separates reactive professionals from trustworthy ones.

6. Don’t Turn Your Back on Someone Trying to Resolve a Conflict With You

If someone reaches out to talk, to understand, to make peace, see it as a gesture. They could’ve chosen to ignore you, walk away, or hold a grudge. But they took the harder path: conversation.

If someone is trying to resolve a conflict with you, at the very least, they care enough to want you around.

If you ignore that, dismiss it, or turn your back, you might avoid the discomfort for now. But don’t be surprised if, later, you’re the one trying to reconnect, and they’ve already moved on.

Resolution needs two bridges. If only one side is building, it collapses.

Final Thought: Those Who Handle Conflict Well Grow Where Others Stagnate

Promotions, partnerships, leadership opportunities, all of these hinge on how you handle people, especially in difficult moments. People who avoid conflict sabotage themselves. People who attack impulsively close doors. But those who can listen, name the tension, and seek resolution respectfully build solid reputations.

And reputation, in the long run, matters more than your resume.

One Last Question

Have you ever lost good friends just because they didn’t know how to deal with a conflict?

Maybe they disappeared instead of talking. Maybe they got defensive when all you wanted was to clear the air. Maybe they waited too long, and by the time they tried, you had already let go.

Think about that. And now ask yourself: are you doing the same to someone else?

Week 3 - You're not Stuck - You just skipped the Basics: What Really Happens When You Type a URL?

Adam Neves — Wed, 11 Jun 2025 13:55:27 +0000

You open your browser, type www.example.com, and hit enter. Two seconds later, the site loads. Magic? Not quite. There's a chain of invisible steps happening behind the scenes, and if you're building web apps, it's worth knowing where things can slow down or fail.

This post is part of the "You're not stuck, you just skipped the basics" series.

🧭 Step 1: Your browser needs an IP address

The web doesn’t work with names like example.com. It works with IP addresses like 93.184.216.34. So the first thing your browser does is ask:

“Hey DNS, what’s the IP for this domain?”

DNS (Domain Name System) is basically the phone book of the internet. Your browser sends a DNS request to a DNS resolver (usually your ISP’s or Google’s 8.8.8.8), and it responds with the IP address.

⚠️ Slow DNS equals slow first impression.

🚪 Step 2: Connecting to the server (TCP and Port)

Now that your browser knows the IP, it needs to open a connection. This usually happens over TCP (Transmission Control Protocol). Think of it as establishing a reliable tunnel where both sides agree on the rules.

Also, your request goes to a port, typically port 80 for HTTP or 443 for HTTPS. Ports help the server route your request to the correct service.

📦 Step 3: Sending and receiving packets

The actual data (your GET request, the HTML, the images) travels in packets. A packet is just a small chunk of data with some metadata (like source, destination, and order).

Your request might be broken into 20 or more packets. They can travel different routes across the internet and still arrive in the right order.

Packets can get lost, duplicated, or arrive out of order. TCP handles all of this for you.

⏱️ Latency, response time, and where things get slow

Here’s a breakdown of what can affect the speed of a request:

DNS lookup time, the first network call
TCP handshake, needs a round-trip
TLS handshake (HTTPS), an extra handshake step
Server response time, is your backend fast?
Payload size, big HTML or images means more packets
Client rendering, slow JavaScript kills performance

So if your app feels slow, it might not be your React code. It could be:

A misconfigured DNS
An overloaded backend
A fat payload with 5MB hero images
Or even a CDN edge being too far from the user

🧠 Why should you care?

Understanding this flow gives you better debugging instincts. If a user says “the site is slow,” your mind shouldn’t go straight to blaming React or the database. It might be a DNS cache miss, or maybe the server is in Europe and your user is in Brazil.

Next week, we’ll dive deeper into HTTP itself, including headers, methods, caching, and how to avoid breaking the internet.

Follow the series:

Week 1: What does a CPU actually do?
Week 2: Essential Memory
Week 3: (You’re here) What happens when you type a URL
Week 4: (coming soon...)

How I Validated My MVP Without Investing Any Cents On It Using Cloudflared Tunnel

Adam Neves — Tue, 10 Jun 2025 21:08:11 +0000

Use your own machine to validate your MVP

When you're bootstrapping a project or simply want to validate an MVP without burning cash on infrastructure, most MVPs don't need a VPS. I just needed a URL I could share, fast. That’s exactly what I did to get DevScout online and test the MVP.

In this article, I’ll explain how I used my own computer as a server, combined with Cloudflare Tunnel, to make the app publicly accessible, allowing me to test everything end-to-end, gather feedback, and only later invest in a proper VPS.

Why Not Just Pay for a VPS?

Simple: I didn’t want to spend money before proving the idea had potential.

Even cheap VPS options can be overkill when you're still building and validating your minimum viable product. And for side projects or personal experiments, using your own machine with a tunnel can be enough to simulate a real deployment environment.

Tools I Used

My local machine (MacBook Pro M1 16 GB RAM)
Cloudflare Tunnel (cloudflared)
Python Flask API / Next.js app (DevScout)
Local database (SQLite initially, after i changed to PostgreSQL)

Step-by-Step: Exposing My Local App

1. Install Cloudflare CLI

brew install cloudflared

Or follow the official installation guide.

2. Authenticate with Cloudflare

cloudflared login

This opens your browser and asks you to select a domain from your Cloudflare account.

Note: You need to have your own domain added to Cloudflare.

3. Create a Tunnel

cloudflared tunnel create devscout

This creates a new named tunnel and registers its credentials.

4. Configure the Tunnel

Create a configuration file:

# ~/.cloudflared/config.yml
tunnel: devscout
credentials-file: /Users/yourname/.cloudflared/devscout.json

ingress:
  - hostname: devscout.example.com
    service: http://localhost:3000
  - service: http_status:404

Make sure your local app (e.g. Next.js) is running on port 3000.

5. Route the Tunnel

cloudflared tunnel route dns devscout devscout.example.com

This connects the subdomain to the tunnel.

6. Start the Tunnel

cloudflared tunnel run devscout

Done, your local app is now live at https://devscout.example.com.

Why It Worked for Me

Running the MVP this way gave me:

A public URL I could share
HTTPS without extra setup
A real-world way to test and iterate
Zero cost hosting (since the app runs on my machine)

This allowed me to test assumptions, collect feedback, and confirm that the core idea behind DevScout made sense, all before spending anything on cloud infrastructure.

How Cloudflare Tunnel Works (Technical Overview)

Cloudflare Tunnel (formerly Argo Tunnel) provides a secure way to expose services running locally on your machine or network, without having to open ports or configure NAT on your router.

🔒 No Open Ports

One of the biggest advantages is that you don’t need to expose your ports to the public internet. Instead, cloudflared creates an outbound-only connection from your machine to Cloudflare’s edge.

Traditional setup: Public Internet ➝ Open port ➝ Your server
Tunnel setup: Your server ➝ Encrypted tunnel ➝ Cloudflare edge

Since the connection is outbound, it works even behind NAT, CGNAT, or firewalls that block incoming traffic.

🔁 Persistent Connection to the Cloudflare Edge

When you run cloudflared tunnel run, your machine initiates one or more persistent WebSocket connections to Cloudflare's global edge network.

These connections:

Are encrypted (TLS)
Use HTTP/2 multiplexing
Are load-balanced automatically across multiple connections for reliability
Support automatic reconnection and failover

By default, cloudflared opens four parallel connections to different Cloudflare data centers. This gives global reach and resilience.

🛡️ Authentication and Identity

Every tunnel is uniquely associated with a Cloudflare account and zone (domain).

When you run cloudflared login, a signed token is stored locally (e.g. ~/.cloudflared/cert.pem)
When you create a tunnel (cloudflared tunnel create), credentials are stored in a .json file
Only machines with that credential file can start that specific tunnel

This prevents unauthorized access, and you can revoke credentials or delete tunnels at any time via the Cloudflare dashboard.

🌍 DNS Integration

Cloudflare updates your DNS records to proxy traffic through the tunnel, rather than pointing directly to an IP address.

That means:

Now I had https://devscout.app live, and recruiters could actually test the platform.
It automatically uses HTTPS (thanks to Cloudflare’s SSL termination)
I didn’t need it for DevScout yet, but Cloudflare Access lets you lock it down with login or IP rules.

🧩 Behind the Scenes Flow

Let’s break down the actual request flow:

User hits https://devscout.example.com
Cloudflare resolves the domain and routes it to the tunnel
Cloudflare edge sends the request over one of the persistent connections to cloudflared running on your machine
Your local app responds
The response is sent back over the tunnel to Cloudflare, and then to the user

🧠 Bonus: Multiplexing and Load Balancing

Each cloudflared process can:

Handle multiple services (via config.yml)
Load-balance across multiple origins if needed
Run as a system service (daemon mode)
Be monitored/logged using standard tools

If you want to scale it beyond your machine later, you can also connect multiple origins to the same tunnel for zero-downtime rollouts or blue-green deployments.

Why This Matters

Understanding how Cloudflare Tunnel works helps you:

Trust it as a production-grade tool, not a dev-only hack
Use its advanced features (like Zero Trust access)
Know exactly how your traffic flows, which helps with debugging and performance

Running everything locally wasn’t perfect, but it unblocked me. DevScout got real users and feedback, and that’s all I needed to justify the next step.

DevScout – Automated Job Search Platform Connecting you between Tech Recruiters

Week 2 – You’re Not Stuck - You Just Skipped the Basics: Essential Memory

Adam Neves — Tue, 03 Jun 2025 14:17:09 +0000

Hello, dev community! 👋

We’re back with our series “You’re Not Stuck - You Just Skipped the Basics”. After exploring the CPU in Week 1, the brain of your program, today we’re diving into another fundamental concept every developer needs to master to truly level up: memory.

Every piece of code we write, every variable we declare, every object we create, they all live in and interact with the computer’s memory. Ignoring how memory works is like trying to build a house without understanding the ground it stands on.

In this post, we’ll break down the essential memory concepts that directly impact the performance, robustness, and behavior of your code.

What Is Memory and Why Does Your Code Depend on It?

Think of RAM (Random Access Memory) as your computer’s temporary workspace while a program is running. It’s where data is stored that the processor needs quick access to in order to execute your instructions.

Your code depends on memory because it’s where everything happens during execution:

The actual instructions of your program are loaded into memory.
Variables store their values in memory.
Data structures (lists, arrays, objects, etc.) are built in memory.
Function calls and execution state are managed in memory.

Without memory, there’s no space for your program to exist or operate. Understanding this dependency is the first step toward writing more conscious and efficient code.

Stack vs. Heap: The Two Main Memory Areas

When your program runs, it primarily uses two distinct memory areas: the Stack and the Heap.

Stack:

Works like a LIFO (Last-In, First-Out) stack.
Used to store fixed-size and known-at-compile-time data, such as local variables (primitives in many languages) and function call metadata (return addresses, arguments, etc.).
Extremely fast allocation/deallocation, since it only involves moving the stack pointer up or down.
Each thread typically has its own stack.
Has a limited size and can cause a stack overflow if too many nested function calls or large variables are allocated.

Heap:

A larger and more flexible memory area.
Used for data whose size is not known at compile time, or that needs a longer lifespan than the current function scope. Dynamically created objects (new, malloc, etc.) usually go to the Heap.
Slower allocation than the Stack, as the system must find a suitable memory block.
Deallocation may be manual (C/C++) or automatic (via Garbage Collector).
Shared among all threads (with proper concurrency controls).

Knowing where your data lives (Stack or Heap) helps you understand performance implications and memory management in your code.

Variables, Scope, and Automatic Management (GC)

Variables are symbolic names we give to memory locations that store values. A variable’s scope defines the code region where it’s accessible, and more importantly, its lifetime.

Variables declared inside a function (local scope) usually live on the Stack and are automatically deallocated when the function ends.
Dynamically created objects and the variables referencing them (usually pointers or references) live on the Heap.

In many modern languages (JavaScript, Python, Java, C#, Go, etc.), memory management in the Heap is handled by a Garbage Collector (GC).

The GC automatically tracks which objects in the Heap are still referenced by your program. If an object is no longer referenced, it’s considered "garbage" and the GC will free the memory, making it available for reuse.

GC doesn’t eliminate the need to understand memory, it just changes the type of memory issues you’ll face.

References, Allocation, and Memory Leaks

When you create an object in the Heap, the variable accessing it usually holds a reference to it. Think of a reference as the “address” in memory where the object is stored.

Allocation is the act of reserving a space in memory (Stack or Heap) to store data. Whenever you declare a local variable or create a new object, allocation is happening.

A memory leak occurs when memory that was allocated is not released when it’s no longer needed. This happens when a Heap object continues to be referenced even though your program no longer uses it. The Garbage Collector can only release memory if no references to it remain.

Memory leaks cause your application to consume more and more memory over time, leading to:

Degraded performance: The OS might start swapping memory to disk to compensate for low free RAM.
Instability: Eventually, your app may run out of memory and crash with “Out of Memory” errors.

Understanding how references work and how allocation/deallocation happens (manually or via GC) is critical for identifying and preventing memory leaks.

Conclusion

Memory isn’t just some “low-level” concept that only matters in C or embedded systems. It’s the foundation where all your code operates.

Mastering concepts like Stack vs. Heap, scope-driven lifetimes, and reference-based allocation (and how GC fits into this) gives you a clearer mental model of what your code is actually doing behind the scenes. That empowers you to write more robust, predictable code and debug problems more effectively.

Don’t skip the basics. Next week, we’ll dive into what really happens when you type a URL, and explore the fundamentals of Networking.

Bonus: Types of Memory and Why Access Speed Matters

Memory in a computer isn’t just RAM and that’s it. There are multiple levels of memory, each with different speeds, sizes, and purposes. Understanding this hierarchy helps you reason about performance more deeply.

Common Types of Memory

Registers

Super fast, tiny memory blocks inside the CPU itself. Used to store immediate values during execution.

Examples: EAX, EBX, RAX, RDX — depending on CPU architecture.
L1, L2, L3 Cache

Small memory levels closer to the CPU than RAM. Used to reduce access time to frequently used data.
- L1: fastest but smallest
- L2: mid-size, slower
- L3: largest, but slowest among the caches
RAM (Main Memory)

Where your programs and runtime data live during execution. Much slower than CPU cache, but much larger.
Disk (Swap Space / Virtual Memory)

If RAM is full, the system may use the disk as memory — extremely slow in comparison.

Approximate Memory Access Times

Memory Type	Access Time
Registers	~1 CPU cycle
L1 Cache	~3–4 cycles
L2 Cache	~10–12 cycles
L3 Cache	~30–50 cycles
RAM	~100–150 cycles
SSD (swap)	~10,000+ cycles

A well-optimized program minimizes RAM access and maximizes use of registers and cache — that’s how you make code really fast.

TL;DR

Registers are where your CPU does its thinking — lightning fast but limited.
Memory hierarchy impacts your code’s performance more than you think.
Understanding how data flows from storage to CPU helps you write faster, more efficient code.
This isn’t just for systems programming — even frontend and backend code can suffer from poor memory usage patterns.

You’re building abstractions every day — but those abstractions run on physical memory. Know the terrain, and you'll navigate like a pro.

This post is part of the series "You’re Not Stuck — You Just Skipped the Basics".

Week 1 – You’re Not Stuck - You Just Skipped the Basics: Understanding the CPU

Adam Neves — Fri, 30 May 2025 22:36:55 +0000

If you're a developer working with web frameworks, high-level languages, or even no-code tools, you might think low-level hardware knowledge is irrelevant to you.

But here's the truth:

Understanding how a CPU works gives you superpowers as a developer.

Let me explain why

1. You’re Writing Code That Runs on It

Every line of code you write, whether it’s in Python, JavaScript, or Rust, eventually becomes a set of instructions executed by the CPU.

Knowing how the CPU:

Fetches instructions
Decodes them
Executes and writes results back

...helps you understand how your code actually performs on the machine. It’s not magic, it’s instructions and cycles.

2. Debugging Gets Way Easier

Ever seen performance bottlenecks? Threading issues? Spikes in CPU usage?

If you know:

What a thread really is
How CPU caches work
What context switching means

You’ll be that dev who can debug what others can’t. You'll stop guessing and start profiling like a pro.

3. You’ll Write Faster and More Efficient Code

Understanding:

Instruction cycles
Branch prediction
Memory access latency

…helps you write code that’s not just correct, but fast. Especially in performance-sensitive environments like:

Game development
Backend services
Embedded systems

Even for web apps, understanding the CPU helps when working with animations, image processing, or parsing large data.

4. It’s Not That Hard (Seriously)

You don’t need to be a chip engineer.

A basic grasp of:

What registers, ALU, and control units do
The CPU lifecycle: fetch → decode → execute → write back
How RAM and CPU interact

…is more than enough to level up your intuition.

Final Thoughts

Knowing how a CPU works won’t make you a better typist, but it will make you a better developer.

It connects the dots between what you write and what the machine actually does.

So take a weekend, watch some YouTube videos, read a few docs, maybe mess around with a simulator, and unlock a deeper understanding of the magic box we all depend on.

Got any CPU-related “aha!” moments from your dev journey?

Drop them below, i’d love to hear them!

Honorable mention to Sibelius Seraphini for opening my eyes to this topic and encouraging a deeper understanding of how things really work under the hood.

This post is part of the series "You’re Not Stuck - You Just Skipped the Basics".

Want to Make Money as a Developer? Start Solving Problems Around You

Adam Neves — Tue, 27 May 2025 04:49:34 +0000

How Programmers Can Earn More by Solving Real Problems Around Them

As developers, we're often told that to make money, we need to build the next big startup, land a high-paying job at a tech giant, or become influencers in the dev space. But there's a more grounded, human, and immediate path to financial freedom: look around you and solve real problems.

The Most Profitable Ideas Are Near You

You don’t have to search far. Think about your friends, your family, your neighbors. What frustrates them daily? What tasks do they waste time on? What services do they wish existed but don’t?

These are goldmines for meaningful software. If you can create tools, automations, or even simple websites that improve someone’s day-to-day life, you're not just adding value, you're building something people are often willing to pay for.

Examples of Human-Centered Projects

A local baker struggling with order management? Build a lightweight dashboard for them.
A teacher overwhelmed with grading? Automate it.
Your friend runs a small business and hates dealing with invoices? Create a tool that makes it painless.
Someone in your community needs a way to track donations, requests, or schedules? There’s your next weekend project.

You don't need to scale to a million users. You just need to deeply help 10, 20, or 50 people. And from there, things grow.

Focus on Impact, Not Virality

Instead of chasing trending topics or building for likes, build to make someone’s life better. When you focus on creating genuine impact, money tends to follow, through word-of-mouth, referrals, consulting gigs, and even product sales.

Think Like a Craftsman, Not a Startup Founder

Craftsmen don’t start by raising capital. They start by understanding a real need and building something useful. You can do the same with code. The tools you create don’t need to be flashy, they need to work and solve a pain.

Final Thoughts

You don’t need to wait for your big break. It's already around you, in the lives of people you care about. Start small. Start local. Solve real problems, and the money will follow.

Let your code be in service of people, and in return, it will serve you too.

What small problem around you could you solve with code today?