Hacker News Reader

Comment by jimbokun | Hacker News Reader

I liken programmers to extremely expensive equipment for manufacturing software.

When a company invests in expensive equipment like that, it is very important to keep it producing output. So by sending programmers to meetings, your expensive equipment is sitting idle, offline, producing nothing.

Interruptions are like shutting down an entire assembly line. When you turn it in again, it will take time to be running smoothly again.

So to the managers and executives, it is your choice how to utilize this highly specialized, very expensive equipment. You can try to keep it running at full capacity, or frequently start it up and shut it down, take it offline, and leave it sitting idle.

View on HN

Many programmers (at least me) have varying levels of peak output in a day.

Some times I literally can't make my brain work after 2 - 3 hours of in-the-zone work. I just can't read lines off a screen anymore.

Other times I can go 24+ hours without breaking a sweat.

I think in practice your average programmer can't operate on the 40 hour a week traditional work schedule and actually output solid performance for all 40. On average, at least. So maybe the first businesses to start introducing meetings and such were attempting to pace their SE staff and actually saw positive results, since they still got whatever the maximum output one engineer could put out before their brain went to mush in a week but also had them talking to clients or discussing other things.

It is just the industry latched on to bureaucracy without postulating why it might be useful. You want your SE coding whenever possible.

That's pretty much the same as me. But I do know people who can do the 7 hour full force ahead. And interrupting those people generally results in very little getting done.

