When I was 9, one of my teachers, Mr. Conger, gave me a book. It had rules, diagrams, and then a whole bunch of pages of all-caps text on numbered lines like the picture to the right. He sat me down at an Apple IIe and gave me a nudge down a path I’ve walked the rest of my life. I was left to my own devices for a few hours a week, and before I knew it was was changing the school’s games around, a little bit here and a little bit there. I snuck my name into Lode Runner, changed people’s tombstones in Oregon Trail, and wrote my own little adventure games. I’d learned from that book that I could look under the hood, that I could read what others had done to make the games and programs that I was using, and that if I tried hard enough I could even understand some of it.
That was Apple BASIC. It was about as rudimentary as it gets, but it was a starting point. Some programmers joke that hell is other people’s code. Plenty of times, they’re right, but I always leaned more towards another classic – good artists borrow, great artists steal. Supposedly Picasso came up with that, but I like to think he creatively modified something someone else had said. Other people’s code is a gift whether it’s out on display or hiding just below the surface, and I’ve always loved getting presents. Sites like Stack Overflow help fill in the gaps and make the big bad errors go away, and there’s a forum or two for every niche language, every crazy topic out there. You get better by trying, failing, and seeking help along the way.
Some people hone in on one language or one system, and some people never do. I’ve gone the swiss army knife approach and tried to fit in as many tools as I can. Do I need the fish scaler? Maybe. It was fun to learn how to use it, and maybe it’ll come in handy some day. The main tool in the set for me has always been PHP, with a need here and there for tools like Perl, Python, NodeJS, C#, Handlebars, React, or any of a dozen others.
Lately I have a drive to learn Rust and Solidity and try to put those skills to use in the emerging world of Web3. The fun of coding and the point of it are the same thing – you get to turn unknowns into knowns. Solving problems, creating solutions, making software that gets to take on a life of its own – that’s what you get when you teach a kid to code.
A Little Advice From Someone That’s Been Developing For 30 Years
Let me try to distill a few useful points for those of you just starting out on your coding journeys:
Prioritize
You’ll be handed new issues and high priority tasks left and right. It will be in your brain’s best interest to keep an active list of prioritized tasks and projects. When presented with something new, you should run through that list with the person giving you the new task just to confirm where it sits on the ladder. Something may seem more important in the moment, but taking a step back and taking just a few more moments to compare it to your other tasks will help avoid deadline slippage and will reduce stress overall. The folks waiting on earlier items won’t be mentally adjusting your or your teams’ earlier completion estimates as new tasks arrive so you’ll want to re-involve them if you need to move something else ahead of your earlier priorities.
Use Mockups
Modeling your system before building isn’t just a busywork task or box to check, it can expose flaws in reasoning or totally missing pieces. If the item you’re working on is going to have a user interface, make a working mockup in a good piece of software like Invision, Figma, or Adobe XD. Starting a project by trying to envision the end result will regularly yield a surprising number of gotchas right up front. “Oh, I just assumed it’d do such and such” or “That’s not going to work for our users, they need to do XYZ” are things you’re going to be glad you got out of the way before you spent two months building features that end up getting relegated to repo-history.
Write Your Comments First
This is the code version of creating a mockup. If you can’t see the work end to end, there’s a potential problem. Avoid thinking in terms of “I’ll cross that bridge when I get to it” because the moment the project begins, you’ve gotten to it. You’re there whether you realize it or not and it’s better to know now whether or not it’s going to be a bridge you can cross. I’ve always been a proponent of an overabundance of inline commenting on software I write because time will pass, and even the author will lose details and context. Write your code as though it will live for a decade or more – sometimes it actually will and you want to be as kind to future you, or a future maintainer, as you can be. You can’t assume that the next person working on your system will have the same skill or experience level that you’ve built up for yourself, or that they’ll approach problems similarly. Rather than end up with “what the heck were they thinking here”, writing every step of the process out will result in more “oh I get it” moments when something inevitably needs to change down the road.
Leave A Little Scotty-Factor
At first, it may feel as though you’re fibbing a bit when you say a task will take you 4 days instead of the 3 you can see yourself completing it in. Trust me – more often than not you’ll be thankful you gave yourself the extra time. When you provide an estimate that works out to being as fast as you can get something built, you’re putting yourself in a position of inflexibility. Reality doesn’t match estimates. As a developer, you’re going to get interrupted. You’ll be pulled into “quick” meetings and given high priority tasks like hotfixes. Scotty famously gave Kirk a timeline that gave him room to make realizations and corrections along the way, and it wasn’t just a cute trick for a TV character. The real-world name for what you’re fighting here is the Planning Fallacy, a tendency to display an Optimism Bias for tasks similar to those you’ve completed in the past.
We want to think that we’re constantly shrinking the amount of time it will take to do complex work, and either consciously or subconsciously want to impress our peers and superiors by setting and achieving more difficult goals. The thing is, even doctorates and lead engineers still fall into the same trap and consistently underestimate the time it will actually take. That leads to a feeling of always trying to catch up. Try to imagine mistakes, scrapped code, and head scratchers as being an inevitable part of your timeline, and when you have your worst case scenario – add 20%. A decent job won’t be built around forced short timelines, because they’ll have hopefully learned from experience that getting something done fast all but guarantees it’ll be something that’s revisited regularly as the edge cases no one had time to think of crop up down the line. The icing on the cake is that once in a while you’ll beat those padded goals and still have a product you can be proud of – you Miracle Worker, you!