DEV Community: Tawanda Nyahuye

The German Tank Problem: Why You Need UUIDs

Tawanda Nyahuye — Sun, 28 Jun 2026 17:44:35 +0000

In World War II, the Allies had a very expensive question and no good way to answer it: how many tanks is Germany actually building?

The official method was spies, intercepted chatter, and educated guessing. The official method was also, as it turns out, wildly, embarrassingly wrong, intelligence estimates put German tank production at well over a thousand a month.

Then some statisticians showed up and ruined everyone's mystique by doing arithmetic.

See, the Germans were excellent engineers, which is another way of saying they were pathologically organized. Every tank rolled off the line with neatly sequential serial numbers stamped on the gearbox, the chassis, the road wheels, everything. And every time the Allies captured or destroyed a tank, those numbers got written down.

So the statisticians stopped trying to spy on the factories and started reading the serial numbers of the wreckage. If you've captured a handful of tanks and the highest serial number you've seen is m, and you've seen k of them, then the total number produced is roughly:

N ≈ m + (m / k) − 1

The intuition is beautiful and slightly evil: the biggest number you've seen tells you roughly how close you are to the top, and how many you've seen tells you how confident to be about that. The gaps between the serials you do have tell you about the ones you don't.

For one month in 1942, the spies said Germany was making around 1,500 tanks. The statisticians, armed with nothing but captured serial numbers and a formula, said 327. After the war, the actual German production records were recovered.

The real number was 342.

The spies missed by a thousand. The nerds missed by fifteen. Somewhere, a very smug statistician got a medal, and the lesson was carved into the bedrock of intelligence work forever:

Sequential numbers leak. If your serial numbers go 1, 2, 3, 4, anyone who sees a few of them can estimate how many of you exist.

I think about this every single time I look at a URL that says /users/1042.

Your database is the German army

Here's the uncomfortable part. Almost every backend you've ever written is the Wehrmacht, cheerfully stamping sequential serial numbers on everything and then handing them to strangers.

You spin up a Postgres table. The primary key is id SERIAL — auto-incrementing integer, because of course it is, that's the default and it's beautiful and it sorts nicely. User 1 is you. User 2 is your co-founder. User 3 is your mom. Everything is fine.

Then you build the profile page. The route is /users/3. You ship it. You are now a German tank.

Because here is what your competitor, or a bored teenager, or a journalist, or anyone with a browser, can now do. They sign up for your app today and get assigned id = 4,317. They wait a week. They sign up again with a different email and get id = 4,981.

Subtract.

You got 664 signups this week. They didn't breach anything. They didn't hack you. They read your serial numbers, exactly like the Allies read the gearboxes, and your growth rate fell out of the arithmetic. Your "we're crushing it, investors love us" pitch deck just got fact-checked by a stranger with two throwaway emails and the subtraction skills of a nine-year-old.

It gets worse, because IDs leak more than count. They leak order and time:

/invoices/58 on launch day tells the world you have billed exactly 58 times in your company's entire existence.
A support ticket numbered #7 tells your enterprise customer they are, uh, one of your first seven enterprise customers. Inspiring.
Two orders placed a minute apart with IDs 9,000 and 9,003 tell a competitor you process roughly three orders a minute at peak.

And then there's the part the security people care about, which is that sequential IDs aren't just informative, they're guessable. If I can see /api/orders/9000, I can also just... try /api/orders/8999. And 8998. And if your authorization is even slightly lazy, and friend, it is I am now reading other people's orders. This has a name. It's called IDOR (Insecure Direct Object Reference), it's been in the OWASP Top 10 for approximately forever, and it is almost always born the moment someone exposes a sequential primary key to the outside world.

Enter the UUID, wearing a fake moustache

The fix is to stop stamping your serial numbers in order.

A UUID (Universally Unique Identifier) is a 128-bit value that, in its most common form (v4), is essentially random:

f47ac10b-58cc-4372-a567-0e02b2c3d479

Look at that gorgeous nonsense. What's the previous user's ID? You have no idea. What's the next one? No idea. How many users exist? You cannot tell, because there's no sequence to read, no maximum to anchor on, no gaps to measure. The German Tank Problem needs serial numbers in a row. A UUID is a serial number that fell into a wood chipper. The formula has nothing to bite on.

As a bonus, and this is the part that wins over the people who don't care about counting attacks, UUIDs are globally unique without coordination. Two different servers, two different services, an offline mobile client on a plane, can all generate IDs at the same time and never collide. No round-trip to the database to ask "what number am I allowed to use next?" You can generate the ID before the row even exists. For anyone building distributed systems, that property alone is worth the price of admission.

So: random, unguessable, count-hiding, coordination-free. We solved it. Ship it. Close the tab.

Okay, here's where I have to be the annoying friend

Because this idea has a failure mode on each end, and I refuse to write a post that pretends UUIDs are free.

They are not free. A bigint is 8 bytes. A UUID is 16, and if you store it as text like a maniac it's 36. Across a hundred-million-row table with a dozen foreign keys pointing at it, that overhead is not theoretical, it's your storage bill and your RAM.

But the real knife is the index. Your database stores its primary key in a B-tree, which is fastest and tidiest when new values arrive in roughly increasing order, every insert tucks neatly onto the end. A random UUIDv4 arrives like a drunk guest who sits between two people at every table. The database has to constantly split pages, shuffle things around, and re-read cold parts of the index off disk. This is called write amplification and page fragmentation, and it's why someone, somewhere, migrated a high-traffic table to random UUIDs and watched their insert performance fall off a cliff and then wrote a furious blog post about it. (You will read that post right before making the same mistake. It's tradition.)

So we did what engineers always do: we fixed the fix.

UUIDv7 (standardized in 2024) puts a timestamp in the high bits and randomness in the low bits. So IDs trend upward over time — the B-tree is happy again, while still being unguessable and uncountable. You can't subtract two of them to get a signup count. This is, for most apps, the correct default in 2026.
ULIDs do basically the same trick with a friendlier, sortable text encoding.
Snowflake IDs (the Twitter classic) cram a timestamp, a machine ID, and a counter into a compact 64 bits — smaller and sortable, at the cost of leaking a little timing info.

But notice the catch, because it's the whole German Tank Problem sneaking back in the side door: a time-ordered ID still leaks the one thing it's ordered by, time. UUIDv7 won't tell anyone your total user count, but it will whisper roughly when each record was created. That's a much smaller leak than "subtract for the growth rate," but it's not zero. If creation timestamps are sensitive in your domain, even v7 is a partial disrobing. Pick your poison on purpose.

And the sneakiest trap of all: an unguessable ID is not an authorization system. A UUID being hard to guess is not the same as a UUID being protected. If your only defense against me reading someone else's invoice is "well, they'd have to guess a 122-bit random number," you have built a password and called it an ID. UUIDs slam the door on enumeration. They do absolutely nothing if you forget to check whether the person holding the ID is actually allowed to use it. Check your authz. The random ID is the lock; the auth check is the guard. You need both.

