DEV Community: 장지호

Why acing the coding test doesn't stop you from floundering on the job

장지호 — Wed, 29 Jul 2026 13:05:32 +0000

The most common thing a perfect-score candidate hears in their first month is "why did you write it this way?"

Algorithm problems hand you fixed inputs, fixed outputs, and one right answer. Real work hands you requirements that shift under you and several answers that are all defensible. That gap is why the people who clear the interview and the people who do the job well are not always the same set. Hiring managers know this. They keep running coding tests anyway, because nothing cheaper has replaced them.

The test measures baseline problem-solving, not job ability

A coding test checks whether you can take a frozen spec and turn it into correct logic inside a time limit. You have to reason about time complexity, pick a data structure that fits, and catch the edge case that breaks the naive version. Those are real skills, and a developer without them struggles.

The problem is that most of what makes production work hard isn't in there.

The difficulty in production code comes from uncertainty. Figuring out what a line in the spec actually means. Predicting what breaks when you touch legacy code that has been running for four years. Tracing why another team's API behaves differently from its documentation. Nobody writes out the inputs and outputs for you. You have to work out which question to ask before you can answer anything.

Algorithm problems have a correct answer. Production doesn't.

A coding test asks "find the longest subsequence in this array that satisfies the condition." One answer, and a grader that knows it.

Production asks "how do I design this so that when the requirements change in three months, I'm not rewriting it from scratch?" There's no answer, only tradeoffs. Make it extensible and you pay in complexity today. Keep it simple and you accept that you may throw it away later.

You can see the same split in code review. An algorithm problem ends at pass or fail. Production code gets judged on whether a teammate can read it in six months, whether it matches team conventions, whether it has tests. Writing alone for a grader and writing for people who will keep editing your code are different jobs.

Take variable names. In a contest, calling things a, b, and tmp costs you nothing. In production, a meaningless name is a direct bill charged to the next person's debugging time. When you finish a function at work, the question isn't only "is this correct" but "can someone else change this safely." No autograder scores that second one.

Companies keep using them because filtering is expensive

Verifying each applicant's actual ability takes real time. Reading a portfolio takes time. Digging through their past project code takes more. Add a few rounds of interviews and the cost climbs fast.

A coding test is a standardized way to cut a large pile of applicants down quickly. It's not precise, but for screening "does this person have basic logic and can they write code," it's efficient.

There's also fairness, which is harder to dismiss than it sounds. An open-ended interview leaves a lot of room for the interviewer's gut feeling. A fixed problem with automated scoring gives both sides less to argue about. Coding tests survive less because they predict job performance and more because they filter a lot of people cheaply without looking arbitrary.

Preparing for both means splitting them by season, not by day

If you're job hunting, there's no reason to skip coding test prep. Fail the first gate and you never get to show anything else.

Pouring every hour into it and arriving with nothing else is a separate problem.

The balance that actually works: do algorithm practice in concentrated blocks around the interview season. The rest of the time, finish small projects end to end. Ship something. Take a bug report and fix it. Leave a review on someone else's code. That does more for your first six months on the job than another hundred practice problems.

The coding test is the key to the door. What you need in the next room, you prepare separately.

Leaning on it too hard backfires on the hiring side too

If a company keeps cranking up test difficulty to filter harder, it starts rejecting people who would have been strong on the team but don't test well. The reverse happens too: someone trained specifically on contest problems clears the bar and then takes a long time to become useful. Both outcomes cost the company and the candidate.

That's not an argument for dropping coding tests. The usual alternatives have their own holes. Portfolios can be faked or ghostwritten. Take-home assignments get criticized for demanding unpaid hours from people who are already working full time. The workable position is to treat the coding test as one filter among several, and to stop reading its result as a full measure of what someone can do.

More companies now ask candidates to walk through past work instead of doing live coding, or pair the test with a collaboration simulation. That shift comes from the same recognition: trying to catch everything with one instrument wastes time on both sides of the table.

A rocket startup gave up on passenger jets, went after weapons, and raised $90M

장지호 — Sun, 26 Jul 2026 16:33:14 +0000

In May 2025 a rocket lifted off from the Texas desert and burned for 32 seconds. That was the whole flight. It was also the first time anyone had flown a rotating detonation rocket engine on an actual vehicle. Venus Aerospace, the startup behind it, has now closed a $90 million Series B.

Venus was founded in 2020 by Sassie and Andrew Duggleby, who serve as CEO and CTO. The original pitch was a clean hypersonic airliner — something that could cross Mach 5 without the emissions profile of older supersonic designs, putting New York to London inside an hour. The engineering was only half the problem. An airliner like that needs regulators and a market that do not exist yet.

The pivot came right after that test flight. "The moment we flew it, the world came back and said, you have a working RDRE, can you sell it to us," Duggleby said. The buyer that showed up first was not an airline. It was defense — hypersonic weapons and missile propulsion, where a proven engine has immediate value. Venus followed the demand.

Why the engine is different

A conventional rocket engine burns propellant inside a chamber at roughly constant pressure. An RDRE burns it with a detonation wave that travels continuously around an annular channel at supersonic speed. You get more thrust from the same propellant, and the engine itself has fewer moving parts, which helps with both reuse and manufacturing cost.

None of this is a new idea. RDREs have been studied since the 1960s and stayed stuck at the bench-test stage for decades. Flying one is what changed the conversation, and it is what the Series B is really pricing.

Who put money in

Mercury Fund led the round. Lockheed Martin Ventures, MESH, PEAK6, Draper Associates, Starboard Star Venture Capital, and Green Sands Equity all participated. Lockheed showing up on the cap table is the part worth noting — a prime contractor investing directly is a stronger signal about defense adoption than any press release.

The money goes toward two things. First, extending burn time from the current 32 seconds to somewhere between 6 and 15 minutes. Second, a larger test stand in Texas, backed in part by the Texas Space Commission.

The part that stings a little

