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.

Scala at Hello Heart – Adoption and a Bonus Training Plan

At 2016 I gave a lecture about Scala adoption in Hello Heart.

To make a long story short, while I personally really enjoy the language as a developer, we’ve experienced some problems in getting new developers up to speed. The language seems to be extremely frustrating to learn, even to – and I would dare to say especially to – the most experienced developers.

There are several factors that make Scala particularly hard:

The functional ideas in Scala are still new to many developers. While I don’t think Functional ProgrammingTM is necessarily “harder” than imperative programming, it is a new way to think about writing software. Learning ways to think is inherently hard, and the struggle can be a massive ego blow – especially if you are an experienced developer and expect to just “get” new languages easily.

You can end up with wildly different codebases, depending on the language features you use. The Scala language has many features, and it doesn’t constrain you too much in how you can use them. In a typical project, you wouldn’t use them all at once. Ideally, you would choose the subset of the features you prefer, and stick to them in order to achieve consistent style. This means you can see OOP Java-like style in one code base, functional, almost Haskell-y style in another, and any hybrid you can think of in between. Compare to Java code that is quite similar no matter where you look (a loop is a loop everywhere, as my mom would say).

Scala’s syntax is extremely flexible. Brackets? Which do you prefer? Because we do both. At the same time. Or either. Or none. Semicolons? Yeah you can use them. Or not. Hate dots? You can leave them out! Sure thing! Random punctuation marks for identifier name? Amazing! I’ve always wanted a codebase that looks like it was profanityped by a developer with massive anger management problems and an uncontrolled dirty mouth!

All these properties make Scala extremely fun to write DSLs in. And they do, my God, they do. So not only do you need to learn Scala when you learn Scala, you also need to learn the DSLs of all the different libraries used in your project.

All this brings me to my final point, which is that it is extremely hard to just open a source file and dive into the code. Unfortunately, that seems to be a preferred method of learning in our profession. Try that with Scala, and much hair pulling, curse words and cries for help are guaranteed.

So in order to shorten the learning curve, we created a training program that is meant to take a developer with some experience, and teach her everything she needs to know in order to be productive writing server code in about two weeks.

You can find our training plan here, and watch my lecture here:

Functional and Reactive Domain Modeling

When we introduced Scala into Hello Heart, one of our greatest challenges was not having anyone on the team with any kind of functional programming experience. We grappled with functional concepts and how they fit together and ended up with an object oriented/semi functional style code that can’t be considered even remotely good in any of these paradigms.

One of my realisations at the time was that as developers, we do most of our learning by reading and imitating other people’s code. We don’t always realise it when it happens because reading and imitating is what most of us do for a living at the beginning if our career, but when you are required to introduce a new paradigm you have no experience with as lead developer, the lack of that kind of experience becomes apparent.

Another thing I was lacking at the time was some understanding of common functional programming idioms and design patterns. Despite the community’s distaste for GoF, I still appreciate the way it shaped my object oriented thinking and the understanding it gave me of how the different object oriented concepts fit together, and how design patterns can be composed to build  software. I spent quite some time looking for a resource that will give me a similar experience with functional concepts.

I am now reading the book Functional and Reactive Domain Modeling, and it gives me exactly that. The book presents one functional design approach from the ground up and explains the different functional concepts that come into play on the way. While I’m not sure this is an approach I would like to adopt as is, it gives me great insight into the thought process of one functional system designer.

In other words, sh!t functional programmers say is starting to make sense to me.

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.

First Impressions from Groovy and Grails

Well, I took upon myself the task of learning a new web application framework for a small personal project I’m working on. Honestly, this is somewhat new to me. Aside from a short one-night-stand with an organizational J2EE framework[1] as part of my training a couple of years ago, I never had anything to do with GUI or business application development. I was quite excited about the possibility to learn a new language, new tools, new ways of thinking and gain experience with a new type of missions, and I happily set out to see what’s out there.

After a short exploration, I decided to play with Grails (aka. Groovy on Rails) for several reasons:

  • Groovy is written for the JVM, and uses most of Java’s features and syntax, which allows for a smooth entry and fast productivity for a Java developer like me.
  • I’m under the impression that being able to seamlessly integrate several languages over the same runtime is a good thing. I think that every language has it’s advantages. Java is working well, is simple and familiar, and most importantly – gets the job done. Groovy seems like it’s good choice for a scripting language for the JVM, and Clojure[2] seems like a good option when complex calculations are called for.
  • Grails is built upon Hibernate and Spring, which are two frameworks that are widely used in the industry and that I have good, albeit limited experience with. I’ve been meaning to learn more about them for a while now, and well – here’s the chance!
  • Should be faster than other similar frameworks.

Well, having my exams to study for and my daily job, I didn’t have too much time to play with my new toy, but I already have several things to say[3].

