It played out like an old film-noir story. It was Saturday night. I was hanging out with a couple of friends, when she called. She has been crying, I could tell, even though she tried to hide it.
“I’m sorry,” she said, “I have been crying, but try not notice it.”
“I didn’t notice,” I lied. I’m a gentleman like that.
“You have to help me,” she said, “you are my only hope.”
As I walked out into the rainy night, I thought about what I’ve gotten myself into. The mist gather playfully around my feet. A gust of cold wind. Lightning followed by thunder clap. But I was lost in thought, not noticing the cold. I’ve taken a job I’ve never done before. I wondered if I will be able to finish it in time. By the time I’ve reached home, I had a game plan in place. I sent her an email, asking if the plan was acceptable and then crashed into bed.
Just Do It
She runs a design studio, and she closed a deal with a small company to design and deploy their website. This is a simple almost static website, with just a few special pages here and there. The problem was that her previous “programmer”, hours before deadline, admitted he has no idea what he is doing, and quit. She managed to get an extension from the customer – one week.
I have some experience with WordPress, as it runs this blog, but I never learned the internals (how to write a plugin, a theme or anything PHP related, etc). I also have some experience in web development in Django which is an awesome framework for building web applications in Python, some CSS skills. Things I picked up along the way, but I’m not a professional web developer, not even close.
This is not rocket science, but still, the time was short, and there was plenty I didn’t know how to do. Under these conditions I like to employ a very aggressive problem solving methodology I call “Just Do It”. Here’s the methodology in a nutshell:
- Do It!
- Repeat until success.
Repeat Until Success
Most people fear failure more than they love success. They prefer not leaving their comfort zone. In fact, they are more loyal to their job description than they are to their workplace (also known as the “I’ve been a DBA for 12 years at 6 different companies” syndrome). When they need to learn something new, they take a few months to study the subject, read books and get mentally ready for the job. They need time to acclimate their comfort zone. If any of these people will have been asked to help my friend, they would have said “I’d love to, but I don’t think I can do it”.
Other people just get at it. They hack and slash at the problem until they solve it. First attempt? Almost always a failure. However, instead of giving in to despair, they try again. And again. And again. Each time they learn a bit more about the problem, about the technology, about best practices. After a short while, they get it done. It won’t be pretty. In six months time, if they ever see that code again, they’ll bow their heads down in shame. But there, in the moment, the problem is solved, they’ve learned something new and they are posed towards a successful future.
The important thing is to repeat, repeat, repeat, until you win. Each time, try a different approach. It doesn’t matter which one, as long as you try something. This is how I did it:
Day 1 – Reaching Out
The first day was the easiest. I’ve installed a new WordPress for development purposes. I’ve downloaded an empty skeleton theme I could use as scaffolding for the design of the site. I’ve put content into the site, set up the header, the pages, the navigation menu. These things are fairly simple and are supported pretty well by WordPress. By mid day I had a basic site in place. Then I started working on the more advanced features.
I found a WordPress plugin for the image galleries, but it didn’t really do what I wanted. The theme I was using had some defaults it was printing for each page (comments, written-by lines, etc.), which I couldn’t disable. The sitemap plugin was all wrong. The WordPress documentation really isn’t as good as it should have been.
This is what reaching out is all about. You go into the world and bring back what existing knowledge you can find.
By 2 a.m. I had to call it quits for the day. I found a great deal of existing samples but none of it was what I was looking for.
In the middle of the night, when all you want to do is go to sleep, do it. Don’t think: “I’ll just finish this, and then I’ll go to sleep”. No. Leave it all and go to sleep right now. You are in a hurry to finish, and you are tired, and the combination is making you stupid. You will not learn anything new at 2 a.m., believe me.
Day 2 – Tampering and The Rule Of Minimal Change
Next morning I decided I’ll try and use what I’ve gathered the previous day. I opened up an editor and started looking at code. With code in front of you, generic how-to questions become specific what-is questions. Yesterday I wanted to add a script to the site. Today, I learned what the “register _script” function does. I’ve spent the morning trying different modifications to the code until I got the results I wanted.
By noon, I was a different person. The day started with a feeling of frustration, as the previous day I couldn’t find what I needed. Now I was no longer dependent on existing solutions. I could change them to fit my needs. It was liberating and motivating. Things started falling into place relatively quickly.
How quickly? So quickly that everything I did was a mess. I call this the rule of minimal change:
Start with something that works in one way and change the minimal amount of code, to make it work in a different way.
This technique includes swapping the return value just before the return, overriding a single function somewhere along the call stack or commenting out blocks of code. There is no change too ugly or too short. Just get it to work in the way you intended with the least tampering. Since most of the code you haven’t read or understood, changing too many things will brake it, and tracing the bug will be much harder.
By 2 a.m. I decided it’s time for bed, because, well, it was getting late and I was already ahead of schedule.
Day 3 – Paying the Technical Dept
There’s a saying: There’s no such thing as a free lunch. And boy, do I wish this wasn’t true. When you work as messy as I did on day 2, you have encured a lot of technical dept you need to return. Technical dept is defined as follows:
Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
The site was working as expected, more or less. The functionality was programmed in, in any case. Now there was the matter of cleaning up and applying the design. This day was spend cleaning up after myself. It was a long, tedious and boring day. Hardly any visible progress was done this day, but it was more stable and robust.
After 16 hours of work I was done. Or so I thought.
Day 4 – (Im)perfection Has Its Price
It Ain’t Over Until the Fat Lady Sings – the customer has to say it is finished for it to be finished. You can’t always get away with good enough. Even if I’ve worked long hours, or my sofa cushions are shaped like my rear end, if the client isn’t happy I’m not done. I am not a professional web developer, so I expected there’ll be things I miss.
Designers are perfectionists. They seek perfect beauty and aesthetics, and of course, they want the result to look exactly like the PDF they’ve sent you. Me? I love quick & dirty & be-done-with. I got an email that morning with a list of minute pixel sized changes.
So I cleaned some more, and fixed some more. After an even more tedious day, I’ve got it to the point where I was allowed to deploy the site.
This isn’t my best work, but it’s amongst the fastest. I’ve employed this sprint-learning methodology a few times before, and I’ve always over performed my expectations in the short term. In the long term, the technical dept will be returned. It is sometimes worth throwing away and redoing everything, but it is always better to learn through doing than through reading books.
So, when in doubt, just do it.