A company that set out to build a clean airliner found its first real customer in weapons. That is not a cautionary tale so much as how validation works: prove the hardware, and the market decides what it is for. Hypersonic weapons, a replacement for solid rocket motors in missile propulsion, eventually launch vehicles — the road in front of an RDRE looks wider than the one Venus originally mapped out.

Whether it ever gets back to the airliner is a separate question, and probably a slower one.

If You Can't Charge an EV at Home, Is It Still Worth Buying One?

장지호 — Mon, 20 Jul 2026 13:47:12 +0000

The first question that stops most EV shoppers isn't the price or the range. It's one line: "There's no charger where I live." Picture living in an apartment complex in Korea, with no assigned parking spot in the underground garage, where the few spots that do have chargers are always taken. How much does that actually cost you in daily hassle? The honest answer is: it depends more than you'd expect.

Slow and fast chargers aren't built for the same job

Level 2 (AC) chargers are made for places where a car sits for hours, like home or work. DC fast chargers are made for a quick stop during a trip. Comparing the two as if they belong in the same category is where most of the confusion starts.

Level 2 charging usually takes eight hours or more overnight to fill the battery. But it uses time the car would be sitting idle anyway, so it doesn't eat into your day. Plug in before bed, unplug in the morning, done.

DC fast charging is designed to get the battery to around 80% in roughly 30 minutes. That speed comes at a cost: those 30 minutes go entirely to charging and nothing else. A coffee break doesn't always cover it, and it's common to see people just sitting near the charger, waiting. Battery makers also generally agree that charging fast every day wears the battery down faster than relying mostly on Level 2 charging. How much faster depends on the vehicle and the battery chemistry (NCM versus LFP), so it's hard to put a specific number on it here.

The core difference comes down to this: Level 2 charging fits into your routine. Fast charging means clearing out a block of your schedule for it.

Apartment charging has grown on paper, but not always in practice

In Korea, national and local governments have steadily raised the required ratio of EV chargers in new apartment complexes. You can check charger counts by region through the Ministry of Environment's EV charger portal, Korea's official locator site for public and residential chargers, and newer complexes are required to set aside a higher share of charging spots. The catch is that this number only tells you how many chargers exist. It doesn't tell you how many are free when you actually need one.

Older apartment complexes, especially ones where parking was already tight relative to the number of households, are a different story. There might be only a handful of charging spots, and as more residents buy EVs, competition for them grows. Even asking the management office to add chargers usually gets stuck behind electrical capacity upgrades, resident approval, and budget constraints. This varies enormously from one complex to another, so if you're considering a move or a purchase, it's worth calling the management office directly and asking how charging spots are assigned and how long the waitlist runs.

On the other hand, if you live in a newer, larger complex with generous charger allocation, home charging is effectively the default, and most of the friction described here disappears. So the claim "apartment residents find EVs inconvenient" is only half right. What's actually true is that residents of complexes with too few charging spots are the ones who feel it.

What people without home charging actually rely on

People who can't charge at home tend to lean on three options.

Workplace charging, when it exists, works almost as well as charging at home. Plug into a Level 2 charger when you arrive and unplug when you leave, and the battery fills up without cutting into your day. Whether your workplace even has chargers, and whether the spots actually turn over, varies enormously by company and isn't something you control.

There's also public charging: the Level 2 and DC fast chargers found at grocery stores, government buildings, and public parking lots across Korea. You might charge while running errands, or fit a fast-charging stop into a route you're already driving. This doesn't force a separate trip, but it does mean planning your own charging schedule. You need to top up before the battery runs low, and checking charger availability through an app becomes a habit.

The last option is relying entirely on DC fast charging. If there's a fast charger near home or along a route you already drive, and your daily mileage is short, some people get by on one or two fast-charging sessions a week. But looking at what people who take this route actually report, charger location, congestion, and whether the unit is even working all become variables every time. A common complaint: charging turns from a routine task into a hunt for a working charger.

How much this actually bothers you depends on your driving pattern

Under identical conditions, some people drive an EV with no real friction while others stay stressed about it constantly. What separates the two groups is the combination of daily mileage and how accessible charging is.

If your round-trip commute is short and there's at least one reliable charging option near work or home, charging once or twice a week is enough. In that case, the hassle of an occasional fast-charging stop stays manageable.

It's a different story for people who drive long distances every day, or whose routes are unpredictable, like delivery or sales work. Charging plans start intruding on the daily schedule, and if that lines up with when fast chargers get busy, evening rush hour or weekends, you end up waiting in line too. Under these conditions, not having a home charger is likely to feel like real friction in daily life.

Here's my take: not having home charging shouldn't be the single deciding factor on whether to buy an EV. Check your own driving pattern and the charging options you can actually reach first. If you have workplace charging or fast chargers along your regular route, the inconvenience drops to a manageable level. If neither holds up, no matter how much you like the car, there's a good chance your days end up revolving around a charging schedule.

What to check before you buy

Before drawing a conclusion, there's a short list worth checking by hand. Ask your apartment management office how many charging spots exist now and how long the waitlist is. Confirm whether your workplace parking lot has chargers and how they're assigned. Then search directly, through Korea's EV charger locator site or a maps app, for how densely fast and Level 2 chargers cover your regular routes. Only after checking these three things can you actually answer whether an EV is inconvenient for your specific situation. That answer, based on your own routes, is far more accurate than a blanket claim that EVs are always inconvenient or always fine.

When You Start Writing Tests, What Changes Isn't the Code, It's the Fear

장지호 — Sun, 19 Jul 2026 00:30:15 +0000

A developer who has never written a test hesitates at the refactor button. They can't be sure what will break. A developer who has tests behind them hits the same button without flinching. What separates the two isn't skill. It's whether they have a way to check their work. Junior or senior, without that check, people tend to build around the code instead of changing it. A few years of that and you end up with a block nobody dares touch.

Refactoring is scary because there's no way to check your work

With tests, you find out within seconds of a change whether anything broke. Without them, you're stuck clicking through screens by hand, or you skip verification entirely and find out from a production alert. Martin Fowler defines refactoring as changing the structure of code without changing its behavior. There's no good way to prove behavior stayed the same except by running tests before and after and watching for green. Once that check gets cheap, you end up touching code more often. Stuff you used to avoid because it was too scary to touch becomes something you can fix, and technical debt piles up more slowly as a result.