For the rest of us there is always code reviews and emails and other fun things that needs to be handled and requires less brain power (well code reviews should require more but let's ignore that).

+1 here. There is also a pressure to get things done when I don't feel like getting things done - as in I don't have the inspirations to write that piece of code / that code is so ugly and hard to write.

Then a day or two later I would come up with a better solution and boom, milestone achieved.

But without forcing yourself to write that code, the breakthrough wouldn't come in a day or two. The breakthrough will never come.

Writing that crappy code that feels like pulling barbed wire through your brain forces you to think about the problem. To look at the corner cases, to really figure out a solution.

The breakthrough in a few days is just a cleaner solution you were able to come to after a deep understanding of the problem.

True and a quiet day might be enough as an pill. Or at least sitting at home can help for some people.

Not sure why someone downvoted you. While it's true that not all work is pleasant and sometimes we have to force ourselves to get things done, I think it's equally true that for solving difficult problems reflection is necessary. Especially as I get older and more experienced, I feel like my brain has more fodder for solutions but it takes more time to tumble around and fall into place. A lot of things besides actually sitting down and coding can help: getting 8-9 hours of sleep, talking over the problem with someone (even non-technical), getting some exercise, mind-mapping / wireframing, staring into space for hours at a time, etc.

I completely agree. I'll have a day at work where I just do not want to code, and anything I create will be garbage. Sometimes I'll do a rough prototype of what actually needs to be done, which will get my brain thinking. A day or two later, everything clicks into place in my brain and I go through, rework the prototype, and create a great piece of code I'm happy to turn in. If I get interrupted during that period of programming though, I usually lose my train of thought which make me stumble to catch up again. The prototype helps because I can see what I was doing if I was interrupted

This is the reason why my productivity has gone down since going from single to having a family. When I was single, I would just cut out early on the days I wasn't in the zone, and get some errands or housework done.

When I was in the zone, I would stay at work until right before I would go to bed.

This way I would spend nearly all of my "in the zone" time doing work.

Now that I have kids and such, I leave at 6 every day regardless of my productivity level, so even though I spend only slightly less time at work, my net productivity is way lower.

In the same situation I think my productivity is actually equivalent with fewer hours after having kids because it has created an ongoing sense of urgency to get done what I can in the 8:30-5:30 window. In the old days, 4pm was almost like the half-day mark, which personally led to a mental slackness about how much time I had left to accomplish a given task that day.

These days, I sometimes get cut out of the zone by quitting time, but more often than not I am mentally exhausted and ready to go. I'm sure that this would not apply to the most focused and driven programmers, but I'm also sure that a lot of young startup types are fooling themselves that the long hours they put in are giving them better returns than they would get with a bit more sleep, a bit more exercise and a bit more downtime.

Anyone can take a great photograph. The professional photographer learns techniques to take great photos more frequently.

In a sense, "professionalism" in any field implies a certain "frequency of success". For a programmer, that means learning techniques to accomplish tasks even when you aren't "in the zone". This means learning to get in the zone, how to stay in the zone, and learning to produce when you're nowhere near the zone. This requirement is universal to all professionals, including all professional programmers[1]

I would add that learning to approach your work even when you don't feel like it can sometimes yield surprising insights. Your brain is recoiling from work, but only as it approaches it from certain directions. It is possible to approach a problem from other angles, and getting "in the zone" from another angle can sometimes yield unexpected improvements to the product for the simple reason that you're looking at it in a new way.

[1] There are two categories of professional programmers, the hired guns and the artists. They both want to build great things. The hired-gun wants to build things faster and to spec. To him, "great things" is unambiguously defined as 'the things that will satisfy the customer'. All businesses love a speedy, accurate programmer - especially if they can be speedy and accurate in a non-disruptive way. Such programmers are very good at understanding existing codebases, processes, and doing the minimum work to get the job done. Often they simply do not care about technical debt - (indeed, they are incentivized the other way, to maintain (and even increase) technical debt, every bit of which only improves their negotiating position with the client.)

Meanwhile the artist-programmer success is not defined by conformance to a spec. Success is harder to define - but the artist can define success as getting the time to perfect his creations, traveling ever higher up that diminishing returns curve, going higher than most people are willing to go. This kind of programmer is the dreamer, the architect, the creative. This can be a backend architect, or a front-end perfectionist. They share the common goal of mastery and beauty. Most, if not all, programmer heroes come from this category. And rightly so, I think.

Nicely put. Yes, programming is part art and we are not like machines that can work no matter in what state we are. But often we mask our procrastination/laziness blaming it on lot many things and waiting for a right moment to magically arrive get the work done.

I am reading 'Dune' now and I found this advice from Halleck to Paul so relevant :

'I guess I'm not in the mood for it today' Paul said.

'Mood ? Halleck's voice betrayed his outrage even through the shield's filtering.

'What has mood to do with it? You fight when the need arises - no matter the mood! Mood's a thing for cattle or making love or playing the baliset. It's not for fighting'

-- Dune, Frank Herbert

While this applies to many things people do, i don't think it applies to programming. Programming is a continuous activity of concentration done over the course of 8 hours, 5 days a week, roughly 45 weeks a year. Meanwhile fighting of many kinds is something that happens in short bursts of extreme focus and excertion.

In fact, programmers have to "fight" too, and it is highly different from their daily work: It is when the software is burning cash and they have to find the problem and implement a fix right now. Most programmers find that they deal with that extremely well, though it usually happens at the cost of the rest of the day.

I find that meetings kill productive time later, especially ones that are pure bureaucracy/managerial dickwaving.

It's certainly the case that I can't grind out code 40 hours per week, but I don't think that sticking meetings in the "unproductive" time helps matters at all.

My current company has engineers pair-programming full time. On first reaction, engineers and managers tend to think that results in 50% net productivity. My experience has shown that people tend to average each other out. There are days where I'm well aware of how poorly I'd program, but I can still navigate my pair out of the pit of despair.

It also tends to cut down on meeting times because two sets of eyes are usually looking at any given piece of code, so knowledge disperses among the team organically so long as we swap pairs regularly.

While I agree - the issue is when nearly everyone in a dept is 'expensive equipment' - do you send the most junior person? The most experienced? Get someone non-technical to go to meetings and collect requirements? But what happens when they are asked to estimate (on the spot) and discuss the possibility of new features?

While I totally agree with not disrupting working people - I don't think you should ring fence them out of input in the process of defining product - we've all seen what happens in that case - "requirements" nailed down by a non technical team. And it's even more wasteful to have people working on the wrong things, or worst still being given so overly defined work that there is no room for them to add any value or find a better and faster solution.

While good management can help shield teams from unwanted intrusion - everyone needs to get involved in the process of manufacturing great software - which doesn't just mean attending meetings, but taking time to actively plan and consider the issue before the session. If your company values your input enough to bare the cost of asking you to be involved, then you should look upon that as a positive thing (unless they REALLY are just wasting your time with 'busy' meetings, which are really just wasting everyone's time - and it's a sign of either having money to burn with limited direction or a company going the wrong way fast)

Well let's see if I can stretch my metaphor to address your points. :)

Equipment needs to be maintained to continue working at peak efficiency. Sometimes it needs to be taken offline for repairs or routine maintenance. Or maybe you realize you need to switch over an assembly line to build a different product or model more important to your bottom line.

So, yes, there are times when the software manufacturing equipment will not be manufacturing software. But you want to keep that time to a minimum and understand the cost to the business of having the equipment offline.

Now if only we could install hardware upgrades...

Don't get me wrong, I totally agree with your point, but I meet a fair few devs who don't want to get involved in meetings - then complain about lack of information or clarity later in the project.

But other distractions as shown in the comic, I totally agree with doing everything teams, companies and individuals can do to remove all those distractions and keep people working however best works for them.

> but I meet a fair few devs who don't want to get involved in meetings - then complain about lack of information or clarity later in the project.

Send a manager to the meetings, and get that manager to do a nice write up, with action points, afterwards. Email that round the team.

The people with people skills do the people stuff, and the people with coding skills don't "waste" a couple of hours in a frustrating meeting.

Meetings are rarely for communication. They're usually for a manager to validate his authority.

"usually" Is a bit harsh IMO. It can be a lot of times, but then that's a symptom of a much bigger problem. It's hint, more often than not, that the environment is toxic and it may be time to dust off your CV.

Or to get an entire team onto the same page?

Weird then that the overwhelming majority of meetings at my workplace are scheduled by programmers, not managers.

Meetings scheduled by managers stand out from the crowd, but if you count them up, are actually a minority (at least for me).

That's a sign that you're in a fairly unhealthy workplace culture. Get out!

Meetings can be useful tools if you make sure to involve the right people and stay focused. This doesn't require anything special. Just define what you want to decide in the meeting, prepare for it ahead of time, and come to the required decision in the meeting -- discussing as necessary.

If you do that, it was a useful meeting. I have one or two such meetings a week at work, occasionally even three. They're rarely scheduled by management, but instead by the engineers building the system.

Meetings can also be used to disseminate information.

You should explore other opportunities, if you feel that way for your current work place.

Sadly true. I like a turn of phrase from Peopleware - "Status meetings are generally ways for the manager to assert their status as manager." I've had many an inexperienced manager sit there and rotate through talking to each minion in turn, while the other N-1 minions sat silently thinking about what they were going to have for lunch today. Even better are the "stand-up" meetings that have everybody sitting around for an hour every morning, totally killing any motivation or energy for the day.

Thankfully I've escaped that sort of nonsense, but it seems like it can pop up anywhere.

I don't know why, but I found N-1 minions incredibly funny and almost spewed my coffee.

I think this is a good point. In addition to not "shutting down the assembly line" it's important to set the proper direction. Many interruptions come from poor planning. "Stop doing that, do this," frequently is the result of not thinking through things to begin with.

Though I like your analogy, most programmers I know would rather say, "Don't interrupt Picasso" rather than "Don't stop the Lexus factory" :-)