So what do you actually do tomorrow

You can't un-stamp the serial numbers on a system you've already shipped, but you fully control two dials, so go set them on purpose:

Stop exposing your primary key. The cleanest move on most teams: keep a boring auto-increment bigint as the internal primary key (your indexes stay fast, your joins stay cheap) and add a separate random external ID — a UUIDv7 — for anything the outside world ever sees. URLs, API responses, invoice numbers. The fast key stays in the basement; the wood-chipper key goes out front.
Default new public-facing IDs to UUIDv7, not v4. You get the count-hiding without setting your write performance on fire. Reach for v4 only when you specifically want zero time signal and don't care about index locality.
Then check your authorization anyway, because the ID was never the security boundary. It just stops people from reading you like a captured gearbox.

The Allies won that particular round of the war with a formula and a pile of serial numbers, because the other side was tidy enough to number everything in order and careless enough to let those numbers be seen.

Don't be tidy where it counts against you. Number your tanks at random.

The statisticians are still out there. They are still very smug. And the next time someone signs up for your app twice in a week just to subtract the IDs, you get to be the insufferable person who already shipped UUIDv7, and is, annoyingly, fine.

DESIGN THINKING SKILLS: What Makes Designers Successful?

Tawanda Nyahuye — Mon, 22 Jun 2026 06:26:00 +0000

People who make great products or services share certain skills. It is not a fancy qualification. It is not natural talent. It is a simple way of thinking called Design Thinking.

It is important to identify these skills so that we can also pick them up.

Why Can't We Just Wing It?

"Why not just build the thing and fix problems later?" A lot of teams do this. Most of them end up with a product that nobody uses.

The difference between a product people love and one that nobody touches is simple. The winning team actually understood the people they were building for. The losing team just guessed.

So What Is Design Thinking?

Design thinking is a way of solving problems that does two things:

It puts the user first, you think about the real people who will use your product, not just your own ideas about them.

It focuses on solutions, instead of spending all your time talking about what is wrong, you spend your time building what could be right. I know this is hard. The normal human instinct when something breaks is to find the person responsible and make it their problem. Design thinking says that is a waste of everyone's time. Find the fix instead.

For example. A company notices its staff avoid using the new internal system. The old way is to scream at employees, threaten them with warnings, make them write reports, or send the classic "please refer to the training manual" email that nobody reads. The design thinking way is to sit with employees, watch them use the system, and find out the main button is hidden on the wrong page. Then you move the button. Simple solution. Real impact.

The thing that makes all of this work is empathy. This means you genuinely care about how other people feel and what they go through. Without this, you are just building things for yourself and hoping others like them.

Design Thinking Framework

The design thinking process can be broken down into three steps:

Explore
Create
Implement

1. Explore — Go and See

This is the step most people skip. It is also the most important one.

Before you build anything, go talk to real people. Watch how they do things today. Ask questions. Listen more than you talk. Ask "why" again and again until you find the real problem hiding under the surface.

You are not trying to prove your idea is right. You are trying to learn something that surprises you. If nothing surprises you, you have not talked to enough people.

2. Create — Try Many Ideas

Most people think this is where design thinking starts. It is not. But this is where the fun begins.

First, write down every idea you have. Even the silly ones. Linus Pauling said the way to get good ideas is to get lots of ideas and throw the bad ones away. So write them all down first.

Then, pick your best ideas and build a rough version of each one. This is called a prototype. It does not have to look good. It just has to be something a real person can try.

A paper drawing is fine. A simple clickable screen is fine. Anything that lets a real human say "I like this" or "this does not make sense" is good enough. As Reid Hoffman said, "If you are not embarrassed by the first version of your product, you've launched too late." You are not trying to get it perfect. You are trying to get feedback fast.

3. Implement — Ship It and Keep Learning

When you finally launch, the work is not done. Watch how people actually use what you built. It will surprise you. Take what you learn and go back to step one.

The best teams never really stop exploring. Every version they ship teaches them something for the next one.

This Is Not Just for Designers

Design thinking is not about colours and fonts. Anyone can use it. A nurse, a teacher, a software developer, a shop owner, if you solve problems for other people, this way of thinking is for you.

The skills are simple: be curious, care about people, try many ideas before picking one, and test before you polish.

Start practising them today. Next time you face a hard problem, do not sit and stare at it. Go talk to the person who has the problem. Build the simplest possible answer. Then learn from what happens.

Is Your AI Assistant Making You a Better Developer, or Just a Faster One?

Tawanda Nyahuye — Fri, 19 Jun 2026 10:57:48 +0000

It's 11 pm. You have been staring at the same bug for three hours. You are tired. You give the whole thing to Codex or Claude and say, "Just fix this".
It gives you a solution. Tests pass. You commit and go to bed.

Did you understand what just fixed your bug?

I have done this, and I am sure most of us have. For me, the problem is not using AI to get unstuck. The problem is that when you do it so often, you stop being able to get yourself unstuck. I am afraid of a situation where one day, you are in an interview, or an outage, or a code review, and there is no AI.

I would also like to assume that for most people, AI handles the boring parts, and you get to focus on the hard thinking, meaning you ship better work in less time. That is real, and it is great.

But there is another version where you are just getting faster at not learning anything.

What do you think? Is Your AI Assistant Making You a Better Developer, or Just a Faster One?

Luck == Opportunity Meets Preparation

Tawanda Nyahuye — Tue, 16 Jun 2026 12:32:41 +0000

There's a line usually pinned on the Roman philosopher Seneca: luck is what happens when preparation meets opportunity. People put it all over social media and like most things on social media, it gets repeated so often that it stops meaning anything.

So let me try to make it mean something again, with a math equation and a football match that happened recently at the latest FIFA World Cup 2026.

The equation nobody writes down

We talk about luck like it's a single mysterious force, either you have it or you don't. But it's not one thing. It's two things multiplied together:

Luck = Preparation × Opportunities

Look at what that multiplication does. If your preparation is zero, it doesn't matter how many opportunities show up, zero times anything is still zero. And if you're the most prepared person alive but you never put yourself in front of a single opportunity, same result. Zero.

The lucky people aren't the ones who got more luck handed to them. They're the ones who kept both numbers high. They got good and they kept showing up to the table where things happen.

Hold that thought. Let's go to Texas.

Japan, the Netherlands, and the 88th minute

On June 14th, 2026, Japan played the Netherlands in their World Cup group opener in Arlington, Texas. On paper it was a mismatch in the most literal, physical sense.

The Netherlands are tall. Van Dijk, Van de Ven, the whole spine of that team is built like a row of wardrobes. Japan are one of the shorter sides in world football, quick, technical, but not the people you'd bet on to win a header. If you were designing a contest specifically to humiliate the Japanese, you'd make it about jumping.

