loading...

Seven useful programming habits

binaryforgeltd profile image Bart Karalus ・3 min read

This short entry was also published on my personal website

I have been reading some good books on forming habits recently. After digesting these, my mind started drifting further and I started thinking what my current habits are. Some of them are applicable to life in general, some relate only to work. Without surprise, some of them happen to be strongly related to programming, which I think might be a good thing to share.

  • Uncontrolled auto save. This one has been accompanying me for ages. Even though many modern IDEs do not even require saving a file, I am relentlessly squeezing "Ctrl + S" combination to its last…drop. If I recall correctly, I am doing it thoughtlessly every time I stop typing. Weird but it actually saved my day more times than it caused a smirk on my colleagues faces.
  • Some devs tend to say being in "the zone" is like being in Nirvana or finally reaching the Valhalla. The way I see it is more like Berserk mode. It is great for some time but then you should take a break to recover. So basically short zone bursts are great for performance but make sure you take regular stops. Being in a zone for too long can actually numb your senses and make your mind more vulnerable to get stuck in a loop. (no pun intended!)
  • Make sure you kill all the sources of disturbance. When I work on something really important I will turn my phone off, avoid social medias or any medias in general with a slight exception for music. Apply everything in healthy limits though. If you have got kids and need to focus, locking them up in a basement might sound appealing but it is not really a good solution in longer term.
  • Always try to start with an end in your mind. Some people say the power of visualisation is priceless. It helps me determining realistic list of goals for today and eventually leads to reducing or removing frustration and disappointment at the end of the day. So anytime you work on something, make sure you know exactly what is it that you want to create. It might sound obvious but it is really one of those steps being skipped way too often.
  • One good habit for me is regular training. Even though going to the gym is another great habit, in this case I am more worried about one's actual programming skills. I enjoy solving occasional programming exercises in order to keep my saw sharp all the time. It might not pay your bills but will definitely pay back in future.
  • One of my most recent ones is trying to start writing any code from forming some test cases. This one is sort of related to one of my earlier points as it helps me seeing my destination before starting. It obviously makes the end result safer but as a bonus it often helps designing and documenting the code. I am actually surprised so few developers can appreciate this point of view.
  • Another fresh one for me which is to avoid "future programming". Start small and grow later. In my earlier days while coding anything I wanted to make it perfect from the very first day, cover all the possible edge cases and almost prepare it for my descendants to use. With time I realised it often leads to overcomplicated codebase, high time consumption and in most cases my program is doing everything and nothing at the same time!

So here, take any of these for yourself if you feel like it. These I have found insanely useful on my programming path but forming them is not an overnight change. The best and only way to implement a habit in your life is to just start using it and it will settle down before you realise.
Ah, do not forget to let me know about other habits that worked for you!

Posted on by:

binaryforgeltd profile

Bart Karalus

@binaryforgeltd

Developer during the day, programmer in the night.

Discussion

markdown guide
 

Any tips on where I can find programming exercises?

 

Codewars.com is a cool site with a bunch of exercises

 

Code wars is a nice site, but the exercises are only little algorithms. Sadly they can't reproduce the experience made with an (even little) completed project.

 
 
 

Avoid "future programming" -one of the strongest points here that seems counterintuitive, but is fundamentally critical.

Simple designs are future proof... complicated designs anticipating an unreal future are messy (not clean).

"Last Responsible Moment" - The key is to make decisions as late as you can responsibly wait because that is the point at which you have the most information on which to base the decision.

 

I've been here so many times that I'm actually ashamed.

First think of the Minimum Viable Product (MVP). Give functionality to yourself or your client. THEN, when things are working worry about improving them.

Trying to create a perfect design from the start is impossible, mainly for one reason: we often don't really understand what the client wants, and neither does the client. When we work on small functionalities that grow and improve over time, we give ourselves (and the client) time and experience to understand the domain of the problem and understand WHERE the software needs to be improved for real.

 

