Month: October 2021

From the outside, programmers seem to resemble the machines they program – cold, emotionless, unmoved.  But the reality is different – most moments in programming are full of emotions.

What are these emotions?

Confusion. Much of the time, I am confused by code. Something is working differently than I expect it to, or I can’t get my head around a line of code.

Anxiety. When the context of the project is stressful, deadlines are near, and I deal with a complicated piece of code, I tend to feel anxious.

Shame.  When I discover that something I wrote some time ago is faulty, I feel ashamed. Or when somebody finds an obvious mistake in my pull request.

Irritation.  When I am confused for too long, or somebody nit-picks my pull request. Or when something takes much longer than I expected – which happens often.

Hesitation.  Sometimes I feel like in a dead-lock, unable to decide between different choices with complicated or non-obvious trade-offs.

Inadequacy. When I need to step outside of my comfort zone, I am often baffled by how small that zone is. On a logical level, I know that I can’t know everything and nobody expects me to, but it still makes me feel bad.

Silliness.  Sometimes I find out that a solution to a problem is hiding in plain sight, and I feel silly.  It is often accompanied by relief.

Satisfaction. Every time something works the way I expected it to, a jolt of satisfaction kicks in.

Excitement.  When I discover a new way to do something.

Hope.  For a short moment in the middle of my feedback loop, when I just coded something and I’m waiting for the screen to refresh or for tests to pass.

Pride.  When I made something neat or something worked on the first attempt.

Relief.  When I solved a problem I had been struggling with for a long time.

Is experiencing emotions much different for different programmers? I don’t know; I have direct access only to my own emotions.

Are emotions bad? No. They are necessary to get going.

Some of them are harmful, and some of them are more useful than others.

Anxiety, inadequacy, and shame are just not helpful in programming.  It is good to reduce them if we can.

Confusion, irritation, and hesitation are rather negative emotions per se, but they can be useful or even necessary.

If you are missing something in your mental image, you should feel confused. That’s how you know you need to explore.

Irritation, in small amounts, can lead to positive action. But it only works if you are irritated by something within your control.

Hesitation can be harmful when you spend disproportional time making decisions, but some hesitation is useful to signal that you need to proceed carefully.

Positive emotions are obviously helpful.  They make the act of programming palatable for humans.

But they can also lead to non-optimal behaviors occasionally.

Programmers are often choosing things that are exciting rather than important. Chasing the newest frameworks and programming languages is a huge timesink.

Pride can cause us to ignore the shortcomings of an overall neat solution.

Relief may fool us to stop being careful.  And it never pays to be careless when programming.

What other emotions do you experience when programming? Do you experience emotions differently than I do?  Let me know.

When committing to a piece of software, favor those created by people who value backward compatibility.

By “piece of software,” I mean any source code dependencies (libraries, frameworks), runtime dependencies (e.g., databases, web servers), or tools (e.g., editors).

Different projects have different cultures of preserving the stability of programmable interface, user interface, and default behavior.

Why should you care?

Stable software is less work down the road when it comes to upgrades.

Stable software is better understood.  Documentation and third-party guides will stay relevant longer; lessons learned will remain valuable. Trade-offs are acknowledged.

Third-party plugins will keep working.

It is probably tested better.

If you have to deal with an older version (e.g., because you are restricted by repositories available on production servers, or you have to downgrade for security reasons), you’ll stuff will still work fine. Also see: Would your code work after a trip back in time?

Many of these aspects have characteristics of compound interest; if the community around software can safely assume that their guides and plugins will stay relevant, its members are more likely to contribute.

How to tell if a piece of software is likely to remain stable?

Age.  If a piece of software is old but still in active use and maintenance, it is more likely that its creators got something right and kept it stable.

Marketing copy.  Look at the project’s website; sometimes projects are explicit in what they value, and it is not always the stability.

Size and scope.  The larger the scope, the harder it will be to remain stable.

Version history.  For projects using SemVer, frequently changing major version numbers is an obvious red flag.  Note that many old, stable projects don’t use SemVer.

Upgrade guides.  If they are long complicated, beware.  But, of course, a total lack of upgrade guides is not a good sign, either.

Of course, there is a flip side; you do miss on bleeding edge.  But it’s OK – just because something is newer does not automatically make it good.

I’m surprised that more people don’t consider stability when picking dependencies. I would be more understanding of people who were consciously choosing projects that don’t value stability. Still, many times when I see somebody picking a new library, they don’t even try to estimate how stable it is.

Even when using a stable project, don’t rush to get dependent on the latest features because they are less likely to be stable, well understood, or available if you are forced to use an older version.

And one final piece of advice: don’t ever let your career depend on an unstable platform and tooling unless you directly profit from that instability.

How to code when you’re tired

In the past, I was experiencing some sleep disorders that affected my focus during waking hours. However, since I had to wait a few months before getting the treatment, I thought it would make sense to adjust my workflow temporarily.

It should be obvious that you want to fix the underlying problem, but if you don’t have a choice, I propose a few things you can try (at least temporarily).

I’m not making assumptions as to what your underlying issue is, so research that separately.

The first things that suffer from being tired are short-term memory and the willpower to ignore distractions.  It is also easier to experience anxiety.

Cut feedback loops as short as possible.  If there is some action that you need to wait for, see if there is a way to speed it up, e.g., by setting a temporary keyboard shortcut.

Do not multitask—close apps that are not necessary at the moment and full-screen your editor.

Turn off all non-essential notifications from your devices.

Split tasks into smaller parts.  Name them and write them down. Prepare your environment for a particular task (e.g., rearrange windows or set up temporary keyboard shortcuts). Then execute the parts serially. This way, it is easy to return to the task if you take a break or get distracted.

Take breaks regularly and ask what you are doing. Make breaks more frequently than when you would without being tired.  E.g., work for 25 minutes and take a 3-minute break.  During the break, ask: what was I doing for the last 25 minutes? Why was I doing it?  It’s too easy to get carried away by yak-shaving when you can’t remember what’s the end goal.

I also suggest experimenting with a slight variation: if you hear a timer beep, but you feel “in the zone,” skip the break, but don’t do this more than once in a row.

Write. Things. Down.  Have a notepad or a tablet with a stylus.  I use an iPad with Apple Pencil and Concepts app with its endless canvas feature.  Draw diagrams.  Make something you can look at if you get lost.

Write more code comments than you usually would.  Unlike the usual comments, they are only meant as immediate, temporary help in remembering what’s left to be done in a particular code component. You can delete or edit them later if you believe that the code is expressive enough.

Plan at least 2 (sub-) tasks ahead.  If I only plan 1 task, get it done and take a break, I tend to feel anxious because it’s unclear what comes next.  So I define one extra step ahead so that I always have clarity about what to do next.

There are also a few somewhat weirder things that work for me, but I’m not sure if they would work for everybody:

I have syntax highlighting disabled in my editor.  The color soup of a regular IDE is too distracting to me.  It takes time getting used to, though.

Learn to type fast so that you don’t have to hold things in your head for a long time.  It’s somewhat controversial, and a lot of people feel that learning to type fast is not worth the effort, but I do believe that being a competent typist helps save mental energy on what really matters.

Work in a well-lit room.  However, some prefer the opposite.

I prefer silence or gray noise to music when I’m tired; I’m fine listening to music and code when I’m not tired, though.

For some reason, sometimes, I find it easier to work on smaller screens.  I guess the brain has less to process when the amount of information on the screen is limited.

Most of these tips are applicable even when you are not tired since the short-term memory and willpower needed to ignore distractions are always a limited resource.