And for most of the night, the script ran exactly as the bodies predicted. The Dutch dominated the run of play, around 60% possession, more passes, more touches in the box, the better expected goals. Van Dijk, a defender, rose for a cross and headed the Netherlands ahead. Later Summerville restored their lead. The Oranje even won the aerial duels comfortably, around 74% of them. The taller, richer, more fancied team was doing exactly what everyone assumed it would.

Then the 89th minute happened. A ball was worked into the box, Koki Ogawa rose at the back of it, and the move ended with Daichi Kamada finishing past a flailing Dutch keeper. 2-2. A point stolen, against giants, right at the death.

(Credit: FIFA)

Now a fun stat that flips the whole story, and the reason this match is actually perfect for what we're about to talk about. You'd assume the dominant Dutch were the ones bombarding the box with crosses. They weren't. Japan attempted more crosses than the Netherlands, 23 to 21. The team that was second-best on possession, second-best on xG, and losing the aerial battle just kept whipping balls into the box anyway, over and over, especially once the subs came on. Most of those crosses went nowhere. And then, in the 89th minute, one of them finally found a head.

So both halves of the truth are true at once, which is what makes it a great story:

They raised their opportunities by crossing it 23 times, and their preparation cashed the one that landed. A team that kept firing balls in long after it looked hopeless, that had drilled what to do when one finally dropped, that hadn't mentally checked out at 2-1 down, that team converted the half-second the universe finally handed them. The volume created the chance; the preparation finished it.

That's the whole equation in one match. Luck = Preparation × Opportunities. Japan cranked both dials, more attempts and the readiness to punish one, and stole a point from a team that, on every other number, beat them.

"Life is a game of numbers" — the other half

Okay, but sometimes you don't have elite preparation yet. Sometimes you're just starting. What then?

Then you turn the other dial: opportunities. You take more shots.

Japan's 23 crosses are a tiny, 90-minute version of this. Stretch the same idea across years and you get the tech world, a graveyard-slash-trophy-room of people who simply refused to stop attempting:

WD-40 — the spray in half the garages on earth, literally means "Water Displacement, 40th attempt." The first thirty-nine formulas failed. Somebody had the patience to label their failures honestly and keep going.
James Dyson built 5,127 prototypes of his bagless vacuum before one worked. Five thousand one hundred and twenty-seven. Read that again. He was wrong 5,126 times in a row, which by any normal emotional standard is a reason to take up gardening instead.
Angry Birds was Rovio's 52nd game. They spent years nearly going bankrupt making 51 things you have never heard of and never will. Game number 52 is the one your aunt has on her phone.

None of these are "luck" in the lottery sense. They're the equation again, just weighted the other way: when each individual attempt has a low chance of landing, you survive by taking more attempts. You buy more lottery tickets in a lottery where skill stacks the odds in your favour over time.

You miss 100% of the shots you don't take. But here's the part the motivational poster leaves off: you also miss most of the shots you do take. That's fine. The whole point is to take enough of them, while getting good enough at them, that the misses become statistically survivable.

"A moving man will surely meet his luck"

This is the line doing laps around the internet right now, and it's basically our equation crushed down into seven words. A moving man will surely meet his luck. It's everywhere, football captions. It spreads because it's true in a very specific, almost boring way: luck travels along roads, and you have to be on the road to get hit by it.

Luck cannot find you in your room. It does not have your home address. It finds you in the meeting you showed up to, the project you actually shipped, the conference you flew to, the cold message you sent, the game you released even though it was your 52nd one. The moving man isn't lucky because the universe likes him. He's lucky because he keeps wandering into the places where luck is standing around looking for someone to bump into.

My favourite proof is Stewart Butterfield, a man so committed to moving that the universe basically had to pay him twice to make him stop.

He set out to build an online game called Game Neverending. The game flopped. But the little photo-sharing tool his team had built inside it became Flickr, which Yahoo bought.
Did he learn his lesson and sit still? Of course not. He went and built another game, Glitch. That one also flopped. But the internal chat tool his team had cobbled together just to talk to each other became Slack — which Salesforce later bought for around $27.7 billion.

Twice he aimed at a target and missed. Twice the act of moving building, shipping, keeping a team in motion, produced the thing that actually mattered, sitting quietly in the corner of his failure. Same energy with Instagram, which started life as a clunky check-in app called Burbn until the founders noticed the only feature anyone used was the photos.

None of these people knew which attempt would land. That's the entire point, you don't get to know. You just keep moving, so that when luck finally comes down the road, you are, in fact, on the road.

The tech hall of accidental fame

Honestly, once you pull this thread, you realise a frankly embarrassing chunk of Silicon Valley is just people who completely failed at their original plan and tripped face-first into a better one. The "visionary founder who knew exactly what they were building" is mostly a story told afterwards, on a podcast, by someone who got lucky and is too polite to admit it.

A quick tour of the graveyard-slash-billionaire-factory:

YouTube was a dating site. The founders registered the domain on Valentine's Day, slapped on the slogan "Tune In, Hook Up," and literally offered women $20 on Craigslist to upload dating videos. Number of videos uploaded: zero. Romance dead, they shrugged, said fine, upload literally anything, and accidentally built the second-biggest website on Earth. The first-ever video was a guy standing at a zoo talking about elephants. Swoon.
Twitter fell out of a podcasting startup. It was born inside Odeo, right as Apple casually rolled iTunes podcasts over the entire industry like a steamroller over a grape. Staring down certain death, the team ran a hackathon, and the dumb little "post what you're doing right now" side-project ate its own parent company. Odeo died so your uncle could argue with strangers about football at 2am.
PayPal was an app for beaming money between Palm Pilots. Yes, the device. Two people had to point their PDAs at each other like wizards casting a spell to send $5. Shockingly, the world did not want to do this. So they tried "what if email, but it's money," and a fintech giant fell out of the side of the failure.
Nintendo — the Mario people, sold playing cards for ~70 years. Before video games, they also tried running a taxi company and, this is genuinely real, a chain of love hotels. The path from hourly-rate rooms to The Legend of Zelda is not a straight line. Nobody's is.

And my personal favourite, pure cosmic comedy: Brian Acton. In 2009 he applied for a job at Twitter and got rejected. Then he applied at Facebook and got rejected there too. His reaction, posted publicly: got denied by Twitter HQ, that's ok, would've been a long commute. He then went and co-founded WhatsApp, which Facebook bought five years later for $19 billion. The company that wouldn't hire him paid nineteen billion dollars for the thing he built because they wouldn't hire him. The man got rejected directly into a yacht. If that isn't "a moving man meets his luck," nothing is.

The pattern under all the jokes is the exact same boring, beautiful equation. None of them knew which attempt would hit. They just kept building, kept shipping, kept pointing Palm Pilots at each other, until something, almost never the thing they were aiming at, finally connected.

The trap on both sides

Here's where I have to be the annoying friend, because this idea has a failure mode on each end.

