One of the things that comes up repeatedly in your career is whether your edge is sharpening or dulling.  It is very easy to get into a pattern when you are at work and not have to change your approach, especially if you are performing at or near the top of the pack.  You can always find a way to improve performance though, and a lot of times it's "I should (and do) know better, but haven't applied the knowledge yet".

Ultimately the problem is called Metaheuristics. Viewed in aggregate, the learning behaviors of programmers is a sort of Memetic Algorithm.  This must also be balanced against the constraints of the current economy.  Namely that for many problems, throwing hardware at the problem is cheaper than throwing money at programmers to fix the problem with existing hardware. This means that you have to converge on "good enough" and "worse is better", and tools/methods that don't fight this.  This can be hard to do emotionally for engineers, as we all want to build great works.

What seems to work best for me these days is writing essays about systems I'm considering designing, and revising it as I go to make sure the narrative remains consistent.  I feel this actually captures the idea of "user story" a lot better than the trite one-liners which are actually user acceptance criteria.  Storytelling is how our brains actually work, and initially the story is hopes and predictions (much like the program going with it) eventually annealed down to reflect reality.  It doesn't hurt that this builds documentation and test cases as part of the process.

Crush everything getting in the way of work

The first thing I had to master as a programmer was how to build an environment which prevents or mitigates the costs of interruptions to flow state. Much of this involved learning interfaces and editors such that I could largely do my job without expensive context switches, like having to touch a mouse.  The two best means I've found to do this are Tmux + Vim + guake-ish terminal emulators and VSCode + virtual desktops with most the IDE features like suggestions turned off.

There are 4 primary features here:

• 100% keyboard controlled navigation and context switches
• Good syntax hinting
• Remembering state between sessions
• Full-screened everything, focus on only one thing at a time

I have to have a solution for every major OS, as this is a necessity for testing software properly.

On Linux I can pretty much have everything I need on one to N+1 virtual desktops, where N is the number of browsers I need to support, plus one window for doing documentation lookups (usually on a second monitor).  I do most of my development on linux for precisely these reasons.

This mostly works the same on OSX, however they break immersion badly for people like me by having:

• different and non-configurable keyboard shortcuts
• window decorations in nonstandard locations
• virtual desktops no longer have consistent ordering between sessions after 10.6.

They seemed to have optimized for the user which Alt+Tabs between 700 open windows in one workspace, which is a good way to break flow with too much clutter.

On windows VSCode has a good shortcut to summon the console, and a vim plugin that works great.  Windows virtual desktops also work correctly, and I can configure shortcuts on linux to match both it and the console summon.  I would prefer it be the other way around, but commercial OS interface programmers tend to either be on a power trip or too afraid of edge cases to allow user choice.  If I could have a tmux-like shortcut to page between vscode workspaces like I do panes I'd be a happier camper, as I wouldn't need as many virtual desktops.  This is apparently their most popular feature request right now, go figure.

_ is other people

Beyond the little hacks you do to increase flow, mitigating the impact of interruptions is important.  This is a bit more difficult as much of this is social hacking, and understanding human nature.  The spread of computing into the general population has also complicated this as the communication style of the old order of programmers and engineers is radically different from the communication norms of greater society.  I, along with much of the rest of my peers, are still having a difficult time adjusting to this.

The preferred means of communication for engineers is information-primary rather than emotion-primary.  The goal of communication is to convey information more than feeling (if that is communicated at all).  The majority of society does not communicate in this fashion.  Instead they communicate Feelings above all else and Information is of secondary (if any) importance.  For these people, their resorting to communication of information is a sign of extreme frustration that you have not yet discerned their emotional message and provided the validation they are seeking.  If they haven't already lashed out, they are likely on the way to doing so.

It is unfortunate to deal with people operating via a juvenile and emotional communication style, but this is the norm in society and over the last 20 years has entirely displaced the existing engineering culture at every firm I've worked at.  Code reviews can no longer be blunt, as it is unlikely you are dealing with someone who is not seeking validation as part of their communication packets.  The punky elements of culture which used to build friendship now build enmity (as you are dealing with the very "squares" nerd culture embraced being hated by).  Nevertheless, you still have to walk in both worlds as there are still islands of other hackers just like you.  Taking on and off these masks is risky, however, as people are quite hung up on the notion that people must be 100% congruent with how they are perceived outwardly.

Everyone out there building an online reputation learns quickly that courting controversy will get you far more engagement than if you had made a program which cured eczema and allowed sustained nuclear fusion. Emotional highs punctuated by warm fuzzies is generally the sort of rollercoaster ride people are looking for.  Lacking better sources they will attempt to draw you into their emotional world.  Their world is a skinner box, and if you enter it unawares they will train you.

They cannot help but be this way, so you must turn off the part of your brain that looks for informational meaning in mouth noises.  Their utterances have little more significance than the cries of a baby or yapping of a dog.  The only thing that matters is whether the behavior is something you wish to encourage or discourage.

Operant conditioning is how you must regard your interactions.  When you validate them (usually with attention), you encourage that behavior.  Non-acknowledgement of irritating behavior is often the most effective discouragement.  The natural urge to engage with any point of fact must be resisted, and instead reserve your communications to that which advances your purposes.  When a minimum of validation is demanded, dismissal via fogging, playing dumb or broken-record technique should be engaged in, rather than the hard no which is deserved.  A satisfying response to a demand can never be offered unless you wish to be dominated by those around you.  Many see this as Machiavellian manipulation, but there is no choice.  You play this game, or get played.

Nevertheless, this all has a huge effect on the corporate environment.  Most firms devote far more energy to playing house than pleasing customers and making money, and tech is no exception.  Fellow employees are far more likely to seek validation on this schedule with each other than customers.  Most satisfy themselves with a stable IV drip of validation from their local group rather than experiencing the much more rewarding experience of solving customer problems.  This should come as no shock, given social media is purpose built to inculcate this mental model, as it was found to maximize engagement.  This is also good at building solidarity at a firm but unfortunately comes at the expense of crowding-out emotional investment in the customer who cannot and should not have so tight an OODA loop with their vendors.