DEV Community: Haki

Breaking Into Tech Is Apparently Not Rocket Science. Who Knew?

Haki — Wed, 14 Oct 2026 22:52:12 +0000

So many of you want to be able to do cool stuff you see people do, like build websites, games, etc.

But… you’re limited by the idea that it’s incredibly overwhelming and only for intelligent people.

You hear your coursemate say he built a neural network in C back in high school and then think you have no chance of breaking into tech or doing something similar.

While I’m not here to preach AI, I’d have to admit that things have changed a lot since your coursemate was in high school.

The idea was “Who writes better code?” back then. Now, the idea is “Who makes better infrastructural decisions?”

Infrastructural decisions basically mean “What should this software do, and how should it do it?”

That’s it. That’s the developer benchmark for 2026 going forward.

So, if you’re interested in breaking into tech, you have two roads to follow, each preferential.

1.) The deep dive path

If you have the time and the courage, you can watch tutorials, learn what you need to learn, then start building things on your own and using AI as your building partner (tool).

This is my preferred approach because I love coding, I love software development, I love everything software, and even a little hardware.

On this path, you’re taking the longer road that’ll require a lot of consistency and patience.

Start with an overview.
Then maybe a tutorial.
From the tutorial, build hands-on things.
Learn further.
Build even more on your own.
Explore AI tooling, etc.

This path is especially for people who want to be “corporate slaves” (just kidding). I meant people who want to be able to apply for jobs in software companies.

You should understand software systems, design, architecture, etc.

2.) The vibe path

In this case, you don’t care about coding that much. You don’t care about programming. You don’t care much about the things running your system. You just wanna have that system.

This approach is the more enticing one for most people because you can literally create a full website in 30 minutes, which might take the DEEP DIVE path a week or even weeks.

The main advantage is that you ship fast. The main disadvantage is that you ship fast and you mostly ship garbage (or, as we like to call it… slop).

Maybe you’re a business owner who doesn’t wanna pay a developer $700 for a simple inventory system and feels that you want to build the system yourself. Of course you can!

Vibe coding is a term used to describe aggressive agentic development without knowledge of the code. Or at least interest.

But the thing is… like I mentioned earlier, making a system is one thing. Making a reliable and good system is another thing entirely, and most times, it’s very difficult.

So, how can I vibe code and ensure that I don’t produce slop (note: slop refers to AI garbage that has the tendency to break)?

Easy! You learn just the basics.

Want to build a website? Learn the overview of how websites are built: the frontend, the backend, the databases.

So, you end up being the one to tell the AI what to use and do instead of it telling you.

You aren’t learning programming. You’re learning infrastructure.

Here’s the twist

Now, these two paths are clearly very different, BUT here’s the twist.

Both paths are software engineering (if done well).

YESSSSS! So, what are you actually waiting for?

After reading this, you can absolutely create your first website.

Don’t have a laptop? Search Lovable or v0.dev.

Check materials online for learning, etc.

And if you need any help (completely free), I’m always available.

Now go build something. Or become a corporate slave. Your choice.

And if you get stuck, need learning resources, or just need someone to point you in the right direction, my DMs are open. I help for free, so you have absolutely no excuse.

Reach me on WhatsApp : https://wa.me/shellhakii
Or anywhere @shellhaki

QUERY METHOD HAS NOW COME TO HONO

Haki — Mon, 20 Jul 2026 13:13:38 +0000

Hono Just Added Support for the New HTTP QUERY Method — and I Got to Contribute ❤️

A few weeks ago, the new HTTP method QUERY was standardized, making it necessary for frameworks and tooling to begin adopting it.

One thing I love about Hono is how quickly it evolves. Even before official support existed, Hono already made it possible to work with custom HTTP methods. Thanks to the amazing Hono community, I had the opportunity to contribute to adding first-class support for the new QUERY method.

That was a fun contribution to be a part of!

What is the QUERY method?