The moment you reproduce a bug, that reproduction is already a regression test

If you write reproduction code before fixing a bug, you get a regression test for free. The usual sequence without tests is: reproduce, find the cause, fix, eyeball the result, close the ticket. Months later someone touches nearby code and reintroduces the exact same bug, with no idea it ever happened before. Turn the reproduction into a test and you record the conditions that triggered the bug, which inputs, which state, in a form the computer can run on its own. Break those conditions again and the test tells you immediately. Keep this up and your test suite starts to read like a history of every incident the team has had. Reading test names and comments beats digging through the commit log for what went wrong last time.

Code that's hard to test is usually code that's badly designed

If testing a single function means spinning up a database connection, calling an external API, and wiring up global state, that's a sign the design had problems long before anyone wrote a test for it. Michael Feathers, in his book Working Effectively with Legacy Code, defines legacy code as code without tests. Flip that around and it also means code that's easy to test is usually well designed. Once you start writing tests, injecting dependencies from outside the function becomes a habit. You hide database calls behind an interface. Anything that changes from run to run, like the current time or a random number, gets passed in as an argument instead of generated internally. What you end up with is more pure functions: same input, same output, every time. This isn't extra work done just to satisfy a test. Code that's easy to test tends to be easy to maintain, so the two pull in the same direction on their own.

Make coverage numbers the goal and testing turns into a burden

A hundred percent coverage doesn't mean your code is safe. Martin Fowler wrote, in a blog post titled Test Coverage, that low coverage is a useful warning sign, but high coverage doesn't prove much (martinfowler.com/bliki/TestCoverage.html). Line coverage only checks whether a line ran at least once. It says nothing about whether you checked the result of running it. Call a function and never assert on its return value, and your coverage number still goes up. So when a team sets coverage as a target, you get more tests that run code without checking anything, which is the opposite of what anyone wanted. Testing implementation details is another common trap. Assert on internal variable values or the order private methods get called, and changing the internals breaks a pile of tests even though the visible behavior never changed. Tests like that don't support refactoring. They punish it, and that undermines the whole point of writing tests in the first place: being able to change code without dread.

So where do you actually start

Don't try to retrofit tests onto an entire existing codebase. Add them to whatever you're touching right now, and whatever bug you're fixing right now. Plans to blanket an old codebase in tests tend to fall apart within a few weeks. It's much less overwhelming to test only what you're already working on: a new function, today's bug, next week's module. When you fix a bug, write the reproduction test before the fix itself, and you get the regression protection described earlier for free. Instead of reporting coverage percentages as a management metric, pull a list of files that change often and files that have actually caused outages, and fill in tests there first. That does more to prevent real incidents. I think tests, in the end, change how you relate to your own code. From the moment you start writing them, refactoring gets less scary. Every bug becomes a record instead of a repeat, and the design keeps getting pushed toward something simpler. But it's worth remembering that the moment you start measuring that tool by a number, it turns into a burden.

Thanks for reading.

