Ask HN: What Programming Habit Changed Your Code for the Better? | Hacker News Reader

Ask HN: What Programming Habit Changed Your Code for the Better?

4 pointsalexliu5182 comments

Hey everyone!

We often talk about tools, languages, and new technologies that help us improve our coding. However, today I'd like to focus on the habits and practices that make us better developers.

1. *What is one programming habit you’ve adopted that has significantly improved the quality or efficiency of your code?* 2. *How did you come to adopt this habit, and what impact has it had on your development process or outcomes?*

This could be anything from a specific way you comment your code, to how you structure your workday, to a particular approach to debugging or testing. I'm looking forward to learning about the routines that have made a real difference in your work!

View on HN

Writing the design doc before writing the program. I was "gently forced" into that at a past job. When I write a design doc, I think about a problem in terms of the problem, rather than the (arbitrarily) chosen tech stack. As a result, the solution is (in)validated quicker, the program is simpler, better fitting the problem and significantly easier to understand, and the programming phase converges to a reliable solution much faster.

Tooling

When your text editor is not enough for a task, and it hopefully is extensible, consider writing little plugins to reduce repetitive tasks.

Here is an example. I was working with a legacy code base using an infamous Scala actor framework. Basically, all function calls were replaced by message passing. All messages were sent as 'Any' objects, then downcast to the expected type, so an IDE wasn't of much use. I wrote a little bash script to populate a jump buffer in vim with the result of a grep, and suddenly, I had jump functionality! Originally, I had to jump to type definition, hope that the associated "received message" type was in the same file, then look for downcasting into that received type. I don't remember precisely the details, but what I do remember is that the little script helped go from a few seconds to just pressing two keys to navigate the code. It's especially useful for legacy code, where the main activity associated with it is reading and understanding.

Our capacity to focus as humans is limited in time and energy. Writing tools to do in half a second what otherwise would take a few seconds can help, not only to make you faster (for that, refer to xkcd 1205) but also to effectively increase your capacity to focus.

Though being able to develop your own tooling is less important today. Languages and frameworks nowadays prioritize tooling as an important feature. And I'm grateful for that, programming used to be much more annoying.

Reply on news.ycombinator.com