The Darwin Award: How crazy people refactor their code

Jaeson Booker
4 min readMay 13, 2019

--

Click. 11:45 PM. Sluuurp. 12:45 PM. Click. 1:45 AM. Sluuurp. 2:45 AM. 3:45 AM. Zzzzzzz. 3:50 AM. ..? 3:55 ?!?! 4:05 AM. Click.

This is how my last Saturday sounded. It was 11:45 PM, and I had restarted my project for the second time that day. I was down in the basement of my dorm, the lights automatically shut off after 10. I had gone there so my roommate could sleep. But sleep wasn’t for me. My next few hours would be spent in the dark, guzzling energy drinks, fighting exhaustion, cranking out a project I had made three times before. It was due next week, and we had been given over a month to complete it. This might sound like a problem of procrastination, but it isn’t. My problem wasn’t that I started the project too late. It was that I kept restarting it.

Iteration 1

First week of class. I go home. I give myself 4 and a half hours to build the whole project. Why? Fuck you, that’s why! Sigh. Sorry, that was rude. I’m a bit tired, you see. If you must know, I used to build out basic CRUD apps like this, and was pretty good at it. So now I constantly feel like I have to prove I haven’t lost my edge. And it played out like this: 5:45 PM. Click! Energy drink opened. 5:50 PM. Click! Project started. 6:30 PM. First blocker. 7:05 PM. Second blocker. 8:30 PM. Stuck. 10:15 PM. Project closed. Result: failure. Project abandoned.

Iteration 2

Second week of class. Bored of the way I was doing it, I decide to implement the project into something I had started months ago. However, looking at the code now, it was both confusing and so poorly-made that I would be spending more time refactoring than writing new code. Click. Project abandoned.

Iteration 3

Third week of class. I start a new project, embedded in the idea of the project I tried to make months ago. I am cautious. I plan everything out, and start building it slowly… then get bored. Too slow, no excitement, no stakes, no risks, no thank you. Click. Project abandoned.

Iteration 4

4:05 PM. Saturday before finals. I give myself 4 and a half hours to craft it out again. Slurp. Click. Project started. I start off fine, but get lost in tiny bugs. I become confused and frustrated. I start looking for a way out. Start looking for some previous project I could quickly alter to match the requirements. 8:35 PM. I close my laptop. Result: Failure. Project abandoned. Sluurp!

So I think this is where you came in. Refactoring projects this way is insane, a mess, and very stressful. I wouldn’t wish this kind of refactoring on my worst enemy… because I don’t want to give them any pointers. Despite this tactic normally being a terrible idea, it has its uses. I can craft out a basic application now extremely quickly. What took me a day in the past I can now craft in an hour. What took me an hour before I can now do in minutes. And I now finally have a project with a result I’m happy with.

It looks pretty nice for something made in a few hours. Its code is clean and concise. No function is there that shouldn’t be. There’s zero waste, and I understand every line of it. What holds many people back from starting a project is actually starting it. And I’ve got that step pretty nailed. Is this a good tactic for gigantic projects? Of course not. Is this a good idea to do at a job? Only if you want your coworkers to hate you (in which case, go for it). But this is a great way of internalizing how to build out a project, and the reasoning for each step and each part. It’s Agile development taken to its illogical extreme. Best of all, despite the stress, you’ll never be scared of beginning a project again. And maybe that’s all you need.

--

--

Responses (1)