Productivity & Coding: Good Habits to Get Into
I’ve been programming on & off for about 5 years now. I’ve worked with a couple of languages (C#, Java, Javascript, Ruby, Python) as well as worked on projects as a student in multiple fields (game dev & full stack dev). And while I definitely have a lot to learn, I’ve discovered some habits that transcend all languages that will improve the lives of any programmer - from the newest of the new, to the head of a department!
Today, I’d like to share some of that wisdom. These habits are based on my prior experience, but I’m definitely not the first to come up with any of them, nor am I perfect at following any of them. Like any good habit, it’s not as simple as flicking a switch in your brain. It’ll take practice & reminding yourself to actually integrate good habits into your coding routing.
(Small note: most of these tips don’t deal with writing better code, but how to best succeed in productivity & memory while coding. If you’re looking for syntactic help, this might not be the article for you.)
Without further ado, let’s get started.
Start your day off with a Stand-Up
Ever sat down to code for the day, looked at your IDE, and had no idea what to do? Where to start? Where you want to be? Especially in a team environment, a Stand-Up Meeting at the beginning of the day can define a productive workday. This is the time to check in with everyone — what they’ve been working on, what they want to work on today, and if they need anything to succeed.
While this is mostly a habit for teams, it’s equally helpful for solo devs. Take some time before coding to check in with yourself. This also leads directly into my next topic…
Make clear & concise goals
When I’m not given a list of goals/deliverables to accomplish, I have a very hard time figuring out what each day should look like. I highly recommend get in the habit of writing down your goals — short, medium, and long term — for your projects.
- Short term goals might include what sections you want to be done with by the end of the day, or a list of bugs you want to squash.
- Medium term goals might include what you want to be done with by the end of the week, or deliverables for the end of a sprint if you’re working in scrum/agile.
- Long term goals will likely include what features are going to be present in each version of your project (alpha/beta/gold for games, skateboard/scooter/motorcycle/car for us Flatiron folk), and a list of stretch features to consider.
Working long-term down is my preferred way of doing things. Once I’ve established what I want for the first version of my project, it’s easy to figure out what features from that list I want to finish by the end of the week. Similarly, if I know what I want to get done by the end of the week, I can easily map out which features I’m doing on which day.
Now, you don’t need to worry about getting to your computer after a weekend not working, and being confused about where you left off. All your planning is organized and easily accessible.
I really like putting my list of goals straight into the associated project as a .txt or .md file — that way, I can take a look without tabbing out of my IDE.
Comment Your Code. That’s it. That’s the header.
Have you ever looked at a project you worked on a year, month, or even week ago, and thought to yourself… “What the hell is this code doing? What does this line even mean?”
If you haven’t, you will. It’s not about if, it’s all about when.
Similarly, working on teams means you’ll be looking at a LOT of code that isn’t yours. And if you sometimes write code monstrosities, imagine trying to figure out OTHER peoples’.
How can we fix this? Getting used to ACTUALLY commenting our code.
I know it can seem dumb to put so much extra effort into writing little notes in your code. But it will help you understand what you’re doing in both the long term & short term.
Put info about your script & references at the top.
References — we’ve all used them while coding. From official language documentation, to Stack Overflow, to random blog tutorials, to our own old code: using reference work is commonplace.
Sometimes, a reference you have will explain what you’re doing far better than any comment you can write. Or hey, maybe it has some other information you might need later. Instead of having a massive bookmark folder of websites, why not just put your references IN your code?
What I like to do is write out some basic info at the top of my scripts. Key inclusions could be name, date, project, & references.
There’s been plenty of times that I’ve tried to remember which website I went to to learn about the syntax of something, or which stack overflow thread out of 5 I browsed actually gave me the answer I was looking for. Don’t spend an unnecessary time looking for those references again. List them in your scripts.
Commit early & often
Version control is a staple of programming work, git(hub) being one of the staples of the industry. With it, you can look at iterations of your work over time. This is important for a plethora of reasons, one of which is bug hunting. If you have a lot of iterations of code, it’s easy to find when a bug originated & what code may have caused it.
You know what makes that difficult? When you don’t actually submit changes often.
Most programmers I know tend to commit their changes at one of two times: A) after they’ve built a sizeable amount of code, B) whenever they remember to. Neither of these options are good. You should get used to pushing code changes on a regular basis. Even if everything isn’t working 100%. The more commits you have logged, the easier it is to revert to a previous point, or search for a bug.
In the same vein: write descriptive changelogs!!
At the end of the day, you should be thinking about two things when writing comments & committing changes: your teammates, and your future self. Convey information about what you’re doing in a clear & concise manner. Don’t be the guy/gal/nb pal nobody wants to work with because nobody can ever understand anything you write.
Get a Rubber Duck
Ever had a problem with your code, asked for help from a co-worker, and then after explaining it for 10 seconds, you figure out what the problem was? Turns out, verbalizing your problem can be the best debugging method. “But I don’t want to look weird talking to myself at my desk,” you might say! Look no further! Why not talk to an inanimate object instead? Like a rubber duck?
Fun story — I once bought 20 mini rubber ducks for a team of 5 I was working with, as a cute gag. After bringing each of them one, my partner at the time proceeded to hide the rest in random locations throughout my apartment. I still have some of those.
Take breaks. Seriously.
There’s a mountain of scientific research out there about how taking regular breaks while working is vital. Turns out, working for hours straight isn’t healthy. I have the terrible habit of not stopping until something is 100% complete. Don’t be like me. That being said, it’s REALLY hard to remind yourself to take breaks. Once you get into the flow of programming, you don’t even realize when an hour or two has passed.
The Pomodoro Technique is a popular methodology for scheduling good breaks. I’d definitely recommend looking into it, and following how it works! I recommend getting a phone or desktop app to automatically set these break timers for you. BreakTimer is open-source software which does just this, and is highly customizable! If you want something simpler & in your browser, TomatoTimer is a great alternative!
What works for you, might not work for someone else
While all of these habits may be helpful for me, some of them might be detrimental to someone else. And that’s OK! We’re all wired differently, and the environment that makes one most productive isn’t going to be the same as anyone else. What’s most important is to find what habits work best for you, and try to stick to them.
I’m currently working on a paired project, and my partner and I have discovered that we work in opposite ways — he’s extremely productive before lunch, and I’m more productive after lunch. We’ve adapted how we get work done around this consideration, where he’ll lead paired programming in the morning, and I lead in the afternoon. It has made all the difference in our productivity.
Bonus: Just Keep Coding
During my game design degree program, one of my professors said something that really stuck in my head. “We’re not going to be coding much during this class” she said, “but regardless, I implore you to code this month. Programming is the type of skill where if you don’t use it, you lose it.”
Creating code on a regular basis does wonders for your proficiency. Hell, it doesn’t have to be much. But if I had a dollar for the amount of times I’ve forgotten about some of the most basic syntax of a language from not coding, I’d have… well, a lot of dollars.
Hopefully you found something in here that works well for you! Have other good habits, or feedback on anything I’ve said? Feel free to drop a comment or message me; I’d be ecstatic to hear what you guys do to maximize your efficiency!