Crank only preparation and never ship, and you become the person with the perfect, polished, fully-architected app that has zero users because you never put it in front of a single human. Infinite preparation × zero opportunities = zero. You studied for a test you never showed up to.

Crank only volume and skip the preparation, and you become the person who sends 500 lazy job applications, builds 50 half-finished side projects, and pitches the same unbaked idea to everyone, and concludes the world is just unfair when none of it lands. Infinite attempts × near-zero preparation ≈ still basically zero, just louder.

And one more, the sneakiest: don't mistake a survivor's story for a recipe. For every Dyson who attempted 5,127 times and won, there are people who attempted 5,127 times at the wrong thing and quietly went broke, they just don't get a keynote. The equation isn't "suffer long enough and you're owed a win." It's "you control two inputs, your skill and your number of swings, and you cannot control the roll of the dice in between." Stack the inputs. Respect the dice.

So what do you actually do tomorrow

You can't manufacture luck. But luck is the product of two numbers you fully control, so go raise both:

Get genuinely good at one thing — that's your multiplier. Skill is what converts a half-chance into a goal in the 88th minute. Suffer through the reps now so that when the ball comes in, your head's already in the right place.
Put yourself in front of more chances — ship the project, send the message, enter the competition, publish the article you've been sitting on. Every swing is another roll where your preparation gets to do something.

Do both, long enough, and one day something will land and somebody will call you lucky. Smile and let them. You'll know it wasn't luck that showed up, it was you, prepared, standing exactly where the ball was always going to drop.

The short team can out-jump the giants. But only the one that practised the jump.

Now go take your shot. Preferably your 52nd one.

A Love Letter to Survivorship Bias in Tech

Tawanda Nyahuye — Tue, 16 Jun 2026 09:32:49 +0000

How many times have you seen a picture of a plane with red dots posted on the internet without context?

There's a famous story about a statistician named Abraham Wald and a bunch of WWII bombers. The military looked at the planes coming back from combat, mapped where they were riddled with bullet holes, and decided to add armor there. Wald, being the kind of person who ruins meetings by being right, pointed out the obvious thing nobody wanted to hear:

The planes they were looking at came back. The ones hit in the spots with no bullet holes, the engine, the cockpit, were at the bottom of the English Channel, not available for the survey.

Reinforce the parts that aren't shot up. That's where the dead planes got hit.

I think about this story a lot, mostly while reading those blog posts titled "X Habits That Made Me a 10x Engineer."

The entire industry is a returning-plane survey

Here is the uncomfortable thing about software engineering wisdom: almost all of it is collected from the planes that came back.

Successful companies write blog posts. Successful founders do podcast tours. Successful engineers give conference talks with titles like "Scaling to 100 Million Users with Three People and a Dream." The companies that did the exact same things and died do not have a booth at the conference. They are not on the panel. They are in the channel, with the engines.

And yet we keep doing the survey. We stare at the bullet holes on the survivors and go, "Ah, this is where we add armor."

"Netflix uses microservices, so we should too"

You have eleven users. Three of them are your co-founders, and one is your mom.

Netflix runs a globe-spanning streaming empire on hundreds of microservices because they have hundreds of teams, billions in revenue, and problems you will be lucky to have in a decade. You have a Postgres database that is doing just fine, thank you, and a monolith that boots in four seconds.

So naturally, you spend the next eight months splitting your perfectly functional app into 23 microservices, introducing a message queue you don't understand, adding a service mesh to manage the services you didn't need, and now your local dev environment requires 40GB of RAM and a small prayer.

You did what Netflix does! And you will also do what most companies that copied Netflix did, which is quietly migrate back to a monolith in two years and write a blog post about it called "Why We Moved Back to a Monolith." That post will be very popular. It will be read by people who are about to make the same mistake and will not be dissuaded.

The bullet holes are on the survivors. The armor goes where the holes aren't.

"All our best engineers skipped college"

Survivorship bias loves a hiring anecdote.

"Our best people are self-taught, never finished a CS degree, just shipped." Cool. You are describing the four self-taught people you hired and kept. You are not describing the enormous pool of self-taught applicants you rejected, or the ones who flamed out in month two, or the entire category of people who never applied because the job post wanted "10 years of Kubernetes experience" for a technology that is nine years old.

You hired survivors and then concluded that being a survivor is a great predictor of survival. Groundbreaking.

"They don't build software like they used to"

Ah, yes, the legendary robustness of old software. That COBOL system from 1987 that still keeps that one giant corporation afloat. They really knew how to build things back then.

Friend. That COBOL system is the survivor. It is one plane. The skies of 1987 were thick with garbage software that crashed, got cancelled, lost its company, and was mercifully deleted before you were born. Nobody's writing "we don't make 'em like we used to" think-pieces about PayrollSystem_FINAL_v3_actuallyfinal.exe because it was put out of its misery in 1991.

We remember old software fondly for the same reason we remember the planes that landed: the other ones aren't here to interview.

The advice that is secretly just luck wearing a hoodie

The most dangerous survivorship bias is the confident first-person retrospective. It goes like this:

"I never wrote tests. I never used a debugger. I just shipped fast and trusted my gut. And look where I am now."

Yes. Look where you are. You are one data point who happens to be holding a microphone. For every you, there is a graveyard of developers who also never wrote tests, also shipped on vibes, and are now explaining to a very calm room why prod has been down for six hours. They are not at this conference. They are in a Slack channel called #incident-2024 that will never be archived.

The gut-trusting works great right up until it doesn't, and the "doesn't" is invisible because it doesn't get a keynote.

How to actually not be the dumb general

The fix is the whole point of the Wald story, and it's deceptively simple: go looking for the missing planes.

When someone tells you, "Do X, it's why we won," ask the question nobody at the survey wanted to ask:

How many teams did X and lost?

If the trait shows up just as often in the wreckage as in the winners, it didn't cause the winning. Microservices, rewriting in Rust, a four-hour daily standup, unlimited PTO, "we don't do meetings" — run them all through the same filter. The survivors will tell you their habits caused their success. The dead can't tell you their identical habits caused nothing of the sort.

This is why post-mortems are worth more than success stories. A blameless write-up of how something failed is one of the rare documents written from inside the wreckage. It's a transmission from a plane that didn't come back, which makes it the only useful data on the whole map.

Please add the armor where the holes aren't

So go forth. Read the FAANG engineering blog. Admire the architecture diagram with 200 boxes. Feel the pull to adopt all of it.

Then remember that you are surveying returning planes, close the tab, and go ship the boring monolith that your eleven users will actually be served by.

The bullet holes are a trap. The survivors are a biased sample. And the next time someone says "we should do it like Google," you get to be the insufferable person in the meeting who is, annoyingly, correct.

Wald would be proud. Wald would also tell you to write tests.

