3 Simple Ways to Get Your Programming Flow Going

Also published on Medium.

It’s a well known fact in the software world that your productivity as a developer is not linear in the time you spend programming. What this means is that in 4 hours of code writing, you will produce significantly more code than x2 of what you produce in 2 hours of coding.

That happens due to the “Flow” or “Zone” effect. If we are lucky, after coding for a while we go into a “Flow State” where we are uber-concentrated, become one with the code and the loops and conditions stream effortlessly from our brain into the IDE without passing through our fingers. When we are in a flow state we write code faster, better and with less mistakes.

Getting into a flow state is hard, and interruptions and distractions take us out of it immediately (which is why open plan offices are the bane of developers productivity). However, getting into the flow and maintaining it is a mental skill that can be honed, and there are several tricks that help me when I need to do it fast.

Have a Ritual

Rituals are technical things we can do to help our brain quickly snap to a new situation due to the sheer familiarity of the process. I like to:

Move to a quiet location. This is especially important if you are likely to be approached with questions at your desk. If you are a manager, set clear expectation around where you are available and when you need quiet time. Your team should and will survive without you for a couple of hours, I promise.
I like to use the couch in front of the window at the side corridor as my quiet place, so you go and find your own quite space.

Make a fresh cup of coffee. Self explanatory, duh.

Switch off notifications. Your phone should be on do not disturb mode. Close those social media tabs. Close your email client. Turn off browser notification. Seriously, nothing interesting happens there anyway.

Close unneeded windows and tabs. Isn’t it nicer to work in a clean environment? Plus, less chance for distractions and less junk on your RAM.

Remove your shoes. Because how can you write software while wearing shoes?!

Use Mental Reminders

It’s easier to snap back into flow state when you have reminders to where you left off the last time you wrote code.

Draw a design/architecture diagram. I have a notebook of architecture diagrams that I create for my projects. Whenever I need to get back to coding I look at the diagram for the code I am writing and add some details to it, and it helps me to quickly get thinking in design again.

Write where you left off. *Inside your source code*. I have a friend who likes to write inside the source code what he was doing before leaving the office at the end of the day. This way when he comes in at the morning and tries to compile the code, the error messages force him to read the comments and help him pick up where he left off.

Do Some Warmup

Switching between mental states is just as hard and switching between physical states, but where the sports world already realised the trick of using warmups to help these transitions, we keep trying to jump between mental tasks with no adequate preparation and being surprised that we are not very effective at it.

Whenever I start a new task or get back to programming after a pause I tend to feel “lost”, as if my brain is not used to thinking in code anymore. Taking on a simple programming task helps me realign my brain. Here are some simple things I like to do:

Document some code. In them olden days when it was common practice to *gasp* comment your code, I liked to find some pieces of code that weren’t as clear as they should be and document what they were doing. These day I just lightly edit some code to make it self-documenting.

Refactor some code. This is a great passion of mine. I like to start every task by lightly refactoring the code in preparation for the new feature I am about to implement. It’s fun, it helps maintain a high quality code base over time and as a bonus your manager can’t complain that you are wasting precious time on refactoring instead of delivering features.

I like these options because they help improve the project over time, but if you are not excited about any of my options:

Find an unrelated coding task you do enjoy. Coding quizzes? Amazing. Developing a small game? Super cool! Implementing a small feature? Awesome. Anything that gets you thinking in code instead of in human.
Just make sure that the task is well contained and that you are not likely to spend more than ~30 minutes on it, else it will lose the benefit of helping you become more productive in your actual job.

Development Superpower

When a state of flow has such a major effect on your development productivity, being able to get into it quickly and maintain it is a development superpower. It helps you complete your tasks faster and better, makes you more effective at works and leaves your free time to be, well, free.

I’d say it’s a skill worth honing.

Advertisements

Programming Warm Up

In software development, productivity is all about getting in the Zone. When You are in the Zone, you are one with the code and writing software is easy as typing. When you are not, a whole day can pass without doing much work because thinking is just so hard.

One of the things I do to get myself into the zone are little “warm up” sessions before I start to code features that are hard for me to approach. I choose small problems that I particularly enjoy as warmups. Little treats, you might say. For example, I may start programming a feature by refactoring some remotely relevant code, commenting on legacy code around it or focusing on a small part of the feature that seems interesting.

To the outside viewer (a.k.a my boss when I was a developer) it may appear as though I’m wasting time on things that are not the core of my work – “We have no time to invest in code refactoring right now, we should ship this feature”, but I argue that this time is not spent but invested in making the development faster, and that the time it takes to develop the feature after investing it is much shorter.

Think about it – in many other areas of our life, the concept of warm up is very prevalent. Athletes warm up before an exercise to make it more effective and less dangerous. Singers warm up their vocal chords and musicians warm up their fingers before a show, and when I took an animation course, we were taught to start every day with a several minutes quicksketching session to get our creative juices flowing.

Why should programming be different?

Concentration and focus is a problem of acceleration and when you try to move from 0 to 100 kmph you should take the car that gives you the largest boost at the shortest time, and this is what programming warm up is all about.

Quality Code 101: Debug It!

Don’t even think about releasing a piece of code, if you haven’t stepped through every line at least 50 times with a debugger.

What? Are you serious? But I have written so many unit tests!

It is true, unit tests are an important aspect of long-term code quality, but they are just not enough. When you write a unit test, it is too easy to become optimistic and be absolutely sure that certain parts of your code work[1].  It is easy to forget the internal workings of your code, and skip some edge cases, and unless you write and execute school like test suits[2], it is too easy to leave things out.

Is there a correct way to do it?

