To learn, you must ship your code

When working on a project, the temptation is strong to make everything perfect before showing it to the world, or even just to your co-workers. You know each and every line of code you wrote, but you have a long list of bugs to fix and don’t want to expose your work until you’re completed everything that was on your TODO list. Shipping is scary, so you’re holding back with the excuse that you need to fix another bug before finishing.

If you want to make software people use and enjoy, and not just write code for the sake of it, you must get over yourself and ship! I’ve seen people holding onto code for ages, polishing it to perfection, only to leave the job before anyone had time to see the results and give valuable feedback.

The same goes if you wish to get feedback on code you’re doing as a side project. If you’re not shipping, nobody will be able to comment on your code and you won’t know if you’re going in the right direction. Agile methodologies have the right ideas about this. Getting used to shipping small changes will help you fight the urge to keep your code to yourself and having to push huge modifications at once because you’ve been playing it safe.

Also, we tend to underestimate the value of our software. A tool that will help improve business processes will be used and appreciated if it does the job, warts and all. When an application makes people’s work easier, they won’t mind putting up with some bugs for a while until you have time to fix them.

You want to validate with your users that you built the right thing as soon as possible, and there are many flaws you’ll see only when people are using your product. What if the incomplete feature you were planning to spend a few weeks on is not really needed? Better to know right away instead of sinking a lot of time into it.

The caveat is that you must allow time to go back and fix those problems when they’re found. On the other hand, you don’t want to fall victim to “ship the prototype” syndrome: if every time you show a quick and dirty prototype it ends up in production, you must make sure that what you show is solid and well-structured even if it’s incomplete. Shipping something is an important milestone, but it’s not the end of the project.

Overwhelmed? Don’t keep everything in your head

A group of young rabbits in the hutchTasks have a way of multiplying like rabbits, overwhelming you quickly. After a few days on a new project, you’ll go past the point where you can easily track everything in your head. Those undone tasks will hound you and come to mind at the most inopportune moments, distracting you from the task you’re currently working on. And since programming requires a lot of concentration and focus, you won’t be able to maintain a state of flow, hurting your productivity.

Nobody can keep all those tasks in their heads, and you shouldn’t aim to. Fortunately, the fix for this is simple : a pen and a notebook is all that’s required. Always keep them close by and when a new task comes up, jot down immediately what needs to be done and all important details you must not forget about.

It doesn’t need to be perfectly clean and presentable. The point is to help your memory and get those tasks out of your head so you can focus on something else without worrying you’ll forget. As long as you can understand yourself, that goal will be reached. You can enter your tasks in a fancy task management system later, but for this to work well you need to be able to take notes fast at any time, so pen and paper is best.

There are no brownie points for trying to work from memory all the time, and nobody will look down on your for taking notes and being organized. In fact, people will trust more that you’ll do what you’re asked since you’ve shown that you’re paying attention. What’s not impressive is forgetting things that you promised your bosses or your clients because you were so sure you would remember. Also, when asked about your current status and progress, you can just take along your notes and you’ll have a clear idea of what’s going on.

This practice comes from the Getting Things Done (GTD) productivity framework, which is all about tracking and managing your tasks and projects. The methodology itself is pretty large and not suited for everyone but the book is worth a read if you want to improve your own productivity.

The part that’s interesting here is about open loops: tasks that are not necessarily complex, but that keep coming up in your head asking for attention since they are not complete. Once you’ll get used to dumping everything on paperm you’ll close the open loop as soon as you write a task down. Your brain will trust the task is handled since you wrote it down and it’s now in your system. You can then let it go of those tasks since they won’t be forgotten and concentrate on something else.

This should be used at any time, not just when somebody directly gives you a task. For example, you can use it during coding sessions to improve your focus. When you think about something should be done later and you’re not in the right place in your code to write a quick TODO, write it down on your notebook. You can then let it go and go back to the task at hand immediately. You won’t loose your current state of flow and the undone task can stop spinning in your head since it’s been handled properly.

6 ways to code faster and with fewer bugs

Blurred motion of hands typing on laptop late at night, view from aboveIt can take ages to code what looks like a simple feature at first glance. Times flows while you have the impression that you made no measurable progress on that new feature and that everything is hopeless.

Outsiders will tell you that you’re only adding a checkbox or a text field and wiring stuff together, so it should not take this long. Why are you coding so slowly?

Thinking about the time it took to create a new feature as the number of lines of code you need to produce is a mistake, because the part that takes the most time is not typing code in the computer. Your keyboard shortcut skills are not going to help you with all the other things you must do to create the feature like:

  • Understanding how it needs to behave when it’s done,
  • Looking at the existing code to understand where it fits,
  • Choosing the best controls and API methods for the job,
  • Naming and documenting the variables and methods in your code,
  • Testing the feature.

Indeed, I’m not going to give you tips to type code faster or technical shortcuts since those can be found in any technical book about your language or framework of choice. Likewise, there are many great posts about keywords shortcuts and tools for your IDE of choice.

So here are some ways to optimize all the other stuff so you can deliver faster:

  • Make sure you understand what the feature should do properly before you start coding, including those hairy corner cases that you must handle. Things can change, but you’re going to lose a lot more time if you code something and have to start over: aim to do things right the first time.
  • Plan out the big picture of how you are going to implement the feature and what are going to be the names of the most important classes and methods. This is the hardest tip in this article to stick to, but you’re going to be a better coder if you make it an habit to read the existing code to get a better idea of what to do and plan for the most probable pitfalls before writing the first line of code.
  • Break down what you need to do in tiny wins instead of trying to take it in all at once. Doing just one small method at the time and incrementally adding more code as you go on is easier to manage than trying to do everything you’ll ever need in one shot. Ideally, you should always be able to run the application even if the feature is not complete. Don’t be afraid to leave TODOs in the parts of the code that are not done yet so you’ll remember what you wanted to do when you come back to finish it.
  • Make sure that each tiny part is well-formatted, with good names and properly documented. It’s easier to do while you’re writing the method instead of waiting to do it all in the end, and chances are that once you’ve moved on you’re not really going to fix it. This will make it easier for you to use the method and change it as needed since it’s already nice and clean.
  • Keep a piece of paper or a notepad beside you as you code to jolt down things that comes to mind as you work. While you code, you’re going to think about things like test cases, that bit of CSS you need to adjust and how to implement other parts of the feature. You can take a quick note without breaking the flow of what you’re doing and go back to the current task. That way, you don’t need to keep all those things in your head (think GTD) and you’re not going to forget them all if you get interrupted.
  • Don’t hesitate to look for examples of code when you don’t know how to do, but avoid copy-pasting. Rewrite those examples using your own variable names and standards, and take ownership of it by understanding it as well as code you wrote yourself so you can fix it if something goes wrong. Also, if you have bugs and don’t understand what’s going on at first glance, use all the tools at your disposal like reading the docs for the API methods you’re using, using the debugger and inspecting the code of your page to make sure it’s behaving as you expected. There’s no need to try to be tough, examples and tools are there for a reason.

All those techniques will also help you with writing code that has fewer bugs since you’ll know where you are going. Coding more deliberately will help you make the best of your coding time and deliver better features.