I’ve been a designer, caterer, and product manager. I never stopped coding.
In ’96 I was doing bad things to perfectly innocent websites. Navigation menus flying out to greet you on every page load. Full-page backgrounds of my face, made “artistic” with a gaussian blur. Blinking scrolling text! I taught myself every “How to write HTML” tutorial from Webmonkey and experimented ruthlessly on my little webpages hosted in Geocities’ Sunset Boulevard. AOL dial-up brought the world wide web to my sleepy suburban household and I was hooked.
I didn’t think of my hobby as “computer science.” That’s what old men with lab coats did at NASA, right? THIS WAS THE WEB, BABY, and I was hacking my way through it.
I haven’t had a title resembling “Web Developer” or “Engineer” in almost a decade, but I’ve still written code in every job I’ve ever had. It’s a practical skill I’ve held on to, and the single reason I can point to for being smarter and faster at solving problems. That’s why everyone should learn to code, even if it’s just for three months.
1. I got really fast at looking up answers
- How to scrape a webpage for information you want
- How to evaluate whether “11:30pm” falls within an acceptable dinner time window
- How to text “Book now sucker!” to your phone from your app
The answer might come in Ruby when you’re coding in Python, or meant for scraping puppy adoption websites instead of State Bird Provisions….but that’s why it’s up to you to apply the answers. And since not every answer is good, you also get quite adept at sniffing out the duds.
Why is this applicable to pretty much any aspect of life? Because you don’t know things, all the time.
- Where is that great date-night spot you just heard about? Look it up.
- How long does it take for a bursted balloon to decompose? Look it up.
- How do you change your tire? Go search YouTube.
After three months of coding, you will do every single one of these tasks faster than before you started. Why? Because with coding, you are solving bits of problems at roughly 12 per hour, especially when you’re starting out. You don’t yet have the answer accumulated from some past experience, so assume it takes you roughly an average of 3 searches to reach a satisfactory answer for each problem — that’s 288 searches in one 8-hour day! It’s sheer practice.
2. I see all the pitfalls
Occum’s Razor says that the simplest solution is most often the best one. But even if this first idea might be the best, it likely isn’t the most thorough solution. There’s bound to be an “edge case” scenario in which it won’t work well. Coding trained my brain to always think of these less-than-optimal cases. If I’m not careful I’m that Debbie-downer in your brainstorming session who poo-poos every idea. I don’t mean to, I’m just ridiculously aware of every detail.
Here’s a common example from coding: let’s say I’ve built a form that requires you to enter your birthday. I expect everyone to type in something like “5/14/1980” when suddenly my self-greeting-card site goes viral in the UK. I get an influx of “14–5–1980” or worse, “14 May”, which causes everyone to see ugly unstyled “500 error” pages. Why are they putting in weird dates and strings when they’re supposed to be putting in numbers?! Are they just messing with me??!!
This is when I learn to separate a date form into three fields, neatly labeled “Month / Day / Year.” Yeah. With every ounce of coding experience comes a myriad ways in which things can go wrong, which is nice to learn…. most of the time.
3. Steadfast Technician, not Mad Scientist
There are two kinds of problem solvers. Mad scientists who test seemingly random ideas and hope that one works; and technicians who methodically tease out a diagnosis then fix accordingly. Coding has taught me to be a technician. Not only do I have the patience to nudge here and poke there to better understand the problem, but I also firmly believe that if I follow these steps with patience and reason then I will find a solution. Though this isn’t always true in the real world, it’s true more often than not. No, laundry gnomes did not steal all your left socks. If you work backwards, you’ll remember that you placed your towering laundry basket on top of the washing machine to turn the doorknob, and hey! There’s the sock in the gap between the dryers.
Bonus Reason — It stays with you, like riding a bike.
Last fall I re-upped significantly in my coding cred. But before that I was writing code for a quarter of my time at best. I had a side project at my previous work that I contributed to, and dry-spells for several months with nothing at all. Coming back from that two years was surprisingly easy, like riding a bike.
Even if you stop after three months of trying coding, it’s not a waste of time because that way of thinking stays around. When I have the need to code again, the methodology kicks in so that I have an easier learning curve. It extends to learning other coding languages too. I was surprised that coding was easier after being away for two years.
Is coding fun?
The joys of coding are debatable. I, personally, enjoy the logic and predictability of programming. There’s a reason why they call different forms of coding “languages” — much like learning English or any foreign language, you acquire building blocks like nouns and verbs which you can assemble together to form sentences. And with those sentences, you form speech! I read a page of script just like I would read a book. Sure, when you master those sentences like writers do, you can get pretty creative with language — double entendres, metaphors, similes. But you’re able to manipulate these things because you know that when you string a noun and a verb together, it produces a coherent idea.
But not everyone’s a writer. And not everyone’s a programmer. It just might not be your thing.
Do it anyway.
Originally published at Patti Chan.