30 Years, 30 Programming Tips

30hax.md

I just made the terrible mistake of turning thirty. Apparently, one of the things that 30-year olds do on YouTube is make lists of 30- things. 30 is a lot of things to put in a list. I tried to make a list of 30 things about being 30, but I got like, four things in before I realized that I didn't have that many things.

So instead, I thought I'd make a list of 30 things I've learned about programming. Let's begin.

1. this first episode has Q in it? Like, first episode. ugh, this is not off to a strong start.
2. why does everybody hate Wesley Crusher so much? He doesn't seem so bad, and Wil Wheaton is a really nice guy in real life.
3. oh. OH. I get it now. I understand the hate.

Oh. Sorry, that's a list I'm making about watching Star Trek The Next Generation for the first time. I'll .. uh... get to that later.

1. good, information-dense logging will make after-the-fact debugging much easier. I like to have all of the important software of my various systems logging to syslog, and I like to have all of my various syslogs sent to a central computer where I can index and search them. I like Papertrail for this, but I ain't no corporate shill. Use whatever you want. A lot of people use a combination of Elasticsearch, Logstash, and Kibana for this, the "ELK" stack.
2. time spent checking that your preconditions are valid and verifying that your code works properly is never time wasted. this can come in a lot of different forms - asserting things that should always be true, verifying the order of your parameters, unit testing, null checking, type checking, check checking - the more ways that your software has to surface errors, the more errors you'll find.
3. make sure the data is correct, well-formed and valid before you put it in the database.
4. automate anything that you might have to do again. if you're not sure how to start, just... start making aliases for commands that you use all of the time. as you find yourself starting to build more and more complicated aliases, start combining them into libraries. start linking them together. after a while, you'll have shortcuts so deep that all you have to do is flex a butt muscle and your software will test itself, push to source control, deploy, and make you a cup of coffee.
5. sometimes it's better to realize that you've made your codebase worse, take your entire day's work, light it on fire, and never look at it again.
6. having git around means that you never need to delete or comment out code. just tuck it away in the past, or in a branch.
7. never delete anything in a database unless you have to for privacy reasons. set a hidden flag, and then just hide it from the user.
8. if you find yourself separating a large function into segments and writing comments to label each of those segments, consider turning those segments into named functions. in some languages you can even scope these functions so that they never leave the function you were in, in the first place.
9. globals are the enemy. never forget.
10. Accept that most of your advice is composed of commonplace platitudes that people have heard a thousand times, and refrain from adding more useless noise to an already noisy conversation, just to hear the sound of your own voice.. except on special occasions. WINK.
11. skim the entire manual, not just the parts that are relevant to the problem you have right now. chances are, the people who wrote the thing that you're using have already encountered the problems you'll face in the near future.
12. invest your money, save for your retirement, eat your vegetables, and don't use pickle to serialize data
13. someone has already designed an algorithm, data-structure, or database that will do exactly the thing that you want to do very efficiently. in fact, just about everything you'll ever do has already been done before, and better, by someone else. this doesn't mean that you shouldn't try new things, it just means that a little time spent reading the literature might reveal that that thing has been tried before, and it didn't go well.
14. it doesn't matter how good your thing is if nobody knows how to use it. WTFM. write the fucking manual. And this doesn't just mean generating API documentation with a tool. You need clear and effective writing explaining how your software works, including examples of how to use your software effectively. And then people are still going to use it wrong.
15. if you can't verify whether or not something is currently working, it's probably not working.
16. a flaky test is a failing test.
17. don't trust that Regular Expression you found on StackOverflow.
18. take a break, chill out a bit, stress-brain can't solve hard problems. but surfing your social media can't solve hard problems either. clear your mind with a walk, or prepare yourself a cup of hot tea. watch out, though, if you make yourself a snack every time you run into a difficult problem, you're going to get fat. take it from me.
19. constantly tune the tools that you use to filter out noise and surface real problems
20. I know your code is good, but fight the urge to make your code even more modular and general purpose. if you take it to it's logical conclusion, you'll just end up building an entire programming language, and you'll be back at square one. This happens so often that it has a name, the 'inner platform effect', which is what happens when a software architect creates a system so customizable that it's really just a poor replica of the software development platform that they used to build it in the first place. A specific invocation of this, "Greenspun's Tenth Rule", reads as follows: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." And if you want that in your system, you can just embed Lua or write the program in Lisp in the first place, and save yourself the time.
21. when someone is wrong, don't correct them unless there's something concrete on the line. being correct is no excuse for being an asshole.
22. when something is broken and you think that you know why it broke, don't stop diagnosing until you know that you know why it broke.
23. your first instinct as a software developer, upon seeing someone else's code, will be to shit on it for being poorly documented, strangely formatted, and badly written. this is because you are unfamiliar with it. understand that just because code is not yours does not mean that it is bad; you are reacting out of frustration and applying an impossible standard to other people's code.
24. rewriting something from scratch will always take three times as long as you expect. treat yourself to it once in a while anyways.
25. wanna write a blog post or a conference talk and you don't know what to write about? take a program, a library, a protocol, or a data structure that you take for granted and really tear it to shreds until you deeply understand how it works. write a talk that explains that to everyone. that's your first draft. then, keep reading it out loud to yourself until you can get through the entire thing without rewriting a part that doesn't sound right.
26. you can learn everything you need to be employable in a 9-month boot camp, but if you ever stop learning your obsolescence clock starts ticking. At this point your only option is to eat a programmer's heart to gain their powers. Or take up sailing.
27. the command line is obscenely powerful - it's a way to build your own utilities very quickly, other programmers build most of their utilities in the command line, and it's super easy to call out to a command line program from your own software.
28. lots of people have opinions about what makes a Real Programmer - it's almost always something that they know that they think that everybody else should know, or something that they do that they think everybody else should do. maybe it's being able to manage virtual memory in C, or knowing the computational complexity of every operation on a Trie, or contributing to open-source. When you write your first line of code you're a Real Programmer - everything else is chest puffery from insecure old tractors who want to feel better about themselves.
29. watch out for off-by-one errors

that's it. 30 programming tips. thanks for watching!

if you like my stuff, I'm classam on twitter, I run a comic at cube-drone.com, and you can support my Patreon at patreon.com/cubedrone

you could also subscribe to my youtub channel.

if you don't like my stuff, you can die in a fire