Authentication vs Authorization (Like I'm 5 years Old)

Tawanda Nyahuye — Sun, 26 Apr 2026 11:26:44 +0000

You are probably wondering why this guy is writing an article on this. Is this some AI slop or what? They keep asking this question in interviews; it is our duty to put it out there and flood the internet with it until everyone easily understands it.

Besides, people have different ways of understanding different concepts. So after reading this article, go out there and write about it in your own words. The internet needs more of that.

The candy store door vs the candy aisle

Authentication is the candy store door. There's a guard at the entrance who checks your ID before letting you in. No ID, no entry. It does not matter how much you want the candy; you need to prove who you are first.

Authorization is the candy aisle. You're inside the store now, but that doesn't mean you can go everywhere. Customers stay in the aisles. The stockroom? Staff only. The manager's office? Don't even think about it. Where you're allowed to go depends on who you are, and that's authorization.

Authentication: Can you get through the door? → prove who you are

Authorization: Which aisles can you walk down? → decided once you're inside

How it actually works in software — JWT

When you log into an app, the server needs a way to remember you without asking for your password on every single click. This is where JSON Web Tokens (JWT) come in.

Think of a JWT as the receipt the guard gives you after checking your ID at the candy store door. Every time you want to grab something off a shelf, you show the receipt, so the staff doesn't need to call the guard again. They check the receipt and know exactly who you are and what you're allowed to pick up.

A JWT has three parts separated by dots:

header.payload.signature

Header → algorithm used to sign it
Payload → user info, roles, expiry
Signature → proof it hasn't been tampered with

The server signs the token when you log in. Every request you make after that carries the token in the header. The server verifies the signature, and if it checks out, it trusts the payload. No database lookup needed on every request. Fast, stateless, and widely used in REST APIs

Authorization in the real world — RBAC

Once a user is authenticated, the system needs to decide what they can do. The most common approach is Role-Based Access Control (RBAC).

Instead of assigning permissions to individual users which gets messy fast, you assign them to roles. Then users are given a role. Back to the candy store: customers can browse the aisles, staff can access the stockroom, and managers can open the safe. Same store, completely different access.

Role    Can read    Can delete
Admin   Yes         Yes
Editor  Yes         No
Viewer  Yes         No

In a JWT, the user's role is often stored right in the payload. So when the server decodes the token, it sees role: admin and knows exactly what that person is allowed to do no extra database call required.

Putting it all together

Here's the full flow in a typical web app:

User logs in with credentials → server verifies → authentication (through the door)
Server issues a signed JWT with the user's role baked in (the receipt)
User sends JWT on every request
Server checks the role in the token → grants or denies access → authorization (which aisle)

Screening Opportunities

Tawanda Nyahuye — Sat, 25 Apr 2026 10:14:48 +0000

The way to get good ideas is to get lots of ideas and throw the bad ones away." — Linus Pauling.

In a world dominated by AI, coming up with ideas is no longer the greatest challenge (“Just prompt it,” they say). The real challenge lies in selecting the right ideas. And I know you’re probably thinking, “What is he on about? I can use AI for that too.”

Join me for a few minutes as I babble about a well-proven framework for idea screening.

Why Is It Important to Use a Proven Framework to Screen Ideas?

I know you’re probably asking yourself, “Why not just follow my gut?” Yeah, about that ... we could learn a thing or two from food. Food goes through your mouth, smells nice, follows your gut, and then comes out as sh*t.

What Is It We Are Talking About?

The process of screening opportunities is all about asking questions, and there are not many. All you have to do is ask these three questions:

Is it REAL?
Can we WIN?
Is it WORTH IT?

Those three bad boys combined form a framework called the Real-Win-Worth (RWW). If we are to combine those three into a Venn diagram in the middle, there is a sweet spot, and that's what they call INNOVATION. Your idea needs to answer those three questions to become a great opportunity.

By the way, I am not smart enough to come up with a framework like that, thanks to George Day.

The Breakdown

Now that we have the questions, let's go one by one, asking each question in detail.

Is it REAL?

The Real Dimension or the People Dimension. Here, you need to determine whether there are real people who can benefit from your so-called great idea. It could be you asking yourself: Would I really benefit from what I want to do? Is it really a problem that I should be solving?

In terms of business opportunities, you need to ask: Is the opportunity real? Does someone out there actually want this? Is there a market for it? How big is that market? Is there a genuine unmet need?

In summary, is there a customer with this problem who is willing to pay to solve it? If the REAL is not making real sense, stop being delulu and reflect right away.

Can we WIN?

The Technical Dimension or the Win Dimension. Here, you need to ask yourself whether you’ve got what it takes. At this stage, managing delusions has to be on another level. You need to honestly assess yourself and take a hard look at the competition. I appreciate my non-technical friends who always approach me with their crap APP ideas. Kudos for not being delulu.

From a business perspective, ask: Can we deliver? Do we have the necessary resources? Can we solve the problem in a technically feasible way? Do we truly believe we have a better solution? And can we build a real competitive advantage?

Is it WORTH IT?

The Business Dimension or the Worth Dimension. Here, you need to ask yourself whether you have the money to do it and, after putting your money into it, whether you’re going to get some money out of it.

From a business perspective, you’re looking at overall viability. Is it worth it? Is it financially viable? That means building a business around it that is both viable and sustainable.

Why Is It Important for Your Opportunity to Answer All Three Questions?

Your idea needs to be balanced across all three aspects. If it scores highly on all three, you may be onto something special. If it falls short in any one of them, you’ll eventually find out. In Japan, they call it a Chindogu.

Chindogu is the art of inventing ingenious yet "un-useless" gadgets designed to solve everyday problems, while actually creating more problems than they solve (Kenji Kawakami).

Have some time to take a look at the Chindogu website. There are examples of ideas that are weak in different dimensions that we have talked about.

Take a look at the following ideas, they are just incredible, aren't they? Truth is, nobody is ever paying for those kinds of solutions.

That’s it for today. Thank you for wasting your time. Let’s not get addicted to AI, alright?

Exploring Connections: How Meeting People Enriched My Master's Journey

Tawanda Nyahuye — Wed, 30 Aug 2023 13:57:37 +0000

I recently completed my 2-year master's degree in Big Data Analytics and I would like to take you on a ride through my experience in the world of Big Data Analytics. This won't be about crunching numbers, and datasets or building machine learning models; it's about the incredible individuals I crossed paths with. The connections that I made along the way and how these connections turned out to be like golden tickets to new perspectives that have had a big impact on my entire life.

Meeting Diverse People: Unlocking Valuable Career Insights

During my learning journey, I met people from all sorts of fields - social sciences, finance, engineering, healthcare, HR, and more. It was like stepping into different universes. Talking to people in social sciences showed me how data and human behavior are connected. The finance people taught me how data fuels financial decisions. Tech-savvy engineers shared ways to solve problems that blew my mind. Healthcare experts proved how data literally saves lives. Chatting with HR professionals helped me to get a backstage pass on how data makes managing people a breeze. Coming from a technical background, honestly, I thought doing such a program was for people with programming and other IT-related skills only. In the end, it was these people from different fields who had an upper hand since for them it was about applying big data skills in their respective fields.

Opening Doors to Future Collaborations

While pursuing this master's, I got to meet professors who taught me different courses and life skills. They were not just names on a list, they were people who shared their wisdom and stories. This wasn't just in class; it was in the real world. These connections are like keys to doors that lead to future collaborations and exciting research opportunities.

The Challenge of Juggling Work and Learning

I will be honest, juggling a full-time job while learning part-time wasn't a walk in the park. It was tough. But guess what? Challenges aren't always bad. They pushed me to my limits and made me sharper. Learning how to manage my time and balance responsibilities turned out to be a skill that's super valuable.

The Payoff: Career Growth and Personal Development

Let's talk about the good stuff. The connections I made with people are like treasures. They've opened up a world of possibilities for my career, especially when it comes to future jobs. Employers love to see a network of diverse connections. And those professors and experts I met? They're like mentors who guide me and help me think outside the box.

Embracing the Challenge: A Transformative Experience

Was it easy? No, it was not. But was it worth it? Absolutely! Balancing work and learning was like a boot camp for my time management and multitasking skills. It might have been challenging, but it was also rewarding. The experience has made me resilient, adaptable, and ready to tackle anything that comes my way.

Consider the Journey: Your Next Big Adventure

If you're wondering whether a Master's in Big Data Analytics is for you, let me tell you, it's more than just a degree. It's a chance to meet incredible people who can shape your future. It's about opening doors to collaborations and research that you might never have imagined. And it's about facing challenges head-on and coming out stronger on the other side. The field of big data is very diverse and it can be applied in any field that you can think of be it soccer, hairdressing, cooking, gardening, and any career that you may think of. I highly recommend doing any master's degree not just Big Data analytics. Pursuing postgraduate programs helps you meet different people from different careers which will help you build valuable connections.

So, here's to meeting people, opening doors, and taking on challenges! My Master's journey has been about more than just data, it's been about growth, connections, and a whole lot of learning. If this journey sounds like your kind of adventure, a Master's in Big Data Analytics or any other postgraduate program might just be the next step you've been looking for. Let's embrace the possibilities together!

Is using AI tools really good for your career?

Tawanda Nyahuye — Wed, 24 May 2023 11:31:12 +0000

Gone are the days when gaining a skill through spending some time learning in order to know stuff separated developers from great developers. In this day and era, your skill to prompt the AI is what makes you a super coder.

In this article I will be rumbling about what I think about the use of AI, is it good for your career (beginners vs experts), and of course the most controversial question (will AI takeover our jobs)

Is AI really good for your career?

Well, it depends. For me AI is a tool that you should use to assist you to do your job not heavily rely on it to do your entire job. Using AI tools like ChatGPT is great if you are in later stages of your career than when you are still a beginner. If you are using AI to do your entire job you should not be having a job (you are just lucky your boss does not know you can be replaced by AI)

Tools like ChatGPT should come in handy when you are stuck with a bug and need a way out. If you are still learning to code you need to avoid abusing the use of such tools for every problem that you will face. This will help you master whatever are learning and help with building your creativity.

I know you are already saying to yourself, "this guy is crazy, ChatGPT was created to do that. If I cannot use it to do that then what is the point of having it?". Well, that actually makes sense and it is supposed to do that. Is having AI doing everything for you good for you though? I do not think so.

I was recently doing my MSc degree the past 2 years and I realized that if ChatGPT had been released before I commenced my MSc degree I would have become an empty head. Considering my levels of laziness, I would have dodged doing all the assignments on my own and that would have costed me all the knowledge that I have now. When you are learning something new you need to limit the use of AI tools, suffer a little bit trying to figure out things on your own.

“There is no growth without pain. No life without suffering.”
― Cynthia Eden, Burn For Me

Will AI takeover our jobs?

That actually depends with the job. Some people have already lost their jobs because of AI but as developers I do not think AI will never be able to replace us. As developers I think we are users of AI therefore we will never be replaced. The worst thing AI will do to us is cut our jobs that is instead of having a team of 10 developers we might end up having a team of 1 10x super coder and god level ChatGPT user.

Though AI might not takeover our jobs, i think we a heading to an AI dystopia. The use of tools like ChatGPT will improve our productivity but ruin our creativity.

A world where an AI tool can generate an entire application for you would be great right? well i dont think so, i believe that suffering makes you a great thinker and being a great thinker makes you creative.

How I became a successful meme account and the benefits it has provided

Tawanda Nyahuye — Fri, 08 Jul 2022 11:00:52 +0000

Originally published on ClickUp

You probably looked at the title and you were like, "huh, this guy calls himself successful?"

Yes, when it comes to memeing, I can beat Elon Musk at this game.

Let's jump straight into it. I have had several people approach me, mostly those who admire my work on Twitter. Most of their questions were:

How did you manage to get quite a number of followers?
How do you manage to get those banger memes?
Are there any benefits to doing this?
Can I have your account when you die?

I then decided, why not write something to answer all the questions and then share it with everyone? In this write-up, I will mainly focus on how I have managed to build my Twitter account and the surprising benefits it has provided.

How did you manage to get quite a number of followers?

Running a meme account on Twitter is not really different from running any other account. You just need to understand the following (not really a standard, but that's what I do and what has worked for me):

1. Admiring others in the game/role model(s)

When I started using Twitter, there were a few accounts that I looked up to, both tech accounts and non-tech accounts. One of the accounts I admired was markdalgleish (who used to post memes). The trick is not just to admire your favorite accounts; notice how they do it; comment; plug your own unfunny tweets in the comment section to get noticed by others (it's low but well it works). Commenting in context with the tweet helps you to get noticed by people who are fans of the tweet author or topic as well as the tweet author. This will probably help you get followed by people who have the same interests as you and most likely the tweet author (yeah, that's the prize you get for being a top fan).

That being said, if you want to be a fellow memer, you know who to idolize.

2. Tricking the Algorithm

Tricking the Twitter algorithm increases your chances of coming up with a banger (Also answers the second question on how to come up with banger tweets). You need to play some games with the Twitter algorithm, that is, know when to post and what to post. In terms of knowing when to post, it depends on your time zone and your audience. Take note of your audience and when they are likely to be active. If you post when the guy who likes your tweets for no reason is asleep, your post will disappear into a sinkhole. Remember, going viral starts with one click, and going viral gives you new followers.

In terms of what to post, you need to pay attention to the trends. Don't post about Linux when Windows is trending, unless of course you are bashing Linux, but remember to include the keyword Windows (be creative). I remember posting the following tweet when Facebook changed its name to Meta.

3. Keep it simple

Don't go too deep. Most of us on Twitter are not that smart and are not slacking off at work to hear you shout about quantum physics.

As a developer, do you breathe while coding?

4. Consistency

What has helped me a lot is being consistent. I post memes and only memes. As a result, the people who follow me do it for the memes, and they will end up staying for the memes. If you post vegan tips today and then post a steak tomorrow, you will scare your audience. Take note that my account posts mostly about technology, and it's very important for me to stick to the topic of technology, as my audience is likely to be a bunch of geeks, nerds, and printer fixers who are not familiar with football. Posting memes about Lionel Messi will probably scare the majority of them. While going viral gives you new followers, being consistent keeps the followers.

How do you manage to get banger memes?

Trick the algorithm.
Be creative.
Understand your audience and post when they are active and post what they like the most.
Use a trending meme template (for example, when Squid Game was trending).

Are there any benefits to doing this?

I post memes for fun, but I get a lot of opportunities that I actually never thought someone who just posts images and videos captioned with silly text would ever get. Some of the opportunities include:

Job opportunities

You are probably thinking of job opportunities to post memes while sitting on a rotating chair somewhere, but no, these are actually opportunities to do with my career, especially software development opportunities. I am not sure how this works, but hey, iris wat iris

Marketing

When it comes to marketing, memers are highly demanded. I get a lot of opportunities to promote different products for several companies (especially startups). There is a high chance you once liked a meme that was part of a promotion and did not even notice it. Usually, with most of these, the company running the promotion gets to post it on their page. Memers just handle the memeing.

Can I have your account when you die?

Building a C# Blazor App with NoSQL and SQL Using HarperDB

Tawanda Nyahuye — Tue, 01 Mar 2022 14:29:13 +0000

This tutorial describes how to use HarperDB Database and Blazor. For this tutorial, we are going to build a simple Blazor .Net Core app using HarperDB. The final source code for this tutorial can be found on this GitHub repository.

What is required to follow along this tutorial

Basic knowledge of C#
Visual studio (in my case I am using Visual Studio 2019)
HarperDB account

Why HarperDB?

HarperDB has an easy to use REST API which supports both SQL and NoSQL. It is very simple to use with a wide range of tutorials, support and documentation in different languages like Python, Javascript and CSharp.

Setting up our HarperDB database

Create your HarperDB account
Go to the HarperDB Studio
Create your Organisation
Create new HarperDB Cloud instance
Create a Schema dev
Create two tables dog and breed and set the hash attr to id

NB: To make it simple, for our pets app we are going to use dogs only

Video tutorial on how to setup your HarperDB cloud

Creating our project

Open Visual Studio
Click: Create a new Project -> Blazor Web Assembly App

Click Next

Name your Project **MyPets** and click Next

Select .Net Core 5 and configurations then click create

Configuring our project

Edit Navigation menu (NavMenu.razor) Let’s edit our MyPets navigation App by opening the NavMenu.razor in the Shared folder. We want to add three options, our Home, Add Pets and lastly the page to Display Pets

Edit the URLs as shown below

<div class="@NavMenuCssClass" @onclick="ToggleNavMenu">
    <ul class="nav flex-column">
        <li class="nav-item px-3">
            <NavLink class="nav-link" href="" Match="NavLinkMatch.All">
                <span class="oi oi-home" aria-hidden="true"></span> Home
            </NavLink>
        </li>
        <li class="nav-item px-3">
            <NavLink class="nav-link" href="AddPet">
                <span class="oi oi-plus" aria-hidden="true"></span> Add Pets
            </NavLink>
        </li>
        <li class="nav-item px-3">
            <NavLink class="nav-link" href="fetchdata">
                <span class="oi oi-list-rich" aria-hidden="true"></span> Display Pets
            </NavLink>
        </li>
    </ul>
</div>

After running the project, our app looks like this

Setting up a Home page Let's rename the SurveyPrompt.razor to HomePage as follows

Change the last line of Index.razor. Index.razor is found under pages as shown above

<SurveyPage Title="How is Blazor working for you?" />

 <HomePage Title="Explore" />

Adding important imports

Open _Imports.razor and add the following imports

@using MyPets
@using MyPets.Shared
@using MyPets.Helpers;
@using System.Text.Json

Create a Pet class to help us pass the object data from DB

Right click your project -> add folder
Name the folder Helpers
Right click Helpers folder and add a new Class
Name it Pet

Add the following code to your pet class

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;

namespace MyPets.Helpers
{
    public class Pet
    {
        public int id { get; set; }
        public string dog_name { get; set; }
        public int breed_id { get; set; }

        public int age { get; set; }
    }
}

NB: To setup your database, DB URL and token can be found in the HarperDB studio account under config tab
To find your DB URL and token:

Login to HarperDB Studio
Click on your instance (if you do not have any instances, click Create New HarperDB Cloud Instance to create a new instance
Click on the config tab
Your HDB URL is the Instance URL
Your Authentication token is the Instance API Auth Header (this user)

Adding pets to our database

We are going to make use of the existing pages created by our default Razor app. Rename Counter.Razor to AddPet.razor in the Pages folder and edit it as shown below:
HTML Section

@page "/AddPet"

<h1>Add a new Dog</h1>
<div class="form-group">
    <input class="form-control" Placeholder="Id" @bind-value="@id"/>
</div>
<div class="form-group">
    <input class="form-control" Placeholder="Dog Name" @bind-value="@dog_name"/>
</div>
<div class="form-group">
    <input class="form-control" Placeholder="BreedID" @bind-value="@breed_id"/>
</div>
<div class="form-group">
    <input class="form-control" Placeholder="Age" @bind-value="@age"/>
</div>
<p>@result</p>
<button class="btn btn-primary" @onclick="AddPets">Add New Pet</button>

C# Code Section

@code {
   //Variables for our inputs
    int id;
    string dog_name;
    int breed_id;
    int age;
    private string result = "";
   //Request and response variables
    HttpRequestMessage requestMessage;
    HttpResponseMessage responseMessage;
    HttpClient http;

    private async void AddPets()
    {
        try
        {
            var postBody = new //our request body
            {

                operation =  "insert",
                schema= "dev",
                table =  "dog",
                records = new[] { new
                {
                    id = id,
                    dog_name = dog_name,
                    breed_id = breed_id,
                    age = age
                    }

                }
            };
            http = new HttpClient();
            requestMessage = new HttpRequestMessage
            {
                Method = HttpMethod.Post,
                RequestUri = new Uri(@"YOUR_HDB_URL_HERE") //DB URl
            };

            requestMessage.Content = JsonContent.Create(postBody);
            http.DefaultRequestHeaders.Add("Authorization", "Basic put_your_token_here");
            responseMessage = await http.SendAsync(requestMessage);
            if (responseMessage.IsSuccessStatusCode)
            {
                result = "New pet added";
            }
        }
        catch (Exception)
        {
            result =responseMessage.ToString();
        }
    }
}

** NB: **To setup your database, DB URL and token can be found in the HarperDB studio account under config tab
To find your DB URL and token:

Login to HarperDB Studio
Click on your instance (if you do not have any instances, click Create New HarperDB Cloud Instance to create a new instance
Click on the config tab
Your HDB URL is the Instance URL
Your Authentication token is the Instance API Auth Header (this user)

Display Pets from the database

Edit the code in FetchData.razor in the Pages folder as shown below

NB: For this section we will use the HarperDB SQL functionality

HTML Section

@page "/fetchdata"

<h1>Dogs</h1>
<p>This section demonstrates fetching data from HarperDB</p>
<p> @result</p>
@if (pets == null) //display nothing when our DB is empty
{
    <p><em>Loading...</em></p>
}
else
{
    <table class="table">
        <thead>
            <tr>
                <th>Id</th>
                <th>Dog Name</th>
                <th>Breed</th>
                <th>Age</th>
                <th>Action</th>
            </tr>
        </thead>
        <tbody>
            @foreach (var pet in pets)
            {
                <tr>
                    <td>@pet.id</td>
                    <td>@pet.dog_name</td>
                    <td>@pet.breed_id</td>
                    <td>@pet.age</td>
               </tr>
            }
        </tbody>
    </table>
}

C# Code Section

@code {
    HttpRequestMessage requestMessage;
    HttpResponseMessage responseMessage;
    HttpClient http;
    List<Pet> pets; //Pets list to store our pets retrieved from the database
    private string result = "";
    protected override async Task OnInitializedAsync() 
    {
        try
        {
            var postBody = new
            {
                operation = "sql",
                sql = "SELECT * FROM dev.dog WHERE 1"
            };
            http = new HttpClient();
            requestMessage = new HttpRequestMessage
            {
                Method = HttpMethod.Post,
                RequestUri = new Uri(@"YOUR_HDB_URL_HERE")
            };
            requestMessage.Content = JsonContent.Create(postBody);
            http.DefaultRequestHeaders.Add("Authorization", "Basic put_your_token_here");
            responseMessage = await http.SendAsync(requestMessage);
            pets = JsonSerializer.Deserialize // for our HTML table
                    <List<Pet>>(await responseMessage.Content.ReadAsStringAsync());
        }
        catch (Exception)
        {
            result = responseMessage.ToString();
        }
    }
}

Test addition and Display functionality

Let's test out what we have so far:
Start your project in Visual Studio

** NB: **To setup your database, DB URL and token can be found in the HarperDB studio account under config tab
To find your DB URL and token:

Login to HarperDB Studio
Click on your instance (if you do not have any instances, click Create New HarperDB Cloud Instance to create a new instance
Click on the config tab
Your HDB URL is the Instance URL
Your Authentication token is the Instance API Auth Header (this user)

Deleting our Pets

We will add the functionality to delete a pet in the display FetchData.razor page
Edit the HTML in FetchData.razor to add the following table data to your HTML page

<td><button class="btn btn-danger" @onclick="() => DeletePet(pet.id)">Delete</button></td>

After adding the line your page should look like the one below

@page "/fetchdata"

<h1>Dogs</h1>
<p>This section demonstrates fetching data from HarperDB</p>
<p> @result</p>
@if (pets == null)
{
    <p><em>Loading...</em></p>
}
else
{
    <table class="table">
        <thead>
            <tr>
                <th>Id</th>
                <th>Dog Name</th>
                <th>Breed</th>
                <th>Age</th>
                <th>Action</th>
            </tr>
        </thead>
        <tbody>
            @foreach (var pet in pets)
            {
                <tr>
                    <td>@pet.id</td>
                    <td>@pet.dog_name</td>
                    <td>@pet.breed_id</td>
                    <td>@pet.age</td>
                    <td><button class="btn btn-danger" @onclick="() => DeletePet(pet.id)">Delete</button></td>
                </tr>
            }
        </tbody>
    </table>
}

Add the following DeletePet() method to your @code section under OnInitializedAsync()

 //Delete a pet 
    private async void DeletePet(int id)
    {

        try
        {
            var postBody = new
            {

                operation =  "delete",
                schema= "dev",
                table =  "dog",
                hash_values= new[] { id }
            };
            http = new HttpClient();
            requestMessage = new HttpRequestMessage
            {
                Method = HttpMethod.Post,
                RequestUri = new Uri(@"YOUR_HDB_URL_HERE")
            };
            requestMessage.Content = JsonContent.Create(postBody);
            http.DefaultRequestHeaders.Add("Authorization", "Basic put_your_token_here");
            responseMessage = await http.SendAsync(requestMessage);
            if (responseMessage.IsSuccessStatusCode)
            {
                result = "Pet has been deleted";
            }
        }
        catch (Exception)
        {
            result =responseMessage.ToString();
        }

    }

Test Deletion

Start your project in Visual Studio
Let’s add another pet

We now have two dogs, test by deleting any of the two

After deleting Bruno we are now left with one dog (Harper) in the database.

Conclusion

This tutorial demonstrated how to create a basic C# Blazor app and how to use HarperDB SQL and NoSQL operations in C#.

The Purpose of the DisplayPets function was to demonstrate how you can communicate with HarperDB SQL operations and provide an example to make it easy to use other SQL operations provided in the HarperDB API.

Finally, the AddPet and DeletePet functions demonstrate how you can add and alter data using HarperDB’s NoSQL operations and to help you get started for any NoSQL reference in HarperDB using C#.

Getting started with a project written by another developer

Tawanda Nyahuye — Fri, 09 Jul 2021 19:25:24 +0000

Lets get into this

I have been there and if you are not a newbie, you have probably been there but if you haven't been there, don't worry you will be there. There will always be a time in your life when you inherit code that was written by another developer. If the developer is smarter than you, that's a problem and if they are not, well that's a huge problem. This is a problem most developers face when they start a new job at a different company.

How did we get here?

Recently I was given a task to maintain a project that was written by another developer using a programming language that I am not familiar with. This article has some few things that helped me get up to speed with this new project as well as explaining these ways in case you encounter the same problem.

You have been given a project written by another Developer. What should you do?

We don't run away from the code, we run the code

Study the programming language used

The first thing you have to do before trying to add functionality to a project written by someone else is to understand the programming language that was used to write the project. Most people say programming languages are the same, learn one and you are good with all of them. I disagree, programming languages are different in terms of syntax but they use the same concepts like , OOP, if statements exception handling etc. Take your time to understand the syntax of the language before you try changing some lines of code in a project and this will save you a lot of time. This applies to all programming languages, Python, JavaScript, PHP, C# etc.

Study the source code

Once you get an understanding of the programming language, take your time to read through the project code. Go through the code as much as you can if possible from line 1 to line n, file 1 to file n. Going through the code thoroughly will help you understand the way the developer structures their code, their commenting style, strength and weaknesses. This will also help you know where to edit when you want to edit any features of the project.

Experiment with the project

Experiment with the project, make a backup then break it and fix it. If you break the project you will suffer, the suffering is necessary because it will help you understand the concepts and technologies used in the project when you are trying to fix the project. This will also help you to understand several modules of the project and their connection.

NB: There are several ways that can help one to get started with a project that was written by another developer but this is what worked for me.