Great input. I heave heard something like that somwhere... not sure where though. Take your time to make a decision and decide late, but then execute fast.

 

In line with these practical habits, I would add the habit of thinking in commits: Even if I work on non-programming projects I put the project in a git repo and I structure my work in steps doing one thing at a time, commiting and then reviewing the changes.
Doing work without committing it after feels like I haven't finished it.

 

I think I share your point of view about being "in the zone". To be honest, Being in the zone as a developer doesn't look all that attractive. I always thought as "the zone" as a state of mind where you are performing at your highest level, doing things you already know.

As a developer, you might want to always reach outside your comfort zone. Not always, but a reasonable portion of your time should probably be spent stretching your comfort zone, feeling uncomfortable.

 

"Flow" is not doing things you just already know. It's when your skill in an area is high and when the challenge is high as well.

This graph, from the wikipedia article on Flow sums it up succinctly: en.wikipedia.org/wiki/File:Challen...

What you're describing is more in the "Relaxation" section

 

Thanks. You are right but I believe we all, devs or not, should aim to keep on stretching the comfort zone as it seems to be the best way to grow. :)

 

I also started "writing any code from forming some test cases". Basically after I create a method in an interface, I leave it unimplemented. Then I create a test class with various test scenarios so that they all fail first! I will work on the implementation till all test cases pass.

 

I love doing desktop tests with paper and pencil for complex functionalities with lots of logic. This helps me understand and better document my code.

 

I do this too! It's usually to try and understand what code someone else wrote is doing.

I'll take the excerpt I'm stuck on, print it out, and then draw lines between function calls, highlight areas, etc.

There really is something different about having it physically in front of you.

 

That is great! It is sometimes good to write or draw our thoughts down on a good old piece of paper. They appear to make more sense when we can see them with our eyes. :)

 

Yea, I have bad habit. Sometimes my mind drifts away to other thoughts, when I read. If anyone has something similar, would want to know how you deal with that. Personally I end up re-reading the paragraph.

 

"So basically short zone bursts are great for performance but make sure you take regular stops."

Couldn't agree more. Not only this, but failing to do this could lead you into burning out for weeks.

I was once working 2 jobs, a mall job from morning to afternoon and coding from afternoon to night. I would never take breaks.

I got the project done but by the time I was 80% complete I was working only at 50% efficiency. I tired my brain out. Especially since it's staring at a screen all day.

Great write-up Bart.

 

Oooh! On the note of auto-saving: I do that too, and moving to IntelliJ which saves on my behalf was annoying at first. But! I found a trick: Make Cmd+s/Ctrl+s run your last test. This works regardless of programming style, but it gives you super powers if you're doing TDD! It also subconsciously validates that your files have been saved as they must be saved to be executed.

 

Eight useful programming habits:

  1. Always add semicolons. It's easier to automatically remove them than having to later relearn the habit to add them...
 

These are all great tips.

Uncontrolled auto save

I see a co-worker using this and it seems so weird to me, but you and he seem to love it.

 

Thanks Ben! I know it seems weird but at least it does not make any harm.

 

I do this, it's also saved my bum a few times.
Sometimes I get carried away and save my browser. lolol.

I did that twice today. Accidentally saving my served files that I'm only occasionally demoing in the browser. It's embarrassing when you're showing a teammate a bug you're currently trying to fix.

 

Great article!
This Ctr+S habit is a real lifesaver.

 

Do not under estimate the power behind a sound-proof basement. We architects would rather say "it's a trade off" ☺

 

Great list! . One habit that I have is to have a notebook and a pencil to write all sort of things and sometimes to draw some quick code debbug.

Yap cmd+s is Life.

 

I often tend to create wrong assumptions and take them for granted while spending too much time in there. Thanks!

 
 

Thanks! The book I had in mind while writing this was Stephen Covey's "The 7 Habits of Highly Effective People" and although it is definitely worth reading, it has got nothing to do with programming. :)