That dreaded tap on the shoulder!
Anand Kumar Keshavan
Principal Engineer at Postman| Computational Linguistics | Generative AI| Formal Methods | Author | Musician| Neurodivergent
Picture this- you enter the office and starts the day with a stand-up, sit-down, standing-on-your head, elbows-on-the-table or whatever meeting that the powers that being in your organization have defined. After surviving this meeting, which may last anywhere between 30 minutes to 90 minutes- you grab a cup of coffee, indulge in an argument about whether "Interstellar" is a sci-fi movie or not with your co-worker. Having settled this burning question, you finally come to your assigned place of work.
You open your IDE and start working on the problem that has been assigned to you. Turns out that it is harder that what you originally presumed. You start thinking, trying out potential solutions, building then and testing them and so on. You reject some of them, others prove to have potential to break other parts of the program and finally you reach a point where you can see the contours of a solution.
And at that point, comes the gentle tap on the shoulder! You turn around with a startled expression see the face of your Project Manager/Recruitment Ninja/ Appraisal Genius/COO/CEO with a smile and a question- "What is the status?", "Need your input on blah" or if you are really unlucky, "Meeting in 5?".
The rhythm is broken, the solution that was within your grasp disappears from your thought processes as you deal with the situation. An hour or later ( because now you might break for lunch) when you start all over you find that you are pretty much starting over.
Familiar? This is so ubiquitous that one wonders whether the "dreaded tap on the shoulder" is a part of some standard operating procedures of companies under some obscure sub-section on page 94. Clearly, these are not stupid people that we are dealing with ( they do manage to get budgets approved, find people and resources, manage customers etc)- so why do they do this? I have seen this happen with every one from the PM to CEO tapping on the shoulder of a developer within a span of a couple of hours with t he same question- "What is the status?" Can't the first one tell the rest? Don't they trust each other?
A lot has been written about the programmer's "zone"- a state of mind that masks out everything else and focuses on the problem at hand. It is in the "zone" that great programs are written to solve difficult programs. From a business's perspective, this is the zone in which most of the stuff gets done - or in management-speak - the zone where programmers are most productive. This "zone" is not something that is unique to programmers-- writers, musicians, artists , scientists, mathematicians all produce their best when in the "zone". And hence it is best to leave them alone in their "zone" or at least leave them alone when they are in the "zone".
The time period of the "zone" is an intensely personal one and it varies enormously between individuals. In my case, the "zone" lasts for about 2.5 to 3 hours at a stretch. I prefer to have 2-3 such sessions a day beyond which I achieve nothing much. But I know guys who can be in the zone for 8, 10 , 24 even the marathon 72 hours. Bill Gates, in his introduction to "Inside OS/2", written by Gordon Letwin, the Chief Architect of the OS, had noted that Letwin had a message outside his office advising people not to "disturb or feed this animal".
Microsoft, in those days and well into the 90s had a policy of assigning an office to every programmer in the company. I suspect this had a lot to do with their phenomenal success- they could just do things much faster that other cubicle ridden outfits that encouraged the tap on the shoulder! ( Of course, I can't prove this conjecture).
A computer program, at some level, can be viewed as the realization and validation of the programmer's thought processes. By breaking these thought processes nothing worthwhile can be achieved- you only end up delaying the favorable outcome. And hence my advice to everyone with the word "manager" in the title:
- Understand the "zone" attributes if each of your team members
- Do not disturb or feed the animals when they are in the zone.
Believe me, you will get things done faster, cheaper and better! That's what you want, right?
Senior Software Engineer at LifeWay Christian Resources
9 年I have found that use of a decent version control tool (Git and Subversion are decent open source tools) can help me "get back into the zone." When I have used them properly, they give me a log of what has been happening with my code and what my thinking was before I was interrupted. The other massively disruptive, productivity destroying phenomenon is the forced Windows reboot practiced by some shops. That scurrilous practice is another subject for another time.
Principal Consultant at SwanSpeed: Rightsourcing, Time Series Forecasting and Anomaly Detection
10 年Wunderbar! BTW Paul Graham has written about this in a milder manner. I think stupidity is not inversely related to the position/designation, just remind yourself of a recent POTUS.
Visual Frameworks to help teams collaborate effectively
10 年Probably the single biggest reason I exited corporate culture. I want getting any work done with those damn status reports.
Fellow @ Postman Inc. | DevTools / DevTech / APIs / Product Incubation / Research
10 年I will go on to tell you this. I have literally NEVER worked in office. So much so that I can vouch to the fact that poor office culture can destroy your ability to go into the "zone." All my life, I've found that the greatest of all contributions to codebases came after "work hours". The greatest of ideas were conceived before going to bed. Office (during standard work hours), had been mostly to communicate, collaborate and coordinate things. Engineers don't formulate algorithms inside IDE. They code inside their brains and simply vomit out the concoction on a keyboard. Thus, the wider an engineer needs to think, the more brain stack it consumes. Worst of all, for many (like myself,) even a tap is not needed. Anything happening around us is easy to topple that stack.