When you step through your code, stop before every line you execute, and try to think what you expect it to do. Execute the line and compare your result with the expected result. Work in several abstraction levels. Debug every line of the method you’ve written. When you think it is working fine, treat it as a black box and debug the methods that call it without stepping into it. Sometimes code that seem correct in one abstraction level, will turn out to be faulty when you examine it from another[3].

Hila, you are so smart! I’ve found a bug!

Why, thank you! *brushes off an imaginary hair from face and beams graciously*
Now turn it into a unit test. Why? Because the next thing you will fix will probably break your code again. Run your test, make sure it fails. Fix the bug, make sure the unit test passes.

Ok, my code looks like it is working now. Can I stop debugging?

Nope. Go ahead, run it again. You will find another bug.

Arrgh! This is so much work!

Too bad, writing quality code is what you are paid to do. If you don’t like it, I heard Walmart are recruiting now.

Isn’t it better to spend the time implementing cool new features and having my QA test the code?

No, from several reasons. They cannot do it as well as you can. Not because they are stupid, but because they don’t know your code as well as you do. In fact, even the future you cannot do it as well as you can. If you move to another task and postpone cleaning up after yourself until you get your inputs back from QA, you will definitely not remember all the little details of your implementation, and these bugs will be a lot harder and a lot more costly to solve. And finally – it is not the QA’s job to find these bugs, they have more important things to do, like making sure the whole system is functioning from the user’s perspective and testing the overall design and integration points. If they have to deal with the bugs you were too lazy to fix all day long, when will they have time to do the real work?

Trust me, step through your code (and wear sunscreen). Your QAs will thank you. Your future you will thank you. Your manager will thank you. Your users will thank you. I will personally thank you.  Your neighbor’s cat will…

Hila, can I ask you something?

Yes, yes, I am implementing a new subsystem now and I’m finding trillions of funky bugs by stepping through my code.
Now go away! I’ve just hit a breakpoint!

[1] How can they not work? you wrote them!
[2] Let’s face it, you don’t
[3] This is why we are debugging as well as writing unit tests!

Being a Programmer while Afraid to Code

It happens to the best of us. You have a task to complete, you have a deadline, maybe something important like a deal with a big customer depends on you completing it on time and your boss is at your neck. You look at your code, it seems all dark and complex and tangled, little bugs that lurk at the corners of your IDE threaten to jump out from the screen and byte you[1]
and…
you get scared.

What do you do then? How does it affect your work? Should it affect your work?

When I was little, my mom used to tell me that I should always strive to make my important decisions in life based on choice, and not on limitations. When I grew up and studied art, my teacher told me that in order to build my own style I need to master my technical skills so that my style will be an artistic choice, rather than the sum of my inadequacies. The same principal applies here: you can’t program based on fear.

If your design and implementation decisions are guided by questions such as “Do I know the technology well enough to program this?”, “Do I know our product well enough to find the source of this bug?”, “Will I be able to design a plausible solution for this demand?” instead of “Is this the right technology/solution for my problem?”, “Is this course of action worth my time and effort?”, “Which strategy is most suitable for our needs?”, then you are not guided by what is best for your project, you are guided by what you can’t do.

Now, don’t get me wrong. The first set of questions are valid and very important questions, and we must ask ourselves these questions all the time, but they need to guide our self improvements attempts, not affect the way we code daily.

For instance, lets say I need to fix a bug in our product. I may decide it is best to dig for the root cause of the bug and fix it, even if it means refactoring some parts of the system (if it’s the beginning of the development cycle and I can take risks). Alternatively, I may decide the best approach would be putting a band-aid on the symptom and leaving the investigations for later (If this deal really depends on me releasing the darn patch already). It doesn’t matter what I decide – the most important thing is that I have a choice.
But if from some reason I am afraid to take one of these courses of action, then my hands are tied and I no longer make my choices based on what I think is best. For instance, if solving a bug requires me to refactor the system and I’m afraid to do that due to any number of reasons – either because I don’t know it well enough, because we don’t use source control in the company or because we have no automated testing and it is impossible to know whether I broke something in the process, then I have no choice but to use band-aids. If I do this for enough time, the software will reach such level of entropy, that even in my best intentions I will not be able to approach it without fear because every little change I make will have a rippling, uncontrollable effect.

This is why you must always strive to reduce your fear and increase your choices; because you can’t tame lions if you are afraid of cats, you can’t be a pilot if you are afraid to fly and you can’t be a programmer if you are afraid to code.

[1] Not funny, I know.

Wise Quote of the Day #1

The bottom line on inlining for performance reasons is the same as the bottom line on any other coding technique that’s motivated by performance: profile the code and measure the improvement. If the anticipated performance gain doesn’t justify the bother of profiling the code to verify the improvement, it doesn’t justify the erosion in code quality either.

Code Complete/ Steve McConnell.

Mind the Debug Message

Consider the following scenario:

MyObject obj = new MyObject();
log.debug("Created an object: " + obj);

This code seems innocent enough. If our logging is set to debug level we will print the message, and if not we won’t print it. Right?

Wrong!

This piece of code is actually quite harmful, especially because it looks so innocent, and may actually cause a major performance problem in your application. For instance, what happens if MyObject’s implementation of toString() is really heavy? This can happen, for instance, if MyObject is a very complex type, it’s string representation is heavy and in order to built it we have to iterate over many objects. In this case, that line of code will do this heavy processing every time it is run, and you will have to pay the performance overhead no matter what your log level is.

This is why it is much better to make sure your logging infrastructure allows you to do something like this:

// Print out one object
MyObject obj = new MyObject();
log.debug("Created an object: {0}", obj);

// Print out several objects
log.debug("Created some objects: {0}, {1}, {2}", new Object[obj0, obj1, obj2]);

and then formats the message with MyObject’s toString representation only if the debug level is high enough. This way you will pay the performance price only when you choose to do so.