![\"code\"](\"http:\/\/www.starkeith.net\/coredump\/wp-content\/uploads\/\/2014\/09\/code.png\")
I’ve been programming for more than a few years now, but sometimes I like to look back at things I wrote when I was much younger, and reflect on how much I’ve learned since then. Of course, no one expects you to start out knowing everything, but there are a few things I wish I’d known when I started, or that I’d learned a bit sooner than I did. So, just for fun I thought I’d come up with a list of a few of the things I wish I’d known when I started programming.<\/p>\n
Like a lot of young developers, when I first started writing code I didn’t use any sort of source code\/revision control system (just zipping up the project files every so often doesn’t count). But once I did, I realized how wrong I’d been – having a complete history of all changes is just sooooooooo<\/strong> <\/em>helpful, even without any of the other features (branches, merging, etc.).<\/p>\n Now, there is a bit of a learning curve with any revision control system, and when you’re just starting out that learning curve can be a bit steep, especially in addition to all the other stuff you’re learning at the same time – but it is so worth the time and effort. Being able to undo changes, or make different changes to the same code (via branches), and just in general having a nice, detailed history of what you’ve done and what’s changed over time is simply invaluable. This is especially true if you’re part of a multiple programmer team, but it’s also just as true if you’re working by yourself.<\/p>\n For anything beyond 5-minute throw-away projects, use source code revision control!<\/p>\n Writing comments is like writing a log entry that you’ll inevitably need to review much, much, much later – so taking the time to write it clearly is well worth it. Countless times I’ve run across old comments of mine and wondered “what was I thinking?”<\/p>\n Same goes for commit messages – brevity may be the soul of wit, but not when it comes to commit messages! You shouldn’t need to do a diff on a particular commit just to figure out what you did; the commit message should at least give you a general idea.<\/p>\n On the flip side, though, you don’t want to be writing novels in your comments or commit messages, either – so write enough to be understood, but don’t be needlessly wordy, either.<\/p>\n It doesn’t matter how many times you’ve gone through the process of compiling or deploying a build, someday you will forget a step. And it’s also just so nice to be able to kick off a complete build & deploy with a single click and then go grab a cup of coffee or something, instead of having to sit there and go through all the steps manually. So take the time to write a script to automate the process – it doesn’t need to be super-complicated, just something to do the work for you. Believe me, it’s worth it.<\/p>\n Also known as “TEST EVERYTHING,” this one’s a hard rule to stick too, especially for really small things like changing a typo in some text – but you still have to do it. It might seem like a tiny change that couldn’t possibly cause any problems anywhere else – but code is complicated, and complexity breeds bugs in the weirdest ways. Maybe that little text change you made causes a display issue at higher DPI settings, or when using a different font – you won’t know until you test it.<\/p>\n When making a fix – even for a small, seemingly insignificant problem – if it’s in production code (or in a released beta build), you’d better be writing up a bug report for it. Just making a comment in your SVN commit log isn’t enough – you need a proper report that can be searched and found and referenced, because someday, maybe years from now, you’ll need to know how or why you made this change.<\/p>\n (I will make an exception here to “fixing a typo” text-only changes, but only just<\/em>.)<\/p>\n Just as fixing (seemingly) simple bugs can have unexpected consequences, designing and adding simple features or changes can turn out to be unexpected complicated. Writing a spec – even if it’s just a quick outline on paper or on a whiteboard – can help immensely in heading off these unexpected complexities. (Or, at the very least, you’ll know there are complexities and can design around them.) Good software should always be designed first, then coded – and writing a specification is part of the designing step (if not the entirety of it).<\/p>\n At the same time though you don’t need to write a novel’s worth of specifications, even for complicated changes or features. If the spec is too long (or goes into too much detail) then no one will read it – yourself included. If your spec just has to be that long, then maybe the feature or change you’re planning should be broken down into smaller parts first. Finding the right balance between length & specificity is a skill that takes practice to get right, but it’s one that’s worth learning.<\/p>\n These are just some of the things I wish I’d known when I started programming all those years ago – if you have things you wish you’d known, feel free to share them in the comments!<\/p>\n","protected":false},"excerpt":{"rendered":"Write Comments So That You’ll Understand Them Months or Years Later<\/h3>\n
Automate the Build & Deployment<\/h3>\n
No Fix or Change is Ever Too Small to Not Test<\/h3>\n
If You Find a Problem, no Matter How Small, Put it in the Bug Tracker!<\/h3>\n
Always Write a Spec (But Don’t Write a Novel)<\/h3>\n
\n