DEV Community

Bart Karalus
Bart Karalus

Posted on

Seven useful programming habits

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!

Top comments (30)

Collapse
 
pattyguereca profile image
Patty

Any tips on where I can find programming exercises?

Collapse
 
conchakiing profile image
Anthony

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

Collapse
 
pattyguereca profile image
Patty

thank you!

Collapse
 
johannesvollmer profile image
Johannes Vollmer • Edited

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.

Collapse
 
tyronepost profile image
Tyrone Post
Collapse
 
dev3l profile image
Justin L Beall

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.

Collapse
 
andrespineros profile image
Andrés Felipe Piñeros • Edited

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.

Collapse
 
binaryforgeltd profile image
Bart Karalus

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.

Collapse
 
jorinvo profile image
jorin

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.

Collapse
 
ohnonapples profile image
Pine Apple

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.

Collapse
 
damcosset profile image
Damien Cosset

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.

Collapse
 
val_baca profile image
Valentin Baca

"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

Collapse
 
binaryforgeltd profile image
Bart Karalus

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. :)

Collapse
 
julichala profile image
El Chala

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.

Collapse
 
sanguine8082 profile image
Aaron Pfalzgraf

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.

Collapse
 
binaryforgeltd profile image
Bart Karalus

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. :)

Collapse
 
legolord208 profile image
jD91mZM2 • Edited

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...
Collapse
 
changemyname profile image
Evgeny

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.

Collapse
 
lewismenelaws profile image
Lewis Menelaws

"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.

Collapse
 
kinbiko profile image
Roger Guldbrandsen

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.