Reflections

The Origin of Purpose

How a teenage repair business, competitive gaming, forum guides and years of reviewing led me to test storage the way I do.

On this page 3 sections

I test storage the way I do because of a habit I picked up early: when a system falls short, fix it. It started when I was a teenager with a soldering iron, a folded flyer and a small neighborhood tech business of my own. It ran through competitive gaming, forum guides, and years of reviewing before it became the validation work that this site is built on. That method is written down in full on the Editorial Standards page.

Six stops on one line: candy, iPods, controllers, guides, reviews and validationA horizontal copper line with six teal circles on it, numbered one to six and labeled Candy, iPods, Controllers, Guides, Reviews and Validation, left to right.ARTICLE / REFLECTIONSFrom candy to repeatable testsSIX STOPS · IN ORDER01Candy02iPods03Controllers04Guides05Reviews06Validation

Where it started

I am a lifelong gamer. In the late 90s and early 2000s I played competitively, and that taught me to take every edge available. Long load times were a disadvantage, and when flash storage arrived, it was clear it could remove them.

Close view inside an open rack-mount server chassis, with a green circuit board card, heat sinks, braided cables and a copper heat spreader.

A soldering iron and a folded flyer were the equipment, and I had appointed myself the neighborhood’s Chief Technology Officer. My business began with candy and moved on to iPods, and I flipped, repaired and reinvested. By sixteen I was optimizing as well as building, and every circuit or cooling loop was a chance to beat the standard design. To the neighbors I was the tech guy.

On controllers I rewired inputs, rerouted signals, and added tactile responses so the controller answered the way I intended, which had nothing to do with cheating the game.

Where it started

Three starting points, and the rule the controllers taught

Three equal panels side by side: candy and iPods (sold candy, flipped and repaired iPods, reinvested), controllers (rewired inputs, rerouted signals, added tactile responses) and gaming (took every edge, long loads hurt, flash could remove them). A copper arrow runs from the controllers panel down to one wide box that reads: Imperfect system, rewrite it.01 CANDY, IPODSSold candyFlipped iPodsRepaired themReinvested02 CONTROLLERSRewired inputsRerouted signalsAdded tactileresponses03 GAMINGTook every edgeLong loads hurtFlash couldremove themImperfect systemrewrite itA starting pointThe rule the controllers taught
Figure 1 · The rewrite-it rule came from the controller projects. Source: the author’s own account.

The controller projects taught me a rule: if the world hands you an imperfect system, rewrite it. Years later that instinct for precision and control carried over to auditing firmware.

Guides first, then reviews

My first writing about it was practical. I made Windows install and optimization guides for SSDs and hard drives and posted them on Overclock.net. For myself, my family and my friends I built the Windows 7 guide, and I shared it because the guides that existed were getting out of date. The Windows 8 guide has passed a million views.

From there I moved into reviewing, first at The SSD Review and then at Tom’s Hardware. That work taught me that a spec sheet is a claim, and that the useful question is what a drive does after the first minute.

Guides first, then reviews

Guides led to reviews, and reviews led to repeatable tests

A left-to-right flow of four boxes joined by copper arrows: Windows guides on Overclock.net, reviews at The SSD Review, reviews at Tom’s Hardware, and validation with repeatable tests. Dashed lines run down from the two review boxes to one wide box that reads: A spec sheet is a claim. Ask what a drive does after the first minute.01WindowsguidesOverclock.net02ReviewsThe SSD Review03ReviewsTom’s Hardware04ValidationRepeatabletestsA spec sheet is a claimAsk what a drive doesafter the first minuteNext stopLesson learned
Figure 2 · The order of the work, with the lesson the reviews taught. Source: the author’s own account.

Alongside the reviews, I have spent more than 15 years building systems and validating them. That is where I learned to make tests repeatable, and it is what most of this site is about.

What I remember most

Looking back, the people stand out more than the tools, and connection with them was the reason I did any of it.

Black and white portrait of two people in sunglasses, one in a plaid shirt and one in a polka dot top with a headscarf, against blurred foliage.

A student’s laptop came back to life hours before finals. A gamer’s console stopped freezing in the middle of a match. The thanks was never loud. It came as a nod or a small smile, and the sense of a promise kept.

What I remember most

Small repairs turned into the purpose behind the testing

A left-to-right flow of three boxes joined by copper arrows: the fix (a laptop revived before finals, a console that stopped freezing mid-match), the thanks (a nod, a small smile, a promise kept) and today (every benchmark, every line of diagnostic output). Below, a wide box reads: Fixing tech meant helping someone be heard.01 THE FIXLaptop revivedbefore finalsConsole stoppedfreezing mid-match02 THE THANKSA nodA small smileA promise kept03 TODAYEvery benchmarkEvery line ofdiagnostic outputFixing tech meant helping someone be heardWhat happenedWhat it meant
Figure 3 · From a repair to a quiet thanks to the work now. Source: the author’s own account.

Those small wins hardened into purpose. The same drive that guided my teenage builds now takes me through memory for AI and silicon design, and every benchmark and every line of diagnostic output still goes back to those days, when fixing tech meant helping someone be heard.

Sources

Primary is the original paper, standard or datasheet. Secondary is a review, a vendor summary or a news report. Measured is my own test data.

Show all 4 sources