While Grails has several IDE integrations, I chose to use Springsource’s STS, which is an Eclipse-based IDE as a development environment. I didn’t take me long to realize it might have been a mistake. Aside from the fact that IDE itself is heavy and slow on my machine, running Grails related commands, and have no mistake – you need to run many during the course of development, requires loading the Grails runtime, which is a slow-slow process. Having to wait several minutes for the simplest of actions to complete really ruins the working flow, and you know how much I like that.
In Grails defense I will say that my computer is almost 5 years old, and that eclipse wasn’t the best IDE choice to begin with.

So far it seems like Groovy is the down-side of this bargain for me. Of course, I’m not well versed in the language yet and I assume things will seem more natural to me as I learn more, but after reading a good deal of the getting started guide (and especially the style guide for Java programmers), I am a bit disgusted. Yes – I admit it, I am highly fond of rigid formalism and I have a slight mistrust in dynamically typed languages as a result, but this is not the issue. Right now the Groovy seems to me like a collection of random features and syntactic constructs that were plundered from other languages and forced to live together without harmony.
I don’t like the fact that there are several ways to write the same code. I don’t like the fact that return statements, parentheses and semicolons can be sometimes omitted[4]. I don’t like the ways methods were added to the JDK, which breaks any form of reasonable design.
Well, you catch my drift.

If you don’t look too hard at the Groovy code, the Grails framework was surprisingly easy and fun to get started and work with. The project is very well structured, everything has its place, most – if not all – the things that you need to do beside pure business logic have already been thought of, and everything is designed to promote good programming practices.
Of course, a good framework is really put to the test when you try to use it in ways that stretch the limits its original designers had imagined for it but I didn’t hit that spot yet so I really can’t tell.

I did have one problem with the framework, from a newcomer’s point of view. Its design relies heavily on the convention over configuration principle, which helps keep the project very clean and the development fast-paced when you know what you are doing, but it really makes it hard for me to learn how things work. When I face a new technology, one of my preferred methods of learning is by “pulling out threads” of software – I find something that I don’t understand, like a piece of code or configuration, and I follow its lead by searching strings in the project sources, configuration or compiled code, decompiling classes where necessary, until I reach some code that I do know.
I like this method because it really helps understand the “guts” of the technology or project you are working with, but with CoC, you have to know the convention to be able to follow the thread, which means that in order to learn I have to… know in advance what I’m looking for?

These are my thoughts on the subject for now. I’m sure they will change over time as I’m still green around the edges[5].


[1] Which, admittedly, was quite advanced for its time
[2] Which will probably be the next language I will try to put to practical use
[3] This statement shouldn’t surprise those who know me, and the fact that the real challenge with me is to make me SHUT THE F#@& UP!
[4] And sometimes not?! They make things formal, dammit!
[5] Pun intended

Getting Fit, Keeping In Shape

I think that all the programmers I know want to get better at what they do. In fact, I think that every professional who takes pride in her work, not just a programmer, wants to get better at what she does. Sadly, I figured long ago that just by doing my work and following my daily routine, I will never be able to advance in a way that satisfies me.

This is why I’ve resolved to taking active steps towards my professional development.

Surrounding myself with bright people

I think that being surrounded by smart people with whom we communicate and work well is crucial for our development. I’ve learned so much from the people I work with, and I’m not talking only about technical knowledge and methods – by comparing myself to the people around me and finding our similarities and differences, I’ve been able to find out what my strengths and weaknesses are, and highlight my strengths while working on the things that need improving.

Working on my BSc in Math and Computer Science

It is a known fact that in the Israeli IT market, if you have the right kind of military experience, you don’t need a BSc in CS in order to get a job and advance to many positions. However, I feel that the broad formal education you get in the university often proves useful in unexpected situations.

Further than that, I hope that later my education will enable me join a research position in the field.

Reading

I make a point of always reading a book or a magazine that may broaden my horizons: it can be a technical book, a book about project management, general management (I’m currently working my way through Harvard Business Review‘s essays bundles, they are quite fascinating), or any other type of book that seem like it can open my mind to new ideas, or spark my creativity.

Working on pet projects

This is something that I learned from the guy that is sitting next to me. I always say that programming is a job that leaves you with a lot of free time. This is why I always keep an IDE open in the background with some pet projects, which I use to explore concepts that I find interesting, or features that may contribute to our product but I am not “formally allowed” to code.

Following technical blogs

I try to find interesting people whose opinion I value, and follow them online. I consider this an extension of the “surround yourself with bright people” principle to smart people who live oversea and have no clue that I exist.

Writing a blog!

Having to communicate your ideas often makes them clearer in your head. Writing a blog is a way to deal with subjects you may not normally talk about with your peers. In addition, when I worked on some of the (unpublished) technical articles for this blog, I faced the fact that I had some gaps in my knowledge, which I had to fill in order to complete my writing.

As an added bonus, I am also forced to slowly but surely improve my English skills.

Teaching

Similar to writing, teaching forces you to communicate with your students. Teaching also pushes you to always learn a bit more than what you already know, because no matter how knowledgeable you are, your students will always find a way to surprise you with questions about this extra bit of information you’ve neglected.
I haven’t taught for a long time, and I really miss this experience.

What about you? How do you get fit and keep in professional shape?