We’re all familiar with GET and POST, and while you can technically use either for almost anything, HTTP semantics exist for a reason.

GET

GET is used to retrieve data from a server without changing its state. It should not create, update, or delete resources.

One limitation of GET is that it doesn’t have a request body. Any data sent with the request typically has to be included in the URL as query parameters.

For example:

GET /users?name=John&age=25

This means request data becomes part of the URL, which can be inconvenient for larger or more complex queries.

POST

POST is commonly used to send data that may change the server’s state, such as creating or updating resources.

Unlike GET, it supports a request body:

{
"name": "John",
"age": 25
}

However, using POST purely for data retrieval isn’t always semantically correct since it’s generally associated with state-changing operations.

Enter QUERY

The new QUERY method fills this gap.

It allows clients to retrieve data without modifying server state, just like GET, while also allowing a request body. This means complex filters or search payloads can be sent as JSON instead of being encoded into the URL.

In other words:

GET → Read data, no request body
POST → Usually changes server state, supports request body
QUERY → Read data, supports request body

This provides a cleaner and more expressive way to perform complex queries while preserving HTTP semantics.

Hono Supports It

Hono is among the first frameworks to officially support the new QUERY method, continuing its reputation for staying modern and developer-friendly.

I’m also happy that I got to contribute to making that happen.

If you haven’t tried Hono yet, I’d definitely recommend checking it out. It’s fast, lightweight, and a joy to build APIs with.

Happy coding! ❤️

How noise cancellation technology works (without the annoying math)

Haki — Fri, 08 May 2026 19:46:55 +0000

Ever wondered how you’re wearing a modern headphone or EarPod, and suddenly the noise/sounds around you reduce drastically ?Its not magic, it’s a cool technology called noise cancellation and I’ll explain how it works;

So there are two ways this can be achieved;

Passive noise cancellation
Active Noise cancellation (ANC) Passive noise cancellation is simply the use of materials to partially block sound waves, as simple as that. However this method is not very effective, there is a more effective means;
- Active Noise cancellation (ANC) works in a more advanced way, applies methodologies on physics, let me explain properly; Sound is a wave, and that wave has a few properties, such as frequency and direction. ANC exploits this property by first of all analyzing the incoming sound in real time, then process it, and produce an inverse of that sound, in lame terms: If sound go forward, noise cancellation reproduces that same sound but backwards, this causes something called destructive interference. Then noise is partially cancelled. IMPORTANT : The end product of the destructive interference is not 2 different sounds at thesame time, it is one sound produced from the collision of the two opposite sounds.

As easy as that :)

Prompt engineering vs RAG vs Finetuning

Haki — Sun, 03 May 2026 12:00:58 +0000

Before I get started, this is my first blog on this platform, I hope it goes well.

MAIN FOCUS
It’s become a very easy thing to mistake prompt engineering for finetuning, especially the scenario of “when should I use which”, this blog posts explains everything.

Difference between Prompt Engineering and finetuning

Straight to the point!

Prompt engineering essentially changes/tailors the output of the model, FROM the input itself
An example might be
“Give me a dummy list of students and their cgpa in JSON format, the advantage of this is that the result you’re getting is something you expect, not just random or unstructured.
key focus : in prompt engineering, you change the input, NOT the model itself.

While on the other hand…

Finetuning is much broader, in this case, you retrain the model on your own data, directly modifying the model behavior, this can be done in different environments although expensive, eg: google collab (free), hugging face (models and data), or even server/ locally (very expensive). Finetuning is more expensive because it requires very large compute to be performed, depending on the data and model.

When should you use which ?
Use prompt engineering in most cases when you need structured output.
Use finetuning only in extreme cases that you need to modify the model itself

In between these two concepts there’s something called rag (RETRIEVAL AUGMENTED GENERATION)
in this paradigm, you provide search context for the model to respond with, this involves embedding, vectorization and so on.
Mental model: user -> model -> search -> model -> user
This is good for large context based operations

I hope this helps :)