Computer Science & Programming

What

This is the start of a new stub for me to curate thoughts, happenings and learnings in and around computer science, software and programming. I hope this will ultimately help some folks getting into the science, software and programming of these computers among us.  :)

Come back and visit! Work in progress!

Articles

Django - 3 Reasons Why Django Wins For Start-Ups

Docker - Fast Docker Builds

Design - 3 Ways To Design Products For Humans

Best Practices

As a bootstrapped entrepreneur, I’m always looking to expose new tricks of the trade to expedite the building process. I also like to cross pollinate with a wide spectrum of modern minds, developers and builders to help keep my own practices fresh and in check.

One night I half-brain posed the following question to a talented friend.

“... i'm trying to figure out a way to program 10x faster ... i know this sounds stupid/silly but think about it ... wondering if you could think of any tips you'd give your younger self or a new developer that would help them speed up the their time to create and release code … just food for thought ... as a 1 man show at the moment i'm always thinking of ways to improve my efficiency and produce more results :D ... i've found that having a set of well formed lego pieces (objects/libraries) can help of course but still shit just takes a long time when you're writing code ... like writing a book ... it doesn't write itself“

My stellar Google buddy Tim James was kind enough to reply with the following thoughts.

Tim James

- Initially, just prototype and crank things out.  It's not worth investing heavily until you know a feature is important.  Good for new projects, new features on existing projects, things you want to experiment with, etc.

- As soon as things feel unwieldy, invest the time to refactor.  I think this is a massively important part of coding.  You end up taking a hit, but the earlier you refactor, then every subsequent change becomes vastly simpler.  I usually find I could spend a few hours, or even a day or two doing a solid refactoring, and the benefit I gain on subsequent changes could be measured in days to weeks.  Not 10x, but far more than the initial investment in most cases.

- Learn your IDE really well.  This can probably speed you up 2-3x over trying to code in a simple text editor or without knowing all the tools at your disposal.  Again, this will probably slow you down by about 50% while you're learning it.  Every keystroke, you start thinking, "oh, what's the magic hotkey for {autocompleting, finding the file, doing a regexp query across all my code, query-replacing across all my code, auto-refactoring this method}, etc."  Once they are ingrained though, they become very fast, and things that in a simple text editor would have taken an hour or two suddenly take seconds in an IDE.

- Design with testing in mind.  If you can't test it, it's going to break, and you're going to waste time fixing bugs.  Don't underestimate the time sink in fixing bugs.  It can be enormous, especially as you get to hundreds of thousands of lines of code.  The other benefit of designing with testing in mind is it usually lends to better code structure, which helps with that refactoring step above.

- Be aggressive about deleting stuff that isn't crucial to your project.  The more code you have, the more you have to keep that code working.  You can always resurrect it later.

- If you can find some way to do it, surround yourself with coders who are better than you and good at giving constructive criticism, have them review your code, and review their code.  Nothing like working with phenomenal engineers to improve your skills.

- Think really carefully when naming stuff, and write lengthy comments for weird stuff you're doing.  I find that I sometimes go back and read stuff and it makes a lot of sense, and realize it was because I spent a lot of time up front.  Sometimes I go back and find stuff is confusing as hell, and it's usually because I didn't invest enough time.  Depending on your memory and the personality / number of colleagues you have, it is more or less important to be super careful about this stuff.  I forget stuff quickly, so your comment about "like writing a book" is really important, because the more your code reads like a book, the easier your life will be when revisiting that code.

- Along those lines, writing comments is often a bad sign that you just need to be refactoring.  For example, if you have an if block that has a comment describing what that if block is doing, you might instead write a function with a name that describes what the function is doing and then call the function from the if block.  This way, the code is self-documenting, and you won't have to be constantly updating your comments.

Thoughts?

I’m looking for other talented friend to also chime in here if you have some ideas to add to the mix please drop me a note! :)

Books I’ve Found Helpful

- Cracking the Coding Interview by Gayle Laakmann McDowell

- Algorithms To Live By: The Computer Science of Human Decisions by Brian Christian

- Hooked: How To Build Habit-Forming Products by Nir Eyal

Surely You Must Be Joking Mr. Feynman by Richard P. Feynman