Picasso was a machine that produced masterpiece works of art! :)

You can't stop the Lexus factory (robots). You mean the Toyota factory? (andon cord!)

I, on the other hand, liken programmers to people.

One client I worked for had a "heads down Thursday", where no one was allowed to schedule anyone in the app dev department for meetings; general consensus was that Thursday's were by far the most productive day of the week

Meetings' Thursday might be even more productive. (Ie nobody is allowed to schedule anything on any of the other days.)

Until it is discovered too late that you are working on the wrong thing.

It's a trade-off. Stakeholders want to be able to discuss upcoming work and course corrections, but developers need uninterrupted time to get current work done.

When I worked as a team lead I created a rule that there could be no meetings in the afternoons. The daily schedule was that we'd have a morning scrum where everyone would say what they did yesterday and plan on doing today. That was also an opportunity to schedule any meetings for the day, to be done immediately following the scrum. As team lead I considered it my job to take on that burden, when possible, and fill in the rest of the team with the pertinent details afterwards.

It worked out fairly well: stakeholders could schedule time any day to talk to the dev team, but every afternoon (at least) was no-outside-interruptions development time.

Did you survey your team to see when their most/least productive times of the day are ?

I usually get the most done in the morning. I would not be as productive if I had nothing but meetings until lunch.

(It doesn't sound like "nothing but meetings until lunch" characterizes your team, I'm just making a point)

In this case it was a distributed team with most the members in Romania (GMT+2) and Armenia (GMT+4) with myself in Ottawa, Canada (GMT-4/5). So our normal working day only overlapped for an hour or two in the morning. So, we didn't have a choice that way when to hold meetings.

At some points in the project my day often ended up being half meetings, half development. Lunch ended up being a break where I'd switch modes from 'team lead' to 'developer'. It wasn't ideal for me, but it was ideal for the rest of the team and I considered that my top priority.

I disagree; meetings are an opportunity to discuss architecture and allow your brain to relax between hardcore programming sessions.

Yes but no, because producing code is never smooth, or smooth code production is exactly the characteristic of these coding sessions you can interrupt without great loss.

I agree this is the weakest part of the analogy, as software production is so highly variable. You can have days where you see very little come out of the machine, then a great amount of valuable software come out, seemingly all at once.

I think, though, it does not invalidate the basic point of keeping the software producers on the task of software production as much as possible in order to maximize output.

My favorite is when I try to take my laptop to a meeting so I can, you know, actually get some work done. And then, I'm lucky to get 5 minutes of useful work done for each hour of meeting.

Reply on news.ycombinator.com