Why We Switched From Redis to Valkey (It Wasn't Just About the License)

장지호 — Sat, 18 Jul 2026 08:16:00 +0000

When the migration first came up, everyone assumed it was purely a licensing decision. That part was real, but once we sat down to plan the actual cutover, the decisions that mattered most were somewhere else entirely: cross-AZ traffic costs, whether to turn cluster mode on, and a client library swap we hadn't fully budgeted for.

Valkey is a drop-in replacement for Redis OSS, maintained by the Linux Foundation under a BSD license. It keeps the Redis API compatible while removing the licensing constraints and fork uncertainty that started this whole conversation. Because our existing Redis clusters didn't need major rework to run on it, we could put together an incident response plan quickly instead of redesigning our caching layer from scratch.

Why we turned cluster mode off

The first call we had to make was whether to turn cluster mode on. Splitting data across multiple nodes for horizontal scaling sounds great on paper, but the further you shard, the messier resharding gets. We chose predictable latency and easier debugging over that risk, so cluster mode stayed off. Unless your traffic genuinely needs horizontal scale right now, running a single configuration with fewer failure points is the more realistic option.

Cross-AZ cost was the other half of that decision. Traffic between availability zones isn't free, and aligning the Redis layer within AZ boundaries cuts that cost. Scattering data across AZs with cluster mode on would have made the bill harder to reason about. Keeping it off and managing AZ placement directly kept the math simple.

From ioredis to node-redis: why the code had to change too

The migration plan also included swapping client libraries, from ioredis to node-redis. On paper it looks like a dependency bump, but it actually meant rewriting code and re-testing command compatibility. That's why we rolled it out to dev first before touching production. If something broke after a full library swap in prod, rolling back would have been painful, so we wanted to shrink the blast radius to dev before anything else.

Pinning exact versions mattered for the same reason. Recording something like Redis fork 7.2.4 instead of just "latest" meant we always had a clear rollback point the moment something went wrong. We made sure there was a way back at every step of the migration.

Why we waited for Valkey 9.0

There was one feature we'd been watching before the migration even started: hash field expiration, which shipped in Valkey 9.0. Previously, TTLs could only be set at the key level, which made things awkward whenever a hash mixed short-lived fields with ones meant to persist. According to Valkey's blog post on hash field expiration, you can now set a TTL per field, so different attributes of the same object can share a hash and still expire on their own schedule. That meant we could solve the problem without redesigning our cache structure.

Then AWS announced Valkey 9.0 support for Amazon ElastiCache, and the plan became something we could execute. Per the announcement, pipelined workloads can see throughput gains up to 40%, and the release also brought full-text search and multi-database support in cluster mode. The catch is that client connections can drop mid-upgrade. So before flipping anything on, we made sure dev/beta testing, retry/backoff logic, and monitoring around hash field expiration usage were all in place first. A new feature shipping doesn't mean turning it on immediately. It means checking first whether your system can tolerate the disruption.

The license is what started the migration, but the decisions that actually got it across the line were whether to enable cluster mode, how to cut AZ costs, and in what order to validate the client swap. Those three calls turned out to matter more than Valkey itself.

Thanks for reading.

The Real Point of Code Review Isn't Catching Bugs

장지호 — Wed, 15 Jul 2026 18:53:28 +0000

A thread on Hacker News caught my eye. It traced back to a single line the mathematician and developer Mark Dominus had posted on Mastodon: "I think a lot of people misunderstand the purpose of code review." I nodded along the moment I read it, and then found I couldn't explain why I agreed. So I read the original thread to the end.

Dominus's argument goes like this. A reviewer's job is neither to find bugs nor to certify that the code is bug-free. The real primary goal, he says, is to find code that will be hard to maintain. And that kind of code should be fixed while the original author still remembers it, meaning right now.

Why review falls apart when bug hunting becomes the goal

If you set bug-finding as the goal of review, you're asking the reviewer to prove something that can't be proven. "This PR has no bugs" isn't the kind of claim a single read confirms. If there's a way to confirm it, that's the job of tests or static analysis, not a human scanning a diff. What a person can actually catch is usually shallow, typo-level mistakes. Yet when review starts with "please check there are no bugs," the reviewer can never decide on their own when it's time to hit approve. They skim and approve, or they sink into perfectionism and the review drags on forever. Both endings are bad.

The alternative: did you understand it, or not?

The replacement standard Dominus offers is simple: see if you can understand it, and complain if you can't. The condition for hitting approve shifts away from fully understanding the whole change and toward pointing at the exact line you didn't understand. Two things are different about this definition. You now have a grip on when the review should end. And anyone can say "I don't get why this function is written this way" on the spot, while nobody can confidently stamp "this PR has no bugs."

Once you move the standard this way, the question the review asks changes too. In place of "does this work correctly right now" comes "will someone seeing this code for the first time six months from now have to wrestle with it." Under this redefinition the review comments change as well. Fewer comments say "I think there's a bug here," and more of them point at the line where understanding broke down, like "I don't get why this cache TTL suddenly dropped to three minutes," naming the variable and the line. Put the two frames side by side and the difference is sharper.

	Bug-hunting frame	Understandability frame
Question the reviewer asks	Is there a bug in this code?	Do I understand why this code is written this way?
Stopping condition	None, since the claim can't be proven, so you keep scanning	Clear: approve if you understand it, send it back if you don't
Representative comment	"I think there's a bug here"	"I don't get why this cache TTL dropped to three minutes"
As the code grows	Review becomes a more and more hopeless task	The question stays the same

The reason this redefinition didn't feel foreign is that I'd already been drifting in this direction while running reviews in practice. At a company I used to work at, we used a CODEOWNERS file, and in hindsight it was less a device for asking "who has to confirm this code is bug-free" than one that automatically routed "who understands this code and can own it." On a team I was on, work that took less than three days, like copy edits or UI tweaks, went through code review alone, with no formal spec document. (In Korea it's common to write a planning doc before even small changes get built, so skipping it for small work was itself a deliberate call.) What the reviewer actually checked in those cases was whether it was clear enough to get at a glance. Whether it had bugs came after. When you put up a review request, the first comment usually landed within half a day, and what the reviewer really wrestled with in that half day was why it was written that way. Whether the logic was correct came second. Typos and repeated mistakes got filtered out ahead of time by a pre-commit hook, so the review time a person spent was narrowed to just "do I understand why this is written this way," not the mechanical stuff. At the time I thought of it as habit and nothing more, but after reading Dominus I realized all of it had been pointing the same way. The comment that showed up most in those reviews was "I don't get why this part is needed," not "isn't this a bug."

I checked separately, later, that this practice wasn't some quirk of one team. A 2018 paper, "Modern Code Review: A Case Study at Google", analyzed logs, interviews, and surveys across 25,000 Google developers and 9 million reviews, and it names understandability and maintainability as the "most fundamental reason" review was introduced in the first place. Catching more defects was a side effect that followed. "Expectations regarding code review are not centered around problem solving. Finding defects is welcome but is not the only focus" is the sentence the paper nails down as Finding 1. Google's official code review guide reads the same way. It writes that "the primary purpose of code review is to make sure that the overall code health of the codebase is improving over time," and states that there is no such thing as perfect code, only better code, telling reviewers not to hold up approval in the name of perfection. Google also filters style checks and repeated mistakes with pre-commit hooks, and the review a human does is handled by someone certified with ownership and readability for that code. What my team rigged up with one CODEOWNERS file and a few pre-commit hooks, Google was running at a scale of 25,000 people, with formal badges for ownership and readability certification.

Not everyone agreed with this redefinition

The comment section on the original thread didn't flow into easy agreement. People who work in security, and people who care about test coverage, pushed back that bug hunting is a legitimate part of review too. Vulnerabilities like auth bypass or a missing permission check don't get caught by the feeling that something doesn't make sense. If anything, the more smoothly code reads, the harder its hidden security holes are to see. It's fair pushback. Dominus's redefinition is a default that works broadly across ordinary feature code. It doesn't fit every kind of code unconditionally. For high-risk areas like auth, payments, and permissions, the point is that you have to lay a bug-hunting checklist on top of understandability, not that you should throw bug hunting out. Concretely: for permission-check unit tests, you take a test that only passed with an admin account token and add a case that calls the same admin API with a regular account token, to confirm that the path OWASP calls IDOR and BOLA, poking at someone else's object ID with my token, is actually blocked. For token expiry and reuse scenarios, you check whether a refresh token, once used, is immediately rejected when the same token requests again, meaning whether reuse detection and token rotation are in place. For SAST, a static-analysis tool like Semgrep or CodeQL wires SQL injection and XSS pattern rules into CI, and the checklist item is whether those results get attached automatically as reviewer comments. All three are things that "do I understand it" won't catch, and a test or a tool has to point them out separately. Understandable code and safe code are different axes, and in high-risk areas you have to review both.

AI-written code has no original author to ask

Dominus's timing principle, fix the problem code while the original author still remembers it, stands on an assumption from an era when people wrote most of the code. The assumption that if you ask the author, an answer comes back. But now that agents write a large share of the code, that assumption is the first thing to wobble. Ask Claude Code or Codex "why did you write it this way" and you do get a plausible answer back. It's just that the answer is reasoned up again in that moment, invented, and not something recalled about why this library was chosen back then, or why this exception was caught only here. By the time the PR goes up, the author's memory is already gone. The review starts with no one to ask.

So the understandability standard gets much heavier for AI-written code than for human-written code. With human code, if you couldn't understand it, the last resort was to grab the author and press them. AI-written code has no last resort. If the reviewer, looking only at the code, never manages to understand it, that code stays in the codebase with no one having understood it. Define review as bug hunting and this state passes review clean, because even a bug-hunting eye finds nothing wrong in the surface behavior. Only defining review as understandability lets you catch, at the review stage, the state where the code works correctly now but no one knows why.

This is the same gap I pointed at in an earlier piece. Giving AI write access to files, and trusting an AI's judgment without verifying it, were different problems. Same here. AI already has permission to put up a PR. Hand the job of judging whether that code is understandable to the AI too, and the permission passes fine while the judgment comes in with no one having verified it.

What holds a review up

As long as you treat review as bug hunting, review gets more hopeless the more the code grows. All that piles up is the demand to find more of what can't all be found. Move the standard to understandability and the question stays the same no matter how much the code grows. Understand it, pass it; don't, send it back. Whether a person or an agent wrote it doesn't matter. The reason Dominus's line keeps turning over in my head is that it confirmed, late, that what holds up the act of review was really understanding more than verification.

Why Nigeria's Climate Policy Now Starts in the Kitchen

장지호 — Tue, 14 Jul 2026 23:07:46 +0000

Mention climate targets and most people picture power plants, cars, or factory smokestacks. Almost nobody pictures a kitchen. But in Nigeria right now, the kitchen is sitting right in the middle of climate policy. A civil society group called AGNES (African Group of Negotiators Experts Support) recently pushed the federal government to scale up clean cooking policy, and the original report lists the environment ministry, the National Council on Climate Change, and the power ministry as co-signers. This isn't just a press release. Why the kitchen, of all places?

How a kitchen becomes a climate problem

The answer is in the numbers. About 95% of Nigerian households cook with polluting fuels like firewood, kerosene, or charcoal, while only around 5% use clean fuels like electricity or LPG, according to one study. Zoom out to all of Sub-Saharan Africa and the IEA counts four out of five people still cooking over open fires (IEA clean cooking data). This isn't some backwater exception. It's the daily reality for the vast majority of a continent.

That creates three overlapping problems. Cutting firewood keeps shrinking forests. The soot and methane released during burning are short-lived climate pollutants that add directly to warming. And the people breathing that smoke every day in their own homes pay for it with their health. The IEA estimates household air pollution causes about 3.7 million premature deaths worldwide each year, 815,000 of them in Africa, with 60% of that toll falling on women and children (IEA vision for clean cooking access). The people lighting the fire and the people getting sick from it are the same people, which is why an AGNES official's claim that "this issue touches productivity, education, health, and economic opportunity" doesn't read as exaggeration.

Everyone knows the problem. So why hasn't it changed?

None of this is new. The Nigerian government has run improved-stove distribution programs and LPG conversion campaigns for years, so why do 95% of households still cook the old way? Pull the thread and it's not a technology problem. It's a money and habit problem. LPG stoves cost too much upfront, and the gas supply chain barely reaches past city limits. LPG ownership in rural households sits below 10%, versus more than half in urban ones. On top of that, myths that gas is dangerous or that it changes the taste of food still circulate, so even where the infrastructure exists, a psychological barrier remains (analysis of LPG adoption in Nigeria). Getting a stove into a kitchen for good takes finance, distribution, and trust moving together. Handing out stoves alone was never going to be fast enough.

That's why it makes sense that this latest push also names electric cooking and carbon-market climate finance as tools. The IEA estimates universal clean cooking access across Africa by 2040 would cost about $2 billion a year (IEA Africa report), a figure that lines up with the $2.2 billion in pledges that came out of the first Clean Cooking Summit in 2024. The number looks large on its own, but if swapping wood for gas alone can save hundreds of thousands of lives and a meaningful amount of forest every year, it's not an outsized bill.

The weight of changing a single kitchen

I want to state my own view plainly here. Clean cooking usually gets treated as a footnote on the climate agenda, a symbolic line item near the bottom of the list, and that ordering is wrong. Retrofitting millions of household kitchens saves lives faster and more directly than building a handful of power plants ever could. We tend to picture climate action as sweeping policy and international negotiation, which may be exactly why it feels strange to imagine the solution starting in the most private room in the house.

Early in my own time living alone, I got by on a portable butane burner for a few months, and even that brief, minor discomfort gave me some sense of the weight of cooking over wood smoke every single day. Writing in this lifestyle-and-practical-info space keeps reminding me how much a single small habit can change someone's quality of life, and this story is one more example of that. The next time I revisit this topic, I'll be looking past the summit pledge numbers for the follow-up data: how many stoves actually ended up in how many homes.

Thanks for reading.

95% of Nigerian households still cook over wood. Here's why the kitchen became a climate policy fight

장지호 — Tue, 14 Jul 2026 17:41:03 +0000

When people hear "climate targets," they picture power plants, cars, and factory smokestacks, not kitchens. But in Nigeria right now, the kitchen has landed at the center of climate policy. The civil society coalition AGNES (African Group of Negotiators Experts Support) recently urged the federal government to scale up clean cooking policy, and the original report shows the Ministry of Environment, the National Council on Climate Change (NCCC), and the Ministry of Power all signed on. This is well beyond a symbolic statement. So why the kitchen, of all places?

How a kitchen becomes a climate problem

The answer is in the numbers. Roughly 95% of Nigerian households cook with polluting fuels: firewood, kerosene, charcoal. Only about 5% use clean fuels like electricity or LPG, according to a policy review. Zoom out to sub-Saharan Africa as a whole, and the IEA counts four out of every five people still cooking over open fires (IEA clean cooking data). This isn't some exceptional scene from a handful of remote villages. It's the daily reality for the overwhelming majority of the continent's population.

From there, the damage splits into three branches. Cutting firewood continuously shrinks forests. The soot and methane released during combustion are short-lived climate pollutants that amplify the greenhouse effect. And at the same time, the people breathing in that acrid smoke every day inside their own homes are getting sick. The IEA estimates roughly 3.7 million premature deaths worldwide each year from household air pollution, 815,000 of them in Africa alone, with 60% of that toll falling on women and children (IEA's vision for clean cooking access). The person lighting the fire and the person getting sick from it are the same person. So when an AGNES representative says "this issue touches productivity, education, health, and economic opportunity," it doesn't read as an exaggeration.

Why nothing has changed, even though everyone knows

This problem isn't new, though. Nigeria's government has run improved-cookstove and LPG-conversion campaigns for years, so why does 95% of the country still cook the old way? Dig into the cause, and it isn't a technology problem. It's money and habit. The upfront cost of an LPG stove is a real barrier, and the gas supply network barely extends past city limits. Rural households own LPG stoves at under 10%, while urban households cross 50%. On top of that, myths that gas is dangerous or that it changes the taste of food are still widespread, so even where the infrastructure exists, a psychological barrier remains (analysis of LPG adoption in Nigeria). Finance, distribution, and trust all have to move together before a stove earns a permanent spot in the kitchen. Handing out free stoves alone was never going to move fast enough.

That's why this new push, naming electric cooking and carbon-market climate finance in the same breath, is aimed at the right target. The IEA estimates that reaching universal clean cooking access across Africa by 2040 would take roughly $2 billion a year (IEA's Africa report), and the $2.2 billion pledged at the first Clean Cooking Summit in 2024 lines up with that math. The number looks large in isolation, but if simply switching from wood to gas can save hundreds of thousands of lives and a meaningful stretch of forest every year, it's not an outsized bill.

The weight of changing a single kitchen

I want to state my own read on this plainly. Clean cooking usually gets filed at the bottom of the climate-action list, treated as a symbolic line item, and that ordering is backwards. Retrofitting millions of households' kitchens saves lives faster and more directly than building a few more power plants. We tend to encounter climate action as a story about sweeping policy and international negotiations, so it feels almost strange to consider that the most private room in a house could be where the solution starts.

Early in my own independent living, I got by for a few months on a portable butane burner. Even that brief stretch of smell and inconvenience gave me some sense of the weight of cooking inside wood smoke every single day. Every time I write in this everyday-life category, I'm reminded how much a single small habit can change quality of life, and this story sits on that same line. Next time this topic comes back around, I'll be looking past the summit pledge numbers to find out how many stoves actually made it into real households.

The Fish That Gave Up Its Eyes and Rewired Its Brain

장지호 — Tue, 14 Jul 2026 03:59:56 +0000

When I write blog posts before dawn, I drop my screen brightness to its lowest setting and kill the room lights. At first it was just to stop my eyes from stinging, but after a few nights the typos dropped off and the sentences seemed to hang together better. All I did was lean less on my eyes and more on the feel of my fingers and the rhythm in my head, and even that small shift felt like something inside was getting rearranged. So a study I read recently stuck with me: an animal that has lived without light for tens of thousands of years can have its whole brain rebuilt. It is about the blind Mexican cavefish, Astyanax mexicanus.

Same fish, so why do half of them have no eyes

The Mexican tetra started out as an ordinary sighted freshwater fish living in the rivers and streams above ground. Some populations washed into the limestone caves of eastern Mexico, got stranded there, and over generations in the dark their eyes shrank or vanished entirely. The strange part is that the surface form and the cave form are not separate species. They are the same one. You can breed them in a lab and they share most of their genome. Yet one reads the world with its eyes and the other actively flees from light. That makes this fish a living control group, evidence that evolution can rebuild an entire sensory system without needing eons or a full species split.

Erik Duboué's team at Florida Atlantic University published a study in Science Advances that pushed on exactly this point with a behavior experiment. They dropped surface fish and cavefish into a chamber that flipped between light and dark every five minutes and tracked how they moved. The surface fish went hyperactive in the dark. The cavefish did the reverse, thrashing around when the light came on. A fish with no eyes reacting to light sounds backwards. It is obviously not seeing and dodging. Its whole body has learned to read light as a cue to flee.

The brain does not build new circuits, it reuses the old ones

The real payoff was not the behavior but the brain circuit driving it. When the team looked at neural activity, they found that in a region called the caudal posterior tuberculum, the very neurons that fired in response to darkness in surface fish had flipped to fire in response to light in cavefish. No new bundle of nerves got built. The switch on the existing wiring simply got reversed. That is why the finding matters. It explains how evolution could invert an entire sensory response inside a window that is, biologically speaking, short: instead of building from scratch, it reworked what was already there. Rewiring a house goes a lot faster than framing a new one.

A natural doubt creeps in here. Isn't this just a side effect of the eyes degenerating? The team answered that by crossing surface fish with cavefish and watching the light response show up scrambled in the hybrids. The reaction did not fire at random. It is genetically determined and inherited, which means natural selection picked this trait out. So why would avoiding light get selected for? The cave mouth, where light seeps in, is exactly where predators are likely to gather. The most plausible read is that fish that shied away from light stayed clear of that danger zone and lived. Whether natural selection alone can account for eye loss this fast, repeated independently across separate cave populations, is still debated among biologists. Some argue the slow accumulation of neutral mutations cannot fit the timeline, so this one small fish keeps dragging a much larger evolutionary argument around with it.

A lost sense does not disappear, it relocates

For giving up sight, the cavefish got something back. Studies have shown its lateral line is far more developed than the surface fish's, and taste cells have multiplied across its head. The lateral line senses tiny vibrations and currents in the water, and the cavefish uses it to map walls, food, and other fish in total darkness. The brain did not leave the visual territory sitting empty. It reassigned that processing capacity to touch and taste. Lose one sense and the whole brain does not wither. It reorganizes around whichever senses are left, and this fish shows that with its own body.

That is also why researchers studying the human brain keep an eye on this one. Vertebrates share a lot of their basic neural wiring, so a fish whose brain reorganizes after sensory loss sits on the same axis as a blind person's brain expanding the regions that handle hearing and touch, or a stroke patient's recovery where other regions take over the job of the damaged area. When one sense gets blocked, the brain does not throw up its hands. It funnels its resources into whatever channels remain. The principle looks much the same whether you are a fish or a person.

After reading the article, my habit of writing in the dark before dawn felt a little different. A few weeks of it will not rewire my neurons, but the sensation itself, that deliberately dialing down one channel makes the others scramble to fill the gap, runs in the same direction as this fish's story. Next time the writing stalls, turning the screen darker instead of brighter seems like an experiment with nothing to lose.

Thanks for reading. Yaho

Why Rainbows Appear, and Why They're Always Arched

장지호 — Mon, 13 Jul 2026 18:22:02 +0000

After a heavy summer shower, the air turns unusually clear. The smell of rain rises off the wet asphalt, the clouds break, and sunlight slants down. Look up at the right moment and a rainbow hangs on one side of the sky. Stare at it for a few seconds and the question comes on its own. Where do these bands of color come from?

Rainbows don't show up on demand. The best window is that short stretch before the rain fully stops, when drops are still falling on one side of the sky while the sun is already out on the other. Bigger drops split the colors more strongly, which is why a rainbow right after a downpour looks far more vivid than one in a drizzle. With some luck, you'll also spot a second, fainter bow outside the first.

A rainbow is sunlight split apart by water droplets

Sunlight looks white, but it carries many colors at once. Normally they travel mixed together, so we just see brightness. They only become visible as separate bands when something sends each color down a slightly different path. That something is water droplets floating in the air. Right after a shower, the sky holds countless tiny droplets. Sunlight bends as it enters each one, reflects off the inside, and comes back out, and along the way the colors spread apart. Nothing solid is hanging in the sky. A rainbow is just that split light, gathered by your eyes from one particular direction.

Every droplet works like a tiny prism

When light passes from air into water, or from water back into air, its path bends at the boundary. That bending is called refraction. The catch is that each color bends by a slightly different amount. Reds bend less, blues and violets bend more. So when sunlight enters a droplet, it bends once going in, bounces off the back wall, and bends again coming out, and the colors fan out like a spread of cards. A glass prism does the same thing when it throws a colored band across a table. Every droplet in the sky is a miniature prism, and the rainbow you see is the combined work of a huge number of them.

That's why the sun has to be behind you

You may have heard that you need the sun at your back to see a rainbow. The reason is simple: the light that enters a droplet reflects off the inside and comes back toward you. Sunlight travels from behind you into the droplets, turns around inside them, and returns to your eyes. So a rainbow always appears directly opposite the sun, in the part of the sky your shadow points to. That's also why morning rainbows hang in the western sky and late-afternoon rainbows in the east. Face the sun and you won't see one, no matter how much water is in the air.

The arc exists because color only gathers at one angle

The light coming back out of the droplets doesn't scatter in every direction. It concentrates most strongly at about 42 degrees away from the point directly opposite the sun. Red gathers slightly toward the outside of that angle, violet slightly toward the inside. Connect every point that sits at 42 degrees and you get a circle. The rainbow curves because only the droplets at that exact angle can send color to your eyes. The ground blocks the lower half, so you usually get a semicircle at most. The lower the sun sits, the taller and rounder the arc looks. If the sun climbs higher than 42 degrees above the horizon, the whole arc sinks below it. That's the reason midday rainbows are so rare. From a mountaintop or an airplane window, with nothing in the way, a rainbow can appear as a complete circle.

A double rainbow means the light bounced twice

Sometimes a fainter rainbow appears outside the bright one. That outer bow forms when light reflects twice inside the droplets. The extra reflection pushes the exit angle out to about 51 degrees and flips the color order, so the inner bow is red on the outside while the outer bow is red on the inside. Each reflection costs some light, so the second bow is always dimmer. Between the two bows sits a strip of sky that is noticeably darker, called Alexander's dark band after the Greek philosopher who first described it about 1,800 years ago. Droplets can't send light into the gap between those two angles, so it's a genuine shadow.

Knowing how it all works doesn't make a rainbow any less strange. A rainbow is built around the position of your own eyes, so the person standing next to you is seeing light from a different set of droplets. Under the same sky, each of us is watching our own private rainbow. Maybe that's why we keep looking up at it.

Thanks for reading.

24-bit/192kHz audio: bigger numbers your ears can't hear

장지호 — Sun, 12 Jul 2026 23:48:41 +0000

When a streaming app puts a "Hi-Res" badge on an album, I tap it first without thinking. I used to go further than that. On FLAC download sites I would deliberately pick the files labeled 24bit/192kHz, because they were about six times the size of a CD-quality rip, and bigger obviously meant better. Then I read an article by Monty Montgomery, the audio engineer behind Xiph.Org, and realized I had been paying a storage tax for nothing. His conclusion is blunt: for distribution, 24/192 gets you nothing over CD quality (16bit/44.1kHz). The files are just six times heavier.

Why 44.1kHz is enough

The argument rests on the Nyquist theorem, the same math behind every ADC you've ever touched. Sample a signal at twice its highest frequency and you can reconstruct it perfectly. Human hearing tops out around 20kHz, so 44.1kHz sampling captures the entire audible band. Sampling at 192kHz doesn't make the audible part any sharper. All it adds is content above 20kHz, ultrasound that no one can hear. Montgomery's comparison: the infrared LED in an Apple remote sits about 20% past the edge of visible light, while 192kHz audio reaches 400% of the audible limit. Worse, that ultrasonic content doesn't stay out of the way. Speakers and amps aren't perfectly linear, so ultrasonics intermodulate and spray distortion products back down into the audible band. You store sound nobody can hear, and it can smear the sound everyone can.

Bit depth is the same story. 16-bit PCM gives you 96dB of dynamic range on paper, and with proper dithering that stretches to about 120dB in practice. That's roughly the gap between a mosquito in the same room and a jackhammer a foot away. Nothing you play at home spans it. 24-bit does have a real job: in recording and mixing it's headroom, soaking up the noise that accumulates over thousands of processing passes. That headroom matters in the studio. For the file that ships to listeners, 16 bits is already more than enough.

Even Neil Young couldn't beat the blind test

This isn't only theory. The Boston Audio Society ran controlled listening tests with professional gear in a soundproofed studio, and across 554 trials listeners picked correctly 49.8% of the time. A coin flip. One man bet a company on the opposite result: Neil Young raised over $6 million on Kickstarter in 2014 for Pono, a dedicated 24bit/192kHz player. Journalist David Pogue then ran a blind test with 15 people aged 17 to 55, comparing Pono's FLAC files against AAC-compressed tracks on an iPhone. More listeners preferred the iPhone. Pono shut down in 2017. Young blamed the record labels, but the simpler explanation is that there was never an audible difference to sell.

The retail side of hi-res can be even shakier. A Korean newspaper had 90 tracks sold as 24bit/96kHz on three Korean music stores put through spectrum analysis, and only two actually met the labeled spec (article in Korean). The rest were upsampled from lower-resolution masters, and the reporting pointed at distributors doing the upsampling themselves after receiving plain MP3s and WAVs from the labels. If customers can't hear the difference anyway, nobody in the supply chain has much incentive to make the number real.

The pricing pages caught up

The market has quietly conceded the point. Apple Music made lossless and hi-res free for subscribers in 2021, and Amazon folded its $5-extra HD tier into the base plan the same year. Tidal, which built its brand on selling hi-res as a premium tier, merged everything into a single $10.99 plan in April 2024. And when Spotify finally shipped lossless in September 2025, after teasing a paid "HiFi" tier for years, it capped the format at 24-bit/44.1kHz FLAC and bundled it into regular Premium. Not 192kHz. The pricing pages worked out what the blind tests already showed: hi-res is not something people will pay extra for.

So I stopped paying for big numbers. The same money goes a lot further on better headphones or speakers, or on a well-mastered release. These days I check which mastering a version uses and how hard it's been compressed before I ever look at the sample rate.

That command you just copied can hand over your whole machine

장지호 — Sun, 12 Jul 2026 04:53:52 +0000

I've copied terminal commands straight off the web more times than I can count, usually for blog tooling, a diagram generator, some CLI flag I keep forgetting. I do check the source, whether it's Stack Overflow or a GitHub issue. But when I'm in a hurry, I paste first and read never. It turns out that exact habit is the delivery channel for one of the most troublesome attack techniques in the wild right now.

The fake CAPTCHA is just the opening act

ClickFix attacks start small. A video won't play, or a "verify you are human" check keeps failing, and the error screen helpfully offers a fix: copy this command, open the Run dialog (Windows key + R) or PowerShell, paste it, done. The user just wants to get past the check, so they follow along. The moment they press Enter, the pasted command runs. Malware installs, saved passwords leak, or the attacker gets remote access to the whole machine.

According to security firm Huntress, this technique accounted for more than 53% of malware delivery incidents in 2025. Past the halfway mark, it has stopped being an exotic trick and become the mainstream delivery method. In May, attackers exploited a SQL injection flaw in Ghost CMS (CVE-2026-26980) to compromise over 700 education and tech websites at once, then served visitors a fake Cloudflare verification page, as Malwarebytes reported.

Why your antivirus never sees it: you pressed Enter yourself

So why hasn't security software been catching this? The answer is simple. Antivirus and email filters are built to watch files arriving from outside, whether that's a sneaky download or a malicious attachment. ClickFix never sends a file for them to inspect. The user looks at the command with their own eyes, copies it by hand, pastes it into a terminal, and presses Enter. From the operating system's point of view, that is indistinguishable from the owner running a normal command.

A Help Net Security article quotes the key insight: the core of a successful ClickFix attack is "weaponizing the user." The latest antivirus is useless in that gap, and attackers don't even need to hunt for vulnerabilities. Human habits are enough. That's why this thing grew so fast.

Opera decided to watch the clipboard itself

Opera's answer to this gap is a feature called Paste Protect. The approach is clever. Instead of matching known malware signatures against a database, it detects the command patterns typical of ClickFix on Windows, macOS, and Linux. If something you copied from a web page matches a suspicious pattern, the copy itself gets blocked and a red icon appears in the address bar. You can view the first 120 characters of the blocked command if you want to see what it was, and if you still insist on proceeding, you have to hold a button down for more than five seconds. Opera bundled in clipboard hijacking protection too, which stops the bank account or crypto wallet address you copied from being silently swapped for the attacker's.

Because it looks at behavior patterns rather than signatures, new variants should still get caught. That's the part Lifehacker emphasized in its coverage. The catch is that only people who use Opera as their browser get any of this. Chrome, Edge, and Safari users have no equivalent built-in defense yet.

Your hands should stop before your browser does

So the practical fix, at least for now, is less about switching browsers and more about breaking a habit. A real CAPTCHA never asks you to copy a command and run it somewhere. It's a checkbox, or picking a few traffic lights out of a grid. Treat the phrase "paste this into your terminal" on any popup as the warning sign itself. The Windows Run dialog and PowerShell are windows most people have no reason to open even once a day unless they work in development or IT. If an unfamiliar web page is telling you to open one, the premise of the conversation is already broken. Read every command before you paste it, and never run one you don't understand. Those two rules alone defuse most of this attack.

Opera shipping this is welcome news, but I wouldn't outsource the whole problem to a browser. I'm staying on Chrome as my daily driver. What I did change after reading about this: before any copied command goes into a terminal, I stop and actually read it. Given how much command-copying my blog tooling involves, that one brake pedal seems worth installing on my side too.

Thanks for reading. Happy hacking!