Makers, Don't Let Yourself Be Forced into the 'Manager Schedule' | Hacker News Reader

Makers, Don't Let Yourself Be Forced into the 'Manager Schedule'

blog.nuclino.com

798 pointssuperhumanuser386 comments

I had this exact situation come up with an engineer that I can only call brilliant, with the most conservative of overtones. He was more than that. Being a maker myself I gladly encouraged him to work when he wanted, sometimes that meant he'd work 48 hours straight and sleep for two days and show up Friday. His 3 days of work (as his peers would describe it), easily was double the quality and output of his closest colleague. I loved having him on my team.

Eventually, other people started asking to work 3 days a week, suggesting that they too would pull all-nighters in an effort to have 2 mid-week days off. I let a few experiments happen but sadly in most cases the result was less than 50% of what they had been previously able to accomplish.

This led to a new merit based working system when we placed emphasis on sprints and achieving. This too ended up failing because the interconnected dependandcies of sprints were always bottlenecked by the slowest operator.

The final result was the eventual departure of my most prized teammate, and mostly due to peer pressure. I often think about how I could have better allowed his brilliance while not alienating the rest of his team, but in the end I failed.

I think it was Mark Cuban who made the point that a mature, professional team can handle having one "Dennis Rodman". But it can only be one, and management has to be clear that they're making an explicit exception which isn't open to others. The rest of the team might find this a bit unfair, but usually they'll tolerate it as long as results are good and they're treated well in other ways.

This, exactly. we try too hard to make one rule to fit everyone but not everyone fits every rule. It's ok to use judgment and say "this person gets this other treatment for these valid reason."

I had always assumed that these sorts of exceptions can become HR liabilities, especially when the person getting special treatment shares the same title as other peers.

Could you be more specific? Why not give the high-performing prima donna a small promotion?

It's a question of finding a great sounding, but ultimately meaningless title to add to the company ladder.

Junior Architect

Senior Architect

Legendary Architect

I think the problem is that every quirky developer thinks they're the Dennis Rodman of their team and it's probably not the case.

They could do without me if they tried. There’s at least one member that could pick up the slack (and code quality might actually improve a bit).

It was Phil Jackson (Rodman's coach at the time):

"Of course not. There is only room for one Dennis Rodman on this team. In fact, you really can only have a very few Dennis Rodmans in society as a whole; otherwise, we would degenerate into anarchy."

Similarly, John Madden on Terrell Owens:

"If you hold the bus for everyone on the team, then you’ll be so late that you’ll miss the game, so you can’t do that. The bus must leave on time. However, sometimes you’ll have a player that’s so good that you hold the bus for him, but only him."

Thanks for the correction, that's what I was thinking of but apparently it wasn't Mark Cuban.

I just shake my head at the idea Rodman likely deserves a Nobel peace prize for the work done with North Korea. (and he likely does) Of all the people in the world to guess... he would not be the one I expected to do something significant outside of sports.

NK still has nukes so no. On the other hand he cannot possibly deserve it less than Obama or the EU, so ...

Obama got the peace prize before even entering office and EU is a study in dysfunction ...

And if NK know what is good for them, they will keep their nukes. The US will flatten them as soon as they get rid of their nukes.

Just a question to check on something that I'm pretty sure I already know from your story:

Just want to verify my assumption that you were too small to have a "Research" or "Tech Strategy" department to move that guy into?

Some people like making production product or like having the higher development standards of production systems.

I was the business owner and we had 9 employees. Even with him moving into another department, it would be like printing new business cards and that's it.

I had a conversation with a CPU designer by chance at a fast food restaurant. He described exactly this, except that everyone he hired was brilliant but didn't fit in with education or other jobs because they thought in more dimensions than just "pass this class", and that's exactly what he needed for silicon design. I can only assume it's a team consistency issue in that if not everyone is on the same page then it's possible the outlier will move on.

What do you mean by thought in more dimensions? Like abstract creative / divergent thinking that defies a canonical answer? Or being constantly distracted by meta problems?

Pretty much. Thinking from different planes of knowledge and connecting them, recognising, applying and folding over abstractions and patterns. Imagine if your knowledge of software development was a tree, and imagine if your knowledge of design was another tree and you had one for hardware, biology, music, math, physics. And a lot of times contain the same patterns and abstractions, so you can recognise them and apply them where you see fit instead of just using them from one tree only, so that gives you a lot of mental models on how things work. That turns out well in abstract stuff and thinking in complex systems, especially when you need optimisation thinking like a CPU designer would need.

Interesting. So how does this make them bad at school?

Lack of focus on the class, boredom, lack of will to obey rules and instructions, punishment instead of rewards (for example, bad grade on a math test because they did it in their head instead of writing down the whole process) for different behaviour and many more

I had a similar brilliant engineer with odd working hours at one point. I also had the same problem with other engineers requesting the same odd hours, with equally negative results.

In my case, I eventually learned that the odd hours weren't the key to his perceived success. Instead, he used the odd hours to force us to give him only work that could be accomplished alone. We were lulled into letting him make key architecture decisions in isolation, because no one else was awake or online at the same time to discuss them.

Eventually he became the architect by virtue of operating in isolation, where we couldn't discuss his decisions. Everyone else was forced to work around his code. If he refactored the codebase in the middle of the night to make his job easier, the other team members were all forced to work around his refactor and waste time updating their PRs to match his work.

Worse yet, having someone like that on the team drives away other great employees. Eventually everyone else will get sick of accommodating the architects isolated schedule. If they have other opportunities, they'll leave.

> I often think about how I could have better allowed his brilliance while not alienating the rest of his team, but in the end I failed.

It's not on you. Brilliance and individual productivity aren't everything in a team setting. If your project must scale past a single person, you need everyone operating on the same page. It's painful in the short term to lose the quirky rockstars, but it makes for a healthier team in the long run.

You're both right :)

You want the "quirky rockstars" as your prototypers, not your architects. Then everyone can thrive.

It seems like all these comments assume everyone is working on roughly the same class of problem. That's probably a mistake.

This is a super strong, on point message.

I feel like I'm currently living in a gray area between those two alternatives. I'm US as the lead architect for this project. I've written much of the code, made most of the architectural decisions, and all PRs go through me. The curveball in my situation is that all of my engineer teammates are offshore of varying levels of quality. I don't really have a choice to cut all the fat because I work at a consulting firm but on a unique project where it's a joint ownership between my consulting firm and a client. The project behaves more like long-term internal project work but its the client paying us and our bills. We're incentivized to keep these green offshore guys on the payroll even though their contributions are pretty small. For whatever reason, even though the client knows they submit low-quality work, the client still wants them on the project. We've tried over and over to push the devs critical thinking skills to the level where they can take a prototype and not royally fuck it up, but they just can't seem to meaningfully push through and take ownership of a prototype. It's weird, because I do end up architecting and developing in isolation (which is sweet, honestly) but stakeholders are somehow happy enough with our throughput that they won't shell out for more US senior engineers. I guess the upshot here is that a team is only as flexible and scalable enough as the average level of talent on the team.

Rands in Repose (Michael Lopp) talks about this in his book "Managing Humans" as volatiles and stables, the former being largely analogous to rockstars. He (I believe accurately) describes how volatiles ignite the fire that leads to big change, then become stable around the new solution (or leave) and get disrupted by new volatiles. It's very similar to Clayton Christensen's work on disruptors.

If you're a manager, the math of having true rockstars on your team rarely works. They take more effort to manage yet produce fractional more output (they might be 10x better than a terrible developer but they're not multiples of solid devs). So I'm way further ahead if I can focus my efforts on improving broad-based productivity 5-10% than if I cater to my rare unicorns that are 30-50% better than my average team. Something I think ICs often overlook is a focus on leverage and scale to drive big improvements.

> Something I think ICs often overlook is a focus on leverage and scale to drive big improvements.

Mind expanding on "leverage and scale" in this context?

I think what they mean is scale = repeatability; you can't really say "clone rockstars" but you can do something n-times with a pool of good developers, and leverage = the scaling action; ex: a senior dev could increase their output by 10% or you could introduce some knowledge sharing/mentorship/coaching program where the individual's capacity falls by 10% but they increase an entire team's production by 5%. In a small org where you probably shouldn't have dedicated dev. managers stick with the former; in growing companies the isolated rockstar is still rare and you're trying to move the needle with 50, 100, or more software devs.

Was this Google's entire point of 10% time?

An outlet for unicorns that keeps them away from the company bread & butter and unicorns.

As someone who has built prototypes and has worked with others who do the same, I couldn't agree more.

The problem is there aren't many prototype gigs out there, so it's not a great specialty.

Isn’t there? Academia, R&D divisions, early-stage small startups... Most greenfield projects require a prototype.

I've worked at mostly early-stage startups.

I haven't seen R&D Divisions at companies, but I'm sure something exists.

Clearly, odd working hours doesn't mean communication has to stop.

It should be possible to set up asynchronous communication channels, like a collaborative document-editing service (Google Docs, Dropbox Paper, etc).

The problem is response delay. If you need 10 rounds of back and forth to communicate something then your total time is 10*delay. Moreover, at some point people start to forget the context so the total time goes up even more and quality of responses goes down. If it takes 6 hours for a response then you can spend days waiting for a relatively simple point to be hashed out. Especially if there's multiple people whose input you need who are all working at different schedules.

Clearly, having 0 work hours in common with the rest if the team is a problem. But what if you have at least 2-3 hours per day? You can already discuss a lot of things during that time.

I get that asynchronous does not always work, but it has some benefits, especially for tasks such as architecturing an app. I'd be worried if such discussions would happen only in an oral fashion, or in chat channels.

I find this often boils down to people being unwilling to read/write very much. If people insist on reading and writing no more than a single sentence at a time, async communication will be very difficult. If they’re willing to provide full answers to the question, it’s not so bad.

Good documentation is also invaluable, and good documentation being 1:N is often more valuable than a 1:1 synchronous discussion for certain things.

That's assuming people bring up the patience to wait for a response - a rockstar developer type is inclined to go "screw that, I can whip this out in a couple hours", so by the time others have a chance to think about it it's already done. Not too late to challenge it, but it'll feel like wasted effort then.

Sometimes people need to feel the sting of a wasted effort to understand that they work on a team. Don't want to waste your time? Don't waste the team's time.

> you need everyone operating on the same page

You're right that people need to be on the same page, but being on the same page should not be 5 scattered 15-minute meetings in a day on top of "Hey did you see my e-mail" and "Hey check this out" and "Hey where is that site you mentioned yesterday".

Real work gets done when people work undisturbed in blocks of time. Meetings should be scheduled such that engineers have large blocks of continuous time. Meetings should be focused on generating action items and establishing the prerequisites for those action items so that further ad hoc requests are minimized.

For example, you might find that 1pm is a good time for meetings because it accommodates all (early/late-shifted) commute schedules, is right after lunch which people need to take a break for anyway, and leaves a continuous block of work time after the meeting until the end of the day. The timing may differ in your work place but you should figure out what works best. Asking your engineers is a good first step.

My team has offshore and onshore developers. We get all the downsides of a quirky rockstar who architects things in the middle of the night without any of the benefits of lots of work getting done.

> Brilliance and individual productivity aren't everything in a team setting. If your project must scale past a single person, you need everyone operating on the same page. It's painful in the short term to lose the quirky rockstars, but it makes for a healthier team in the long run.

I think this is a self-inflicting ailment in the tech world. Many who are ICs fancies themselves one of these mythical "rockstars" who can code the business saving solution in 24 hour benders. Management/hiring/culture in general put too much emphasis on the brilliance of a single person on the team. But as you said, there's a time and place for the brilliant IC, and that's usually the very very early stages of a business.

I've seen this sort of situation play out at my current job. We had a "rockstar" who was with us from the beginning. He was able to ship solutions extremely fast, was a fantastic eng, but loved to do things on his own schedule. He was the backbone of the eng side of the business... until he decided to take an offer somewhere else. He pulled off a crazy last 48 hour bender to wrap things up he was working on, but in his haste left behind a half-finished total rework of the back end which nobody other than him had a vision for.

We spent the next 6 months trying to understand and finish where he was going with this rework. The manager who enabled this from the beginning also left, so we were left with a bigger mess than when we started.

Sure, this particular eng got a metric ton of features shipped in our early days, but in the end ended up costing almost as much to clean up his mess as the value we got from him in the first place.

There's a way to make these situations work, but blindly enabling the whims of the rockstar is not it.

> there's a time and place for the brilliant IC, and that's usually the very very early stages of a business

I definitely agree with this with a slight alteration....early stages of a project

Ehhh... everyone is brilliant in the early stages of a project.
Coming up with a fantastic green fields design isn't hard and represents a fraction of a percentage of the overall work.
Give me a solid engineer who can deal with all the legacy cruft and still produce a maintainable piece of software.

I'd offer a third option: Early stages of a product.
The hyper-productive antisocial back room whiz kid is perfect for an R&D role. They can launch off solo and come back a few weeks later with a working prototype to prove the viability of a new product line. Then, before they get bored and stop being productive, you send them off on another deep space mission to invent something else.
All the while, you have a team of less flashy but more dependable and cooperative engineers taking the prototypes and building sustainable systems and marketable products out of them.

I need that role. In a week I turn out what takes a team several months and many times they've already spent that many trying to show any visible progress.
I've done the impossible since I was in college. Still am. I'm resented by peers. Feared by less competent managers. I can't be controlled.
I have a deep sense of integrity. I refuse to compromise my morals. I will not be forced to implement anything I believe could be used for unethical purposes. I won't bury the truth.
I won't keep my mouth shut if blame is cast inappropriately. I will not see people thrown under the bus. I work too hard. I'm an over achiever. Others start to believe they are looking bad by comparison. I'm held back by them.
I work all night. I get 'er done. I care. I listen. I empathize. I'm hated.
I'm not a team player because I am able to do all the jobs but focus what I do best. I'll help you do your job better but I won't do it for you.
I won't tolerate lies. I have high standards for myself and my team. I won't fall in line.
People assume I'm arrogant but I always under promise and over deliver.
I'm lost.
There is no place for me.
I'm alone.

Sounds like you need to start your own company where you can call the shots and surround yourself with like-minded people.

Look for consulting work or start you own business. If you are difficult and not a team player, you are going to have a hard time in teams regardless of your ninja rockstar abilities. But there are plenty of opportunities for a sole developers where you might thrive.

Honestly, it sounds you're both brilliant and a bit lacking in people skills at the same time. Most people are decent and try to do the right thing, so if they do something questionable it's usually because there's another (not-questionable/good) thing that they're trying to achieve. Try to objectively understand people's reasons for doing things before you reach a conclusion about their behavior, it will go a long way in making you feel less alone.

It must hurt to feel so lost and alone. I'm sure what you wrote is an honest description of how you feel, but it's highly biased. Impossible for it not to be, mind you. Without talking to your peers, or watching you interact with them, it's impossible to say if it's actually your IQ that they resent you for, or if there's something else going on. For instance, if EQ is low (compensation for high IQ), then you may not even be able to see hurtful actions that you've taken towards them for which they resent you, rather than jealousy of your brilliance.
(btw might look into Aspergers/ASD)

Go see a therapist.

You need to grow up. It’s hurting and will hurt like hell, but it’s the only way. You are not your work, you got that illusion and higher sense of self because you knew that’s the only thing you have to offer, now you’re starting to realize it’s a dead end.
Time to let go.

There's a bunch of contradictions in this post, and honestly it seems like a troll/joke post.
You're conflating lies/truth, empathy/hate, peers/team, productivity, etc all together, it's bananas.
But the basic gist is that it sounds like you're not suitable for larger companies at all. You should limit yourself to companies smaller than 50 people.

This reminds me of a manifesto, like the hackers manifesto that showed up years ago. Maybe we can call it the Overachiever Engineer manifesto?

Have you tried coming down off your high horse in the rarified stratosphere and acted like a normal and humble human being? Because you are either on a team of retards or you have an unhealthy ego.

In some degree, I believe everyone is in that same boat. But I think it is unusual to mix your 'morals' with your work. This indicates that you like discussing random stuff with people at work.
I mean, avoiding allocating memory unnecessarily is not related to moral nor ethics.
And you know.. just because you have a moral opinion doesn't mean you MUST point out divergence with others, when they pronounce their world view. I really find it unusual to point out "morals" in a topic like this one.

Why not just revert the rework? If no one has any context you're probably better off sticking with what you had even if the rework had good intentions.

Undoing someone else's well intentioned work can be viewed as passive aggressive behavior.

If they're still around sure, but the engineer in this case had left and wasn't around to maintain the work anymore

I think they were referring to reverting the work of the employee that left that put the organization in a bind, not someone still on the team.
I had the same thought—revert the changes to get the rest of the team back on track. The problem could be that the changes could be over the course of many commits, so rolling back is complicated and almost as difficult as moving forward.

Yep multiple commits over a long period of time + different services (microservices).
Was possible to revert, but the work needed to be done. The biggest mistake was letting this singular person take control and not let anyone else in on it. Reverting would have been a big effort as well.

That’s only if you don’t discuss it first.
Well intentioned work can still be bad or not usable or not the thing the code needs right now.

But as you said, there's a time and place for the brilliant IC, and that's usually the very very early stages of a business.
There are two kinds of ICs that I like to call capability guys and capacity guys. Capability guys can bring new skills into the organisation, and capacity guys can do the bread-and-butter work that actually pays the bills. You need to balance the two. Make sure the capacity guys benefit from learning the new skills and make sure the capability guys don’t go off on a tangent, and it can be a very enriching experience for everyone.

What does IC mean?

Individual Contributor

individual contributor. i.e. not a manager or leader.

It’s easy for people to reflect on the brilliance without the casualties they sometimes cause.

Overly dramatic language aside, what else are engineers that come into a place that isn’t rife with greenfield opportunities expecting?
Most software work out there is babysitting. Oh I know, I know we’re rockstars inside.
In the early days, as the story goes, one person shipped a bunch of features. This part of the anecdote is underdeveloped, IMO. Hazy past recollections formed after emotionally processing a big shift.
Was someone bringing this up before manager and rockstar bailed? Sounds like the team and upper management as a hole lacked foresight, and this is an after the fact realization.
It’s a TEAM effort after all. Poor organization isn’t the fault of one brilliant eng or manager.

> Most software work out there is babysitting.
Yes, of a sort. Green fields are rare, and with the way things are today your picking up a massive pile of pre written infrastructure and libraries that you hardly look at (until they are a problem).
The rockstar mentality is not wrong, but some days you need to pick up the pack and walk up the mountain too.
The problem starts at the interview. We give people coding tests to see if they can produce, but that's less than 10% of the technical side of the job. Really we should be giving code reading tests. What does this do, is there anything wrong with it, is there anything you would change and so on.

Even most "green fields" these days tend to be fields where the grass is torn out, some re-landscaping is done, and some new grass that is a lot like the old grass is planted.

As a manager, a big part of our job is to mitigate risk and single points of failure. If enabling someone to work like this increases risk and creates SPOF in our teams, we're screwing up letting them do it.

Absolutely agree. This point however is generally only understood by a previously engineer-turned-manager.

> As a manager, a big part of our job is to mitigate risk and single points of failure.
No, your job as a manager is to understand the trade-offs of taking such risks and make a decision that fits your situation.
I.e. your competitor may capture your market with a single engaged risky engineer before you can produce anything usable with your best practice low risk team. Once they capture the market, they can stabilize later and hire your team, because you went out of business.

That is one of the very important points a lot of people are missing here, and a key argument of the article: a fast rendering engine was a requirement for quake to be as popular as it was and it was a product of a brilliant engineer doing something innovative.
More often then not, innovation comes from a reduced number of people doing things differently, and it's very hard to assemble a team of engineers which is willing or even capable of doing this sort of work.
This also comes back to the "decision shielding" from working different hours: it's very common for managers or people averse to risks to try to stick to solutions they know, even if they are suboptimal or do not fit the problem very nicely.
Anyone capable of doing more will soon realize they are spending most of their time solving mismatches between what solution was used/implemented and the problem they were trying to solve. If they don't find an alternative or a way around these limitations, they will leave.

With real rock stars, or movie stars, the manager of course reports to the star and serves at their disposal.
Manager may have some challenging performances lined up and the creative operator has to really toe the line, but the purpose of the team is to support that to the best of their ability.
Anything less, and the desired expression of talent might be dampened. If this is too severe expect the star to move away toward a more functional arrangement.

Your job as a manager is to make corporate life tolerable for your minions. The storyline you present here sounds very dehumanising, and in my experience all of my worst managers have been like that.

IC = ?
edit: IC = individual contributor (just found that answered somewhat deeper in another subthread)

“Individual Contributor”, as opposed to “Manager”.
The term is often used in reference to the engineer career track where you don’t become a manager but instead focus on technical leadership, but more generally it refers to being a leaf on the org tree.

Individual contributor.
In contrast to a lead, manager, or pm.
The IC is usually the person who actually writes software/code. (The bulk of employees at a software company are ICs)

PM is typically an IC too unless they are directly managing others.

I'm a little confused by your comment. If his 48 hour rewrite of the codebase didn't end up working out well (and how could it really), why not just rollback to where you were previously? That way you wouldn't need to spend 6 months making it work?

It was an on-going rewrite that consistent of multiple PRs against multiple services (micro-services arch).
The 48 hour push was to "finish" which didn't end up happening.
Reverting was possible, but would have been just as much work as pushing forward (since the rewrite needed to happen anyway).

This is the sort of thing that gets me ranting about how 10x programmers are actually vampires, sucking their life out of the rest of the team with their loose-cannon behavior.

Would love to hear some examples/experiences especially since 10x programmers are so deified

It's like classic school. My kids complain that they are forced to slow down to keep pace with the rest of the class. Same idea here.

I've worked with a lot of them over the years. Big/breaking codebase changes without consulting anyone, not waiting for requirements to work out, not playing well with others, not being willing to mentor less experienced team members... the list goes on and on and on and on. I do not like working with 10x programmers. They're the engineering equivalent of putting your bills on a credit card. You have to pay it eventually, with interest.

Your description sounds so familiar to a situation I was in over a decade ago I almost wonder if it is the same! In my case the "brilliant" engineer wasn't really that brilliant although he did have grand intentions. He ended up building an XML based configuration systems so wildly over-complicated it retarded development for everyone else involved. He'd come in overnight and make massive change that would require everyone to spend their entire day re-doing their work. He was also extremely toxic from a personality standpoint, often getting into angry exchanges with his piers. He was the type of engineer who tried to dominate technical discussions by insulting and dismissing others rather than by demonstrating the merit of his ideas. Most engineers would just avoid the confrontation and this allowed him to railroad bad ideas through. Eventually, after I left, he bypassed all dissent entirely by working overnight so that no one could even challenge him.
I was on contract so I just left. No way was I going to deal with that environment. I lost all respect for the technical management there too. The director in charge of the project seemed to be confusing arrogance and belligerence for ability. Rather than reign in a clearly toxic employee he actually encouraged everyone to work around him and touted the benefits of the crazy XML system he was building. These benefits, of course, were no more than empty promises from the employee himself. But they were politically expedient ... the director could claim the team was building some advanced system that could potentially be reused. It gave him some cover to explain why things were taking so long to deliver.
IMO, this is the worst environment possible for development. You have directors favouring empty promises for incredibly complex systems to give them good talking points. You have toxic developers who make any dissent to their bad ideas so unpleasant that they gain control. This creates a feedback loop where good engineers see bad ideas and bad behaviour get rewarded with special treatment.

that person doesn't sound brilliant at all. What earned him the badge "brilliant"?

When dealing with complicated systems (PARTICULARLY fragile, over-complicated ones) the engineers are often (unfairly) seen as "brilliant" because they're the only ones that understand the mess.
It's ironic, right?
The more fragile and over-complicated the system, the more the engineers who created the mess in the first are considered "brilliant."
I've seen this countless times.
(In defense of such engineers, it's often not their fault. They built one thing, and then management and business needs dictated a plethora of changes and technical debt against their wishes. I have been one of these engineers on occasion)

The irony is strong because brilliant engineers are the ones able to simplify problems and write simple, robust and easy to understand code. Whereas not so good engineers don't know how to manage complexity and write fragile code (and yes I'm guilty of that but trying to improve).

Probably this: "He was the type of engineer who tried to dominate technical discussions by insulting and dismissing others rather than by demonstrating the merit of his ideas. Most engineers would just avoid the confrontation and this allowed him to railroad bad ideas through."
I have seen this play out multiple times - acting like asshole can make you look smarter then you are and smarter then nicer people.
First, he ended up dominating discussions, so other peoples ideas were not told. This is simple, he is having ideas and they seemingly don't.
Second, other people got criticized a lot and he did not got criticized. Hence, others looking like having bad ideas and him looking like having good ideas. Yes, criticism was actually insults and dismiss and actually actual arguments, but it unfortunately often does not matter when people make impressions.
Third, people have tendency to buffer criticism with praise. So when they criticize him for having been asshole, they will first euphemise with "low social skills" and then add something like "but he is good programmer/professional" to it. So that they dont sound biased or overly negative. Unfortunately, they rarely buffer praise with praise "he is so nice" is rarely followed with "and also good programmer" cause it feels unnecessary.
It does not work that way for every kind of asshole through, not everyone can achieve the same. But when it works this way, imo, above are factors.

A few reasons, which I alluded to.
He offered a grand vision for a highly-configurable system. This vision meshed with the directors desire to have such a system. He was effective in promising all of the features of such a system that the director wanted. In fact, he promised even more! To be fair to him as a developer, he was trying his best to deliver on this promise. The system as promised was beyond what he could produce.
Within the giant mess he had created were many of the elements required for the grand system, they were just buried underneath very complicated XML systems and over-engineered code. He would prototype new system features working (held together with digital tape and bubble gum) to prove viability. The fact that these features were incomplete would be hand-waved away. Of course, sooner or later the system would have to be "filled in" so that all of the details were correctly handled - which would inevitably require further massive rewrites to all systems. This gave a feeling of progress but that progress was actually hollow.
If anyone pointed out that most of the systems he was implementing were basically prototypes and would fail on any case other than the ones he used as examples - he would become extremely toxic. I mean, literal yelling matches. His tactic was to belittle anyone who pointed out issues in his design or his code. Most of the developers on the project were junior so they didn't stand up to his tirades, the rest just didn't want to deal with it. I have no idea why the director allowed that behaviour to continue but it was a regular occurrence. This meant that his examples worked barely enough and no one else could get their own code working without his input. That matched his toxic rhetoric that everyone else was just getting in the way of him getting things done. It also gave him the cover to work late nights when no one else was around, so no one would interrupt him while he completed this grand system.
This attitude of "I am so great that others are getting in my way" is now a huge red flag for me. If your attitude is "once I'm done my grand system, everyone will thank me" then I want you off my team. Your grand system will never be done and if you develop it in isolation I can guarantee it will be of no use to anyone. If you react to feedback about your grand system with "you are too stupid to understand it" then that is even worse and I cannot get rid of you fast enough. If your system cannot be understood then that is your problem, not a problem for everyone else. The fact that someone with either of those attitudes is seen as "brilliant" by anyone is a mystery to me.

Hah! I feel like you are writing about me from several years ago, although I don’t believe I was this toxic with my peers.
Q: was the programmer in question fairly young and inexperienced? My gut tells me that these types of “brilliant programmers” flare up early on in their careers, think they are hotshots, but mature a few years into it.

I'm not sure how long he had been developing but he was considered senior on the team. I didn't get enough of his history to determine if he should have known better.
I definitely believe people with those kind of negative attitudes can be reformed because I've seen it with my own eyes. Often all it takes is a supportive manager and some positive role models.

Ouch. I used to work with a guy like this.
Generally speaking, this is an occurrance that is exceedingly common and extremely under-recognized in our industry.
Instead, he used the odd hours to force us to give him only work that could be accomplished alone. We were lulled into letting him make key architecture decisions in isolation
Our guy accomplished this via different means but the end result was the same: because of various factors, he became "architect" and essentially was able to make decisions alone. Then we had to live with them.
Eventually he became the architect by virtue of operating in isolation, where we couldn't discuss his decisions. Everyone else was forced to work around his code.
Yyyyeeeeeeep.
Our guy was genuinely, I think, the best engineer on a team of pretty good engineers. But in terms of sheer talent he was not a "10x" coder in terms of raw talent. Call him perhaps a "1.2x" or "1.5x" in terms of raw talent.
However, he was essentially able to operate as something like a "10x" talent because he got to do a lot of greenfield work, make sweeping architecture changes and decisions, and so forth. Meanwhile we were all left to deal with his fallout.
Whether or not you believe there are legitimate "10x" engineers (we'll set that debate aside for a moment) I think it is very, very obvious that we have misidentified the talent level of many engineers. Your actual output level as an engineer, be it 1x or 100x, is always a product of many factors and your actual talent level is only one of those factors.
Worse yet, having someone like that on the team drives away other great employees.
Yes. Two big reasons.
1. It's not a good way to make software, obviously. Great employees want to make great software and will be frustrated.
2. It's career fucking suicide to work under somebody like that. It's impossible to shine when working under somebody like that. You can't clean up a mess as quickly as other people can create a mess. You just can't. With very rare exceptions you simply cannot mop a floor well enough to be seen as something other than a janitor.

I still think I’d rather have my architectural decisions made by a 1.5 coder than a 1.0 coder.
This causes other people to have to follow the style, but it also prevents them from making something worse.

I think their point was that architectural decisions shouldn't be dictated by any one single engineer.

Not sure about that. Too many chefs spoil the broth. And in most cases, if this one single engineer has the proven track record, I'd give his opinions and decisions slightly higher weightage but at the same time, dictate that he run through his decision making process with the rest of the team. Think of it as forcing him to communicate/knowledge share so that the rest of the team can keep up, learn or simply be convinced. Otherwise, the session serves as a Q&A for the rest of the engineers to shoot. It makes this 'rockstar' a more wholesome engineer in the end, whether he buys it or not. Communicating well is more difficult than perceived, and it's definitely a critical competency to master if you want to really call yourself a rockstar/10x techie.

Yes, this is how it should work. Assuming your 1x engineers are smart, competent engineers with relevant real world experience under their belts (and are not recent code school grads)... they should have a great deal of input into architecture decisions. They should never have architecture level stuff thrust upon them. Too many cooks spoil the broth indeed but nobody should be doing this stuff in isolation and dictating it unless perhaps you’re doing truly bleeding edge shit and your 10x engineer is a true, Carmackian generational talent.
However.
Howwwwwever....
The ILLUSION of democratic (or at least collegial) meritocracy is how our faux-10x engineer pulled the wool over folks’ eyes. He gave the appearance of soliciting feedback. We had internal RFCs and everything. But in the end though he really did just push his ideas through unmolested, because he had management's blessing to do so.
Not sure how much was an intentional masquerade on his part. I think he really did think it was a meritocracy and his ideas were simply the best. It is certainly not unheard-of for folks to fail to recognize their own privilege. Whatever the case, management enabled it. He was not an awful guy in general, and I rather liked him, just not as architect-dictator.
One of his favorite tactics was to spend weeks or months coming up with something in isolation. If you raised objections he’d brush them off by demanding to know your alternative. Which was horseshit - how could you have a viable alternative when he’d had weeks to come up with his idea and you’d only had 10 seconds, especially when these "ideas" are his fulltime responsibility and your responsibility is to ship 40 or 50 hours' worth of software a week. And past experiences had taught you resistance was futile anyway, so why pour your heart into a doomed battle in this latest bit of asymmetrical warfare?
This tactic played well to management though. He looked like the brilliant idea guy and you looked like the negative Nancy. This is a very common bit of political and rhetorical warfare and you see it everywhere.
It is, essentially, a tactic that has much in common with the dreaded "Gish gallop" - you fling stuff at your opponent faster than they could possibly refute it.
https://en.wikipedia.org/wiki/Gish_gallop
The cure for this in the software simple and difficult. Managers "simply" need to be aware of this possibility. However, they also need a certain level of technical chops IMO. If they're too far removed "from the trenches" they can't accurately judge the situation.

"The cure for this in the software simple and difficult"
Apologies. This should read:
"The cure for this, both in software development and elsewhere, is both simple and difficult"

I hate to be in your predicament. Software dev mixed with workplace politics is such a mess. Coupled with non-technical upper management that can be easily manipulated. I don't think the cure is simple and difficult, there probably isn't a silver bullet.

Thank you.
Luckily, I'm out of that predicament. It was actually really hard to see it for what it was when I was in it. That environment had all the trappings of a healthy engineering culture, and sometimes it truly was healthy, but only in hindsight have I realized some of the ways in which it was deeply screwed up.
What helped was talking with former coworkers, and going to work someplace that is actually healthy. It's not totally unlike finding yourself in a healthy relationship again after being in an unhealthy one.

At my last place "architecture by committee" did not appear to work at all. I think there were two reasons:
1) Lack of focus - everyone had their own annoying part of the system they wanted to fix badly and were not aware much about what going on elsewhere.
2) Our group of ~10 people would cost 10x of senior salaries to the company to do such architecture work. No manager would ever authorize that.

How big were the committees?
A group of 10 seems too large and counterproductive. I think a group of roughly 3 seems about right.

I worked at one company which did design reviews for major projects where one person would present and everyone would pick at it until some semblance of a decent consensus was reached and then said designer would go off and build their stuff.
That worked pretty well and kept each review fairly focused.
And it was generally one of my favorite parts of the day from either end.
It’s really nice to be able to sit with a group of engineers, hear each other’s thoughts, find things you missed, and get away from the laptops for a bit to thing about new systems.

There should be a single vision for how the software works.
This does not mean that vision should come from a single person. Ideally, it comes from the people who are able to contribute and critique that vision (other senior developers), with the acknowledgment of the people who don't have the information to contribute or critique (the junior coder).
This harkens back to the MMM and Mills's proposal.
> The surgeon. Mills calls him a chief programmer. He personally defines the functional and performance specifications, designs the program, codes it, tests it, and writes its documentation.
> The copilot. He is the alter ego of the surgeon, able to do any part of the job, but is less experienced. His main function is to share in the design as a thinker, discussant, and evaluator. The surgeon tries ideas on him, but is not bound by his advice.
> The success of the scaling-up process depends upon the fact that the conceptual integrity of each piece has been radically improved—that the number of minds determining the design has been divided by seven. So it is possible to put 200 people on a problem and face the problem of coordinating only 20 minds, those of the surgeons.
Chapter 4 is all about conceptual integrity of a project.
> Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds.

Anecdotal, but I've never seen democracy work out well for architecture level decision making.
If there's someone with a proven track record of making sound decisions at the required level, often the team benefits from just following their lead.
Obviously, this can't be another case of the 4x engineer making everyone else 0.4x engineers. Fairly situational indeed.

I used the word "democracy" myself, but I probably should have used a different word.
I would agree that it certainly shouldn't be a "one person, one vote" style democracy that makes everybody exactly equal regardless of talent, dedication, experience, domain knowledge, etc!

The Brooks model is to have a "surgeon", who calls the shots and owns everything about the development and process and tooling around it, with a support structure that assists and reduces risk, as he outlined in The Mythical Man-Month.

Code reviews help gate this behavior, a bit. If a coworker does this and drops a 40k line PR, they get code review duty for everybody else for a little while _before_ their code can get merged. Letting them go unfettered definitely is a mistake.

I've worked with too many engineers who got a lot done by making it hard for anyone else to get things done. I think there aren't very many 10x engineers but there are a lot of 4x engineers who make everyone else .4x engineers.
I was a lot happier and less busy trying to be a 3x engineer making everyone else into 1.5x engineers.

Ideally, this is how it works. Ideally you could even be a 0.5x engineer and make everybody else a 3x engineer and the team would still come out ahead.
That sort of work often goes unrecognized though, if you are an in-the-trenches engineer. Unless your manager is pretty hands on and spends time “in the trenches” with the team they won’t see that. Most organizations reward selfishness and punish benevolence. Not on purpose. They just can’t see it, because they are too far removed from the work and benevolence is nontrivial to measure. So it takes a back seat to trivial measures.

The first time this became an issue for me I pointed out that I'd saved a frustrating half hour a day for our dev team by making a series of QoL improvements. Across the team that was well over 40 hours a week. If you do things that make other people faster but not yourself then you look bad... to a shitty boss (and Mike was the shittiest I've ever had.)
These days I'm more likely to fix things that bother me and then share them after they're debugged. And often after I have my fingers in something new.
It makes me wonder if the proportion of 'scratch your itch' projects wouldn't be lower if people weren't disillusioned by the process of doing something solely for other programmers.

Reading your comment and the parent gave me goosebumps, I might be guilty of being this type of engineer.
I created a side project that became its own very successful product, and now there are a couple of other engineers in the team and I'm the "tech lead". We have a front end and backend component, and I have another brilliant full stack taking full charge of the frontend. the other two engineers are _very_ mediocre at best. The code is complex partly because I (without formal training) wrote it all myself, but also because it's a very complex priduct, not just a CRUD. I'm Constantly stymied by the fact that on the backend, asking the mediocre engineer to do something means it will take a full Sprint instead of the two hours it'll take me. The other engineers are also not able to fully understand the PRs (because the code is still too complex to them after six months joining the project) so I feel minimal upside to wait for their code reviews (which I still do anyways). I've asked to staff with better engineers but given the complexity of the product (directly query very large datasets with very complex jobs from a clean frontend) and our small orgs inability to attract great talent, I'm not getting anyone.
I'm forced with two possibilities: 1. Ask for the mediocre engineers to be removed from the team, and continue working on the backend solo (but making it actively a job to document and make it as easy as possible for a good engineer to take over after me). This would actually boost productivity 2x from what we are now frankly.
2. I stop coding fully or slow down 5x and work primarily as just someone who asks others to code. It would probably slow us down 3-4x,but I suppose it'll match the pattern of a regular team, though to what end I don't know.
Is there any advice you can give? I'm sure I'm not seeing something obvious here that I'm doing wrong, and am fully open to honest input.

So, I think any engineer can be "guilty" of this.
In fact, I might say that pretty much every engineer will be guilty of this if they have been in the industry long enough.
It doesn't mean you're evil! It just means you're the one who created a bunch of stuff and naturally you can work with your own stuff more efficiently than others can.
In fact I actually was "this guy" with one section of the code at my old company; the one where we had the "faux 10x" architect-dictator. I did manage to achieve a fairly clean transition once my involvement in that bit of the code ended.
Ask for the mediocre engineers to be removed from the team
It sounds like this codebase is significantly complicated that even above-average engineers might find it an uphill battle. Is this true? If so, perhaps the answers are the largely the same whether or not the mediocre engineers are replaced.
"asking the mediocre engineer to do something means it will take a full Sprint instead of the two hours it'll take me" "[Transitioning from coder to mgmt/mentor] would probably slow us down 3-4x"
How many hours of useful coding do you do per day? There are a lot of studies that suggest even great engineers don't code for more than a few hours per day. I don't think I'm great, but this definitely applies to me.
Maybe you could divide your time in a way that's not too painful. Perhaps you could spend a fixed 1-2 hours per day on knowledge transfer (pair programming, etc) and not impact your productivity.
Here's what I would say.
0. Get buy-in from the rest of the management/leadership team. They should fully support your efforts to get others up to speed. Tell them you are concerned about being the only one who can maintain the product effectively. They should NOT want you, personally, to remain an indispensible single point of failure. What if you leave? What if you are hit by a bus?
1. As I said above, if you can devote perhaps 25% of your week to full-time knowledge transfer, you might find that you accomplish a lot without sacrificing your other productivity unduly.
2. Pair programming is, I think, the fastest form of knowledge transfer. An hour or two of pairing with the newbie engineers at the outset of a task goes a LONG way and may save dozens of hours later in the sprint. It sounds like these engies should never, ever begin a task without this guidance from you. They will learn the code, they will learn the thought process that went into the code, and they will learn your problem-solving process.
3. Is your test suite awesome? Writing or improving tests can be an excellent way for folks to get up to speed on the code in a low risk way. And a strong test suite has long-lasting benefits. If you don't have a test suite at all, even a very rudimentary one will reap large rewards down the road.
4. I document my code (via inline code comments) more than most. My opinion is that if a bit of code represents a non-obvious technical kludge, or a bit of business logic, it should have an explanatory note. Theoretically this could be accomplished via diligent commit messages, but sifting through hundreds of commit messages is awfully tough.
5. YOUR ENGINEERS ARE PEOPLE. Working on your legacy hairball of code is... frustrating. Recognize their pain. Be sure to get them some "wins" on a regular basis so they can feel good. Praise their efforts in private, and in front of others in meetings.
Good luck to you! My email is john edmund rose "at" gmail if you want to correspond. I'd like that!

The telephone game taught me why there should be a “how the system works” runbook in writing. At 3 AM, I don’t want to try to remember the lecture I got from someone who was trying to remember the lecture they had gotten from Saint Paul or whomever.

Really like this.
“Average” engineers manage to be productive with React, Spring, WPF[1]... These are not simple technologies. Why can’t “average” engineers be productive with my stuff?
Quite often it’s because these bigger, more complex, projects have far more comprehensive docs.
It sounds like this codebase has a fair few abstract concepts in it. Those things can be hard to understand without comments and docs explaining core concepts.
Sequence diagrams are also great. I like generating sequence diagrams from logs during automated testing so they never go out of date.
I also find it useful to have docs at the top of each class (or file) explaining 1. what its responsibilities are, and 2. what it collaborates with. Like the old CRC cards.
Obviously this stuff can drift out of date, but it’s less of a problem with the core bits of the system once they’ve settled a bit.
If they don’t exist already, it’s nice to write docs by pairing with new devs.
It is of course possible your engineers really aren’t up to the job, in which case the effort you put in to explaining things now will still make things easier for their eventual replacements.
I had all this wrong for so many years.
[1] whether these are “good” technologies is beside the point here

I think you're failing to prioritize the right things about your code.
The primary purpose of source code is to be understandable and manipulable by other engineers. No matter how well it accomplishes its goals, it's not "good code" unless it can be understood by other people.
I question whether you're actually working with a "very complex product" - it might just be that the way you're representing it is complex. If the code is still too complex to other engineers after 6 months, it's not the engineers who are wrong. At 6 months they should deeply understand some parts of the code and have confidence about diving into and understanding other parts with some ramp-up time.
I say this as someone who writes a lot of code that other people find hard to understand because it's "clever", and it's taken me a long time to fully internalize that, when someone else can't pick it up, it's not their problem, it's mine. Code is user interface, and good user interface meets the users where they are, not where you wish they would be.
Honestly, this aspect of software engineering is really the bottom line hardest part - it's not getting a working binary out of the compiler/interpreter, it's about getting a living system to evolve well. That means nomenclature and abstractions have to be top notch, not just the algorithms.
There's an old saw about "if it's twice as hard to debug code as to write it, never write code that's more than half as clever as you're capable of, otherwise you'll by-definition be unqualified to debug it", and I think there's a lot of truth there. One of my old director of operations used to say "If you can't run the playbook at 3am after being at the bar, it still needs work", and I think that's also true of non-ops related code.
Your next step is to reorient your role: your job is no longer to ship features, your job is to make the code easier for your coworkers to execute in. You're right that you'll "stop coding" as seen by management: your new bosses are your coworkers. Treat them as your customers, have them file tickets, the whole nine yards. When you reach the point that your coworkers are faster at getting things done than you are at the moment, then you can turn your sights back to production work, but until then, your job is technical debt remediation.

> The primary purpose of source code is to be understandable and manipulable by other engineers.
I've never worked in a fantastical position like this. The only purpose of the source code that I've been a part of was to provide a real solution to a real problem, in a limited amount of time, with too few resources. Technical debt always increased slowly until features are removed or break, forcing some dedicated work.
Can I ask what industry you're involved in where code quality is held higher than profit/deadlines/solutions? I would happily make the jump.

I've worked in a lot of industries from heavily-regulated healthcare, financial, core developer tooling, and a lot of YC startups. It always pays off in the end to consider code primarily for engineers, and every time I see people take those kinds of shortcuts in non-bet-the-company situations, they regret it. Especially in situations where you're handling large flows of cash or data, a percentage point can sink your entire business. Certainly a HIPAA violation can add zeros quickly.
I've actually been doing a lot of turnaround consulting with companies that took a short term mindset, got stuck, and had to step back and revamp their technical processes like you say. It's always more expensive to redo it after the fact, but I'm happy to take their money and fix their mistakes.
And that's not to say that it's not a tradeoff, but it's about being conscious of the tradeoffs involved and making reasonable choices.

I’ve worked on code that’s both ways. That is, either:
(1) spaghetti code that relies on the author having a great deal of it memorized. It uses opaque types that get passed through multiple modules. There is no hard separation of modules. Consequently it’s easy for someone who knows the system to reach into any part from one part and immediately get something done. However it’s a nightmare to make changes on otherwise. Unless you have an near-eidetic memory, it will likely negate any coding skills.
(2) Strongly typed and modularized code that takes advantage of advanced language features. In this case, it requires somebody of a certain proficiency in the language, but they only need to focus on one module at a time, and the compiler will stop them from violating architectural assumptions.
And these aren’t mutually exclusive, nor are they binary.

If you were as good as you think you are, you'd be able to write code that other people can understand.

I'm guilty of that sort of thing as well (doing something complex without enough training to properly code it).
Story time to drive home my points: I started 7 years ago, fresh out of uni with a diploma, but not enough experience, and did something overly complex, with a lot of frankly bad code. Then, 5 years ago, we expanded the team (which means I was no longer the sole developer, but we were now 2).
At first, I was not satisfied with the other developer (fresh out of uni as well). Instead of trying to fire him, I bit the bullet and answered every question, took a lot of time to explain things to him. Yes it slowed me a lot. It also forced me to up my game to make our codebase readable (not MY code, our codebase), add comments etc...
In the end, he is now a valuable team member (we are still only 2 devs, with the occasional intern) who knows most of the codebase as well, if not better, than me. It has been the case since about 3 years (it took him 6 months to have a decent development speed, and about 2 year to develop at about the same speed as me). Neither of us consider himself a "rockstar" developer and that's fine. We work as a team, and as a result our code is better, faster, more readable and as less bugs. I couldn't achieve that level alone no matter how much I tried.
To sum up: train them relentlessly, without loosing patience, and use that as an opportunity to make the codebase more readable.
You didn't mention how much time those engineers have been working with you though. Common knowledge is that it takes at least about 3 months to be proficient with a codebase you are new to. More if you are not experienced.

Programming is a trainable pursuit. Perhaps they are mediocre, or perhaps they are even bad. So, the best thing you can do is spend a significant portion of the time pair programming and seeing the project through their eyes.
Second, you probably should be taking some of that time you are coding and instead extensively documenting how it works, the design methodology, and making sure the unit tests are covering the code. After all, there are many implicit decisions in the code that they have to re-discover.
If you don't have tests, it makes working on a project as a new engineer difficult because you have no guard rails to know if something broke, especially because the specification is only in your head.
If you invest in your other engineers and in the process, they will become much faster and that slow down is a temporary bump in the road.

Is this superhero syndrome? Where the engineer creates messes that only they can truly clean up? If not, what is a better term here?

There should be a term for it, so that people like me can describe it in less than a billion words.
Wikipedia says:
People with hero syndrome generally cause an accident or disaster with the intention of then coming in to render aid, and become the 'hero'. The reasons for this often vary. The perpetrator may be trying to validate their own self-worth, or be seen as brave by others.
From that description, it sounds like the would-be "hero" in hero syndrome deliberately creates these disasters.
I think things are a little less clear-cut in the sort of (common, IMO) engineering scenario I was talking about.
I feel it's often more of a systemic situation, where the company/team does not properly value the knowledge transfer, empowerment, and management skill necessary to avoid those situations.
In the specific situation I described I don't think our architect intentionally created messes, and I think probably believed at each step of the way that his actions were best for the company.

Let's call it 10X syndrome. Spread the word!!!

To play devils advocate: If he was as brilliant as you imply perhaps he SHOULD have been the one making the key decisions under his purview anyway.
This almost sounds like bitterness coming from the other side of the team.
Not everything is a team decision and nor should it be.
Often times brilliant engineers, in order to express that brilliance, need to be left alone by over zealous managers and jealous teammates that would rather argue than get work done.

Hello, fellow brilliant engineer here.
In my experience, it is not as often as you might think. The key issue comes down to brilliance coupled with selfishness.
If you look for it, you can see some common themes in these comments: "...the other team members were all forced to work around his refactor and waste time updating their PRs to match his work," or "Meanwhile we were all left to deal with his fallout," or "...this particular eng ... ended up costing almost as much to clean up his mess as the value we got from him in the first place." We have all had to work with that guy. In the early part of my career, I have been that guy.
People are not arguing because they don't understand your brilliance and are jealous of your productivity. It is because you are making their lives harder. That is what makes people bitter.
Turn the problem around: instead of asking "how can I get all of these over-zealous, jealous people to leave me alone", ask, "how can I apply my brilliance to make their lives easier instead of harder?" Unless you are doing something basically trivial, there is usually too much work for any one person to do it all by themselves, no matter how brilliant. You need those people. So help them out. You will have a much better time. And so will they.

> To play devils advocate: If he was as brilliant as you imply perhaps he SHOULD have been the one making the key decisions under his purview anyway.
I think you missed the point.
It's easy to operate in a vacuum. If you maneuver yourself into a position where you can only ever operate in a vacuum, you avoid the real difficult work: Coordination, communication, cooperation. That work doesn't just disappear, though. The rest of the team has to pick up the slack, fix the leftover bugs, work around the lone wolf's quirks, and so on.
If a project requires more than a single person to scale, then those people need to work together as peers. If you let one person run away with the fun work and leave everyone else to clean up the bugs and pick up the scraps, it's not a sustainable situation.

>To play devils advocate: If he was as brilliant as you imply perhaps he SHOULD have been the one making the key decisions under his purview anyway
If he should have been. Then he should probably have been lead eng or something.
His authority and actions were mismatched. Management can change either side of the equation.

> We were lulled into letting him make key architecture decisions in isolation, because no one else was awake or online at the same time to discuss them.
That sounds like a process rather than schedule issues: important architectural decisions shouldn't be performed "on the spot" but only after some sort of discussion. Preferably in writing.
> If he refactored the codebase in the middle of the night to make his job easier, the other team members were all forced to work around his refactor.
Don't you do code review? People shouldn't be able to push code without another person looking over it.
These issues would also apply to remote or off-shore workers.

If you are the lead you generally have permission to push directly to master. This isn’t always something you do, but it’s occassionally helpful to clean up the last mess before a release.

Sure. Not ideal in theory, but in practice that's generally reasonable. But if it's a regular thing, it should get called out and addressed one way or another (i.e., even ignoring the pathology that this conversation covers, if there's always a mess to fix right before release, then your process needs to be revisited).

There's a world of difference between "clean up" and "refactored the codebase in the middle of the night ... [and] other team members were all forced to work around his refactor and waste time updating their PRs to match his work".
"Clean up" would be things like fixing typos/docs, bumping version numbers, fixing a build script because some path/version/etc of some external dependency changed, and sure -- mostly that's fine. If you're doing proper CI, there should be little to no surprises like this in your master branch, because you shouldn't be merging branches that break the build, and the "final release" build is really no different from any other build, other than you label it "release" (or "GA" or "RTM" or whatever) after the fact.
Refactors and any thing that could be classified as an "architectural change" really must go through code review. If someone thinks their skill is so great that reviews are pointless -- I absolutely guarantee in 100% of cases that they're gravely mistaken.
If the rest of the team can't understand the changes, well, they're bad changes, full stop. This is the team working on the code base, they are the ones that have to be able to understand it. This can be fixed of course, by firing everyone and getting a better team (just kidding), helping raise the skill level of the team, or by simplifying the changes. In my experience though, if no one understands it's usually a sign of overly-complex and/or under-documented code.
Code reviews are a two-way street, and learning is not just for the reviewee -- it's a great opportunity for the reviewers to learn, too. They get to see how someone else solved a particular problem, with rationale, the opportunity to ask questions (and 80%+ of the time, a question about how/why is usually an indicator a comment in the code is missing), and "current context" (eg: it's a change that's probably been discussed in the days/weeks before).
If the changes really are good, and it's a good PR (eg, not a massive, surprise major refactor that touches thousands of lines of code) then the PR will pass easily.
And seriously, if you need to do a massive change like this in a rush right before a release, then the team probably missed something major and the release simply isn't (and was never) ready. Major refactors means brand new code, and putting brand new code into a release with no testing (not even dev testing!) is a terrible idea.

> Instead, he used the odd hours to force us to give him only work that could be accomplished alone
Ding ding ding. We have a winner!
A big problem with people like that is that at the end of the day, writing code or building stuff is the easy part. Communication, coordination, mentoring, onboarding, figuring shit out, etc, is the hard part.
People who hide for large parts of the day or multiple days are usually just dumping the hard part on others. Since the industry is often stuck thinking that line of codes === worth, these people seem more productive. Often, it's the polar opposite. They're freagin useless and anyone else in their situation would do the same or better. Everyone else is slower because of the increased burden (who's answering questions when Mr "I work from 5pm to midnight" isn't around?

If people are regularly interrupting their development work to answer questions, then it suggests that documentation isn’t a priority and/or the team isn’t being very productive. Async communication often works fine as long as people are willing to read and write in detail.
And you can often work faster if the code is better organized and self-documenting than if you have to spend an hour meeting with another dev to understand it.

There is a compromise. I have a tendency to work odd hours because it's much easier to get actual work done if there's less distractions. On the other hand, I do feel it's important to have at least 1-2 hours overlap with other people's schedule to ensure that there's buy-in for any major changes in the code base.

I've gone from loving Flow state early in my career, to being cautious about it, to watching with suspicion and dread the behavior of my coworkers to see if they are making decisions based on opportunities to engage in it instead of rational thought. For some it seems like a form of thrill seeking.
When you are in flow state you are producing a lot of output but aren't asking any questions. That turns into big, solid chunks of the system with no oversight, no consensus, no introspection, no empathy. And when someone does ask questions - because who wouldn't? - we aren't questioning a small isolated part of the architecture, we're questioning a very big piece. One that the author feels very warm feelings about because they had An Experience while writing it.
Flow state is useful, possibly great for refactoring. It's occasionally a waking nightmare for new code, and not a great experience for everyone else the rest of the time.

Flow state is where I build trash that works, so that later I can refactor it into elegant code that doesn't.

This is where mandatory code reviews really help. He can't merge that crap and mess everyone else up without someone approving the changes.
Also, to be frank, if his code is reverberating all over the code base like that, causing merge conflicts and re-write all over the place, he is a terrible engineer - not a brilliant engineer. He clearly had no knowledge of the basic SOLID principles, modularization, encapsulation, etc. He was a rookie blasting experiments all over the code base.

Well, or the code base had no organization to begin with and he’s moving in that direction.
Sometimes individual people can be very focused on their particular assignment and greatly resent somebody forcing them to make even small changes. Even if those are to make a global API smaller and more consistent.

>In my case, I eventually learned that the odd hours weren't the key to his perceived success. Instead, he used the odd hours to force us to give him only work that could be accomplished alone. We were lulled into letting him make key architecture decisions in isolation, because no one else was awake or online at the same time to discuss them. Eventually he became the architect by virtue of operating in isolation, where we couldn't discuss his decisions.
McCarthy's 1995 book "Dynamics of Software Development" has a chapter devoted to this phenomenon.

>Eventually he became the architect by virtue of operating in isolation, where we couldn't discuss his decisions.
I had opportunity to see some projects that went in the wrong direction by bad architectural decisions resulting from an opposite behaviour. Every architectural decision would be made based on everyone's input where most junior people's opinions would weight the same as most experienced. In the end decisions were made primarily based on how simple the solution appears and not based on its suitability for performance, future extensibility, maintainability etc.

This is one of the often unspoken benefits of remote work—it obscures how (and when) you work and exposes only the results. This naturally pushes back on micromanagement not only from managers but also from everyone else on the team.
It's not fool-proof by any means—you can still build up processes and expectations that lead to micromanagement if your managers or culture are so inclined—but it makes the default behavior of the team distinctly less oriented towards micromanagement. You'll waste a lot less time and energy worrying about optics if people being present at a particular place and time is not an obvious signal of dedication/hard work/whatever.

in the age of slack, where managers about to instant message you any second, you don't really get control of your schedule

Between this and the memory complaints, I have to ask: Has anyone tried closing Slack?

At some companies you can get a negative performance review for not being on Slack during working hours. “Needs to be more responsive / better team player.” In other places you might be expected to be online beyond 9-5 too.

It's difficult but I'd avoid places like that. If your team won't allow you to close slack for an hour you have serious communication and planning problems. Anywhere I've worked what I do is message anyone who might need vital information from me then just close slack for an hour, do my work and check back in. When I get pulled up on it I give my explanation about focus, communication etc. If they don't like it then I leave. I'm glad it's a seller's market.

Oh hey, I am relevant for once. I moved to another city for university a while ago, but kept the job I had before as a half-time remote position. At first I felt extremely pressured through slack. People didnt know my exact schedule and would also write me on days off, and I felt like I should answer asap, because otherwise people would develop the idea that I slack off because I get to work remote.
Well, after a panic attack I changed my approach and asked my colleagues to write me mails instead or ask me on teams where I would only be online on certain days. Everybody just said sure, and work is finally fun again. I think I wasn't the only one either, more and more people started avoiding slack and only look into it maybe once a week.

Once I was told by my manager to close Slack and focus on my work, and only check what's new about twice a day.
A week later, the same manager got angry at me for not responding to client's urgent issue which was announced by Slack an hour ago.
So... yeah, closing Slack improves things, until it suddenly makes them worse.

Too bad those cases usually don't have an email history to prove the prior ruleset... or it just disappears and anything's possible...
Worked for that kind of team before. Never again.

I'll never understand this sentiment. You don't have to have alerts from slack outside of business hours. Or respond in general. If I responded or looked at my messages every time I got one, I'd never get work done... so I simply ignore them until I am taking a break or otherwise at a good stopping point. It's not that hard.

As if managers had no way to interrupt you before Slack came into existence.

After my wife had someone lie about 15+ hrs of working at home, I stopped believing in the "work at home" trend.
I understand it works for some, but since it doesn't work for everyone, I can see how people would be offended by an "unfair" policy.
Sure, if there is a clear start and end, these things could work. But on creative work that could go on forever, it's easy to cut corners.

If they're getting the necessary amount of output who cares if they spend those 15 hours with their kids instead of browsing reddit behind the boss's back?
The inability to track actual output levels doesn't go away when everyone is in the office. Instead you promote the person who is best at looking busy instead of the one actually outputting the most work.

It matters if they're getting paid by the hour. I used to work with someone who was good at handwaving away why his work was falling behind, and the management believed him. In reality, he was missing deadlines because he wasn't working a full 40 hour week. He'd record his commute as working hours because "he's an engineer, and thinking about his work is just as important as doing work", so he ended up working ~10 hours less per week than everyone else because he claimed that thinking about work on his commute counted as billable time.

>I used to work with someone who was good at handwaving away why his work was falling behind, and the management believed him.
So you had a management issue rather than a worker issue.

But how would the situation have been different if he'd been underperforming despite working the correct hours? I don't think that would change things, except that it might make it harder to fire him.

>"he's an engineer, and thinking about his work is just as important as doing work"
Not meaning to devalue your comment, but this is such a bs excuse from him. Like, I definitely think about solutions to work-related problems outside of work way more times than just during my commute, and I bet that's the case for a lot of people that do any sort of intellectual work (all kinds of engineers, lawyers, researchers, accountants, etc.).

Rest assured that your lawyer will bill every second he spends even thinking about working on your case.

And that's one of the reasons those positions are often salaried.

Engineers are generally salaried for this reason. Although, personally, I very much do count thinking about work problems as work hours no matter what time of the day it happens.

In practice, the only thing that really matters here is the phrase "his work was falling behind". And "he was missing deadlines".
It doesn't matter if a worker is secretly pulling 80 hours or 10 hours a week instead of the 40 (apart from legal/contract issues). If he's doing less than agreed between the parties, that's a problem. If management bought his excuses, then there's a problem with management.

1000x this.
I don't get how anti-remote persons manage to track office workers' performance.
Either you measure output, or you don't.
There are valid arguments against remote work, usually related to communication, but performance measurement? Nah

Just another point in favour of working at home friendly companies.
Less likely to be employed by someone who measures your output by hours.

I am one of the people who work better in spurts of productivity.
I love that my company has a loose work from home policy. To me that means, I can go in the zone without being interrupted, but also that I can work on those not-so rare nights of productivity boosts from like 11pm-3am.
I'm no rockstar tho. Just a regular employee with wierd productivity graphs.

I've found the more senior I get, the less spurts of productivity are tolerated. People will rattle on about consistency and expectations. Especially so if this is more on the scale of weeks than within a day.

I can easily be productive when I am working with people on business problems. But, for coding, I need time to get in the zone.
In contrast to your case, the managers in our team do not do any coding at all. I imagine you are talking particularly about senior ICs.

Yes. If you're a senior IC and tend to do several days work on your good days but get little done on your bad days, depending on the boss you have this can cause a lot of friction (even if overall you're producing a lot).
There's a strong tendency to "watermark" your productivity, and ignore circumstances around it.
Today is a perfect example, I got to look at code only for the first hour before I got a pinged about an issue somebody thought was related to code pushed out last week. It turned out the issue had nothing to do with it, but I had to investigate that. Then I got pulled into a conversation about why a certain number was up and how we might ameliorate that; came up with a pretty simple solution someone else is implementing... but then I got asked if I still was working on some low priority ticket so I had to figure out what that was, and then my boss wanted more details in our weekly status update so I had to search up some docs and tickets and stick them in there. Right now I have 15 minutes between lunch and a meeting with HR, and no, I'm not using it productively - because how far can I really get in such a small time window?
I budget for this reality in my estimates, but often get pushback. "Is this really going to take a week?" Well, no, it's not. If all this crap was pushed out of the way it could get done in a couple days, like project X did. But the reality is I'm halfway through my workday and had at best an hour to code uninterrupted - much of which I spent checking my email and doing code reviews because I often get tagged for not doing those things often enough
There are quiet days when I can just code, and there are days like this. And even in the former category, not everything is perfect; sometimes I didn't sleep well or have other personal stuff. But the days everything went well sets the expectations, while the reality is much less predictable.

“It’s going to take a week for the org to let me spend two half-days on it.”

If you've got Outlook or some other calendaring tool, fill it in with each external request when you get done with each one... when performance is questioned, you can review the history and hopefully get a more reasonable, "oh, I see" level response.

When a team is close in abilities with a single outlier it can be difficult to have special cases. Because there isn’t a wide variation between people policies are expected to be “fair”.
The alternative is strict hierarchies where its made clear that some people have better abilities. That comes with extra privileges (money, flexibility, etc).
The one thing you can’t get away with is pretending everyone is equal but some are more equal than others.

This is textbook bipolar behavior -- periods of intense productivity offset by periods where you basically stay in bed for a few days. I suspect he works the way he does because it's how he has had to set up his life to be able to keep a job. Work is a healthy outlet for manic energy, but it burns you out fast and you have to hibernate for a bit when your mood turns. I know I personally am toxic as hell if I have to be at work when I'm in a depressive state, so it's better for everyone.
I say this because bipolar disorder is a protected condition under the ADA, which allows for work modification. We tend to end up in positions where deadlines are soft and there's a lot of individual work that can be done asynchronously, so there are a lot of us in software.
This may not have been the case with him, but I do think there's a lack of awareness of mental health issues in the workplace. People who struggle with mental health can still be great employees in the right circumstances. If there were better awareness that people struggle with issues like these, I think there would be fewer issues with co-workers.

Someone works long hours sometimes and therefore they're probably bipolar? What?

I don't know if that was the case with this guy, just that the schedule OP described is the kind of schedule that a bipolar person might end up with. But the main point is that building a work culture that can handle this kind of schedule from people who really need it (for whatever reason) is a good thing, and there are good reasons beyond mere convenience that a person would work a schedule like this.

Oddly enough he did confide in me that he was bipolar.

Considering that I had the same thought, no.
However, most people cannot regularly work 48 hour shifts except under duress. (IE, their life, job, or crisis depends on it.) Many can do it once, but need a significant break afterwards.
If someone is regularly cycling like that, it very well could be a coping mechanism for bipolar.

Spoiler alert: the guy was taking amphetamines.

Seems like the only way to regularly work 48hr shifts.

Long hours is like 10, maybe 16 for a serious emergency (like building-catches-fire level stuff, not like "oh the API is down" stuff - it should happen less than once a year).
48 hours, even once, is a serious problem.

I often work from 9 am to 3am. The problem is when I start something interesting at 5pm. Between 5 and 3am, a box of cookies (Prince, they’re quite addictive). Total 16-17hrs, plus a good lunch break. I think being sugar-high has an amphetamines-like effect.
I know it’s not healthy, but I have unresolved issues that remain unresolved after 10 years trying to get help. At least it’s not alcohol. But that’s also perhaps why people don’t see the distress.
I work to forget.

I'm confused, what is a SWE going to do during a 16 hour shift about their building being on fire?

"Back in the day" we used to have physical machines places. A DC catching fire (or flooding, getting hit by lightning, or etc. etc.) meant "manual failover" and a day of restoring backups.
(And that was best case, if your infrastructure and deployment scripts were up-to-date. Most people's weren't; probably the ratio is only slightly better today.)

I assumed it was an exaggeration, like 48 hours with a break to sleep, because how could OP even know for sure that it was truly 48 hours without break if the guy was at home?
I'm still suspicious whether it was actually 48 hours straight with no rest because -- no matter how brilliant someone is -- I would be extremely leery of the code written toward the end of that session.

I suspect people who were around for the dotcom bubble, or who have worked on consumer software back when it had gold master dates, don't read it as an exaggeration. I did not, and know several people who worked non-stop 30-60 hour shifts for various reasons.
In my case one had genuine clinical manic episodes and was open about his mental illness; another seriously burnt out; older friends in the games industry spoke of multi-month post-launch vacations (back in the late 90s) to cool off.

Unless you are using drugs it's very unnatural for your body to allow you to stay awake for 48hrs. It is however common in people with bipolar.

I think you're jumping to conclusions a bit, based on your own experiences. It's textbook bipolar behavior, sure, but it's also textbook a-hundred-other-things behavior as well.
Take me, for instance: as far as I know, I'm not bipolar, or anything else. The best framework for understanding myself I've found is that I'm an INFP.
Though it might look like I prefer to work in bursts and then chill out for a while, the reality is that few things stress me out more than deadlines, and getting into a flow can take a while; while I'm in it, I'm reluctant to let it go prematurely, so I end up going until I tire out, and then I need a rest, which (in a perfect world) can sometimes take two or three times as long as the preceding flow period. I'm also only really motivated internally -- doing things just because I'm supposed to is a recipe for me doing them badly, but doing things I care about is nearly always a recipe for producing very strong work.
I'm also pretty emotionally-driven (from the MBTI standpoint, I'm Fi-dominant) and am drawn towards my negative (Te-inferior), so it's no surprise that I do creative work (music) that requires lots of control and technical know-how (writing music to picture i.e. solving a problem, lots of gear to understand; this draw-towards-the-negative is why I've ended up frequenting a place like HN -- I like the control that programming gives me, even I'm still quite an amateur). This industry has terrible deadlines though, so that's still a problem that I simply endure, and do my best to work around with workflow and efficiency hacks.
Being primarily motivated by my feelings and values means that I can easily get into a slump. It's like depression, but as far as I can tell, probably not "real" depression. Just more like "Highly-Sensitive Person" living.
From the outside, I suppose that my way of being could totally be seen as bipolar or something like that. But the devil is in the details. All sorts of states can produce similar results.

I'll put it this way: if you are able to regularly and productively work 48 hours straight of your own volition, you already meet a lot of the criteria for hypomania.

I have bipolar disorder, and the behavior of these "brilliant" engineers working late at night and exhausting themselves for days runs very true for me. It's really the only way that I've found to work successfully in any sort of deep manner. Essentially, this sort of behavior is in response to my disorder.
Mental health disorders are very, very, very, very hard. Not giving engineers with mental health disorders the room that they need to grow is doing everyone a disservice. And yet, the stigma around mental health disorders is so high that that conversation will not happen anytime in my lifetime. At the end of the day, myself and the others like me, are pushed into the dark further and further. It really sucks, and the only place for conversation about it is in therapy and close friends. Mentioning it at work leads to risk of retaliation. So, we cope. And then people write blogs about people like us, without taking into consideration that there's likely some mental health issue going on.
And, for what it's worth, talking about things in terms of MBTI isn't helpful in a conversation about mental health disorders. You might as well be talking about horoscopes.

Heyflyguy comments downthread that the guy did indeed confide in him that he was bipolar. It seems wayoutthere was on the money.

Yeah, I saw that as well. Regardless, I think my point stands -- I find it pretty alarming how quick the internet is to armchair-diagnose people with serious mental illness.
For example, a good friend of mine was internet-diagnosed with Schizophrenia. He believed it, and going down that rabbit hole screwed him up for a while.
Turns out that he and a long-term daily weed habit just weren't really a good mix (the paranoia led him to take it more seriously than he should have -- and the fact that "paranoia" was one of the supposed "signs" of Schizophrenia only made it more believable). He stopped smoking, and within a couple weeks saw just how ridiculous a turn things had taken.w
My point was simply that people are complex, and one single behavior isn't really enough to go around stating that a person might be X. A person can be inclined towards a certain work habit for loads of reasons.

While not directly what the OP/GP mentioned, sometimes it's worth noting that, if a person suffers from some symptom, they'll probably benefit from advice to (a group of) people who suffer said symptom. This is true regardless of whether said person is part of said group.
If Greg has issues concentrating, and someone says "I know people with autism can suffer from that, and they find stimming helps", then even if Greg is not autistic, they may be well served by that advice.
That said, they won't necessarily be well served by all advice (Ask your doctor for Ritalin!), and I'd personally rather leave it to themselves and their medical practicioner to diagnose/decide whether they're actually part of any given group.

MBTI is actually complete pseudoscientific nonsense with zero empirical backing: https://www.vox.com/2014/7/15/5881947/myers-briggs-personali...

I'm not trying to give offence internet stranger, but Myers-Briggs is bollocks, and it certainly sounds to me like you should see an actual professional to see if you're bipolar.

Sigh...I'm not bipolar. I thought I made that pretty clear in my post.
I am literally never manic. Sometimes I get pretty down -- that's it. Very well within "normal" range. And yes, I've talked with a professional about these sorts of things (when I saw a therapist for a couple of years), and the notion that I am mentally ill, beyond perhaps being a so-called "Highly-Sensitive Person" (a classification I find fuzzy and dubious, but whatever), was outright dismissed and was honestly found to be kind of laughable -- me brining it up was more a sign of my own insecurity/difficulty in accepting that I was seeing a therapist than anything else.
I don't really care to get into a discussion about Meyers-Briggs, as they don't really go anywhere on this site. If you care to read, I've explained my views on the topic elsewhere on HN in more detail: https://news.ycombinator.com/item?id=20888175

I'm bipolar and that's pretty much how I work. If you are in a hypo phase, you'd better spend it somewhere useful.

> I say this because bipolar disorder is a protected condition under the ADA, which allows for work modification.
Allows for but doesn't require. Workplace accommodations for any disability have to be reasonable and it's generally up to the business to decide what's reasonable. You can sue but most businesses would not find it difficult explain why it's important for employees to be working roughly equivalent hours and in the office if that's what everyone is doing.
BTW, deciding your own hours with little direction about how you complete tasks sounds more like a contractor than an employee.

Agreed. About 15 years ago I worked alongside a developer who worked like this. He was a very good engineer (not some savant as in the parent's example, but arguably the best in the organization when his mind was right). His mania had people convincing themselves he was a great engineer, like a black turtleneck and bravado convinced some that Elizabeth Holmes was Steve Jobs 2.0.
Unfortunately, he carried substance abuse and relationship issues with him as well, and eventually his health deteriorated.
When I reflect back, I realize nobody could relate to him because he was ill and needed help. Not because he was smarter or more capable than everyone else.

yesh I knew a developer like this, except that he was from what I could see a capable 1X developer just with a screwy schedule (although maybe he was doing another project on the side - that was his excuse at any rate) but really my theory, based on his habit of disappearing into the bathroom for extended periods of time and my familiarity with junkies, was that he was a textbook high-functioning one.

How common is it for a manic or depressive phase to only last a few days? My reading on the subject and experience with people who have this issue would suggest it's measured in months. Although I guess I have also heard of terms like "rapid cycling".

It depends. It can last a day, a week, a month, or even longer.
Consider that it's "just" a mood disorder, where mood management can be affected by random stimuli. So, their mood might be stable until some stimulus comes by. And that stimulus could just be a random memory, which can create a feedback loop. It's "fun".

I've been successfully managing a bipolar disorder for over ten years - and unsuccessfully for years prior to that.
In my _personal_ experience, manic phases last 2 weeks to 2 months, followed by 4-10 months of catatonia.
It is approximately the same for my aunt and grandmother. In their cases, lithium and electroconvulsive therapy were the only things that work. For me, lamotrigine and modafinil are life-changing wonder drugs.
That said, people in my group therapy reported cycles as short as days to weeks - rapid cycling, as you say.

I'd guess, like another commenter, that some people might get this type of oscillating behaviour due to feedback mechanisms: working for 48 hours straight (enabled by mania) could trigger a recession, requiring intensive recovery, which enables a new visible episode of mania.
Note that the "off time" need not be matched by a depressive episode (and in fact I find that unlikely, since depression is not very restful) -- it could simply be exhaustion hiding the symptoms of the underlying (long) manic episode.

I think there's a number of creatives who have sub-clinical manifestations for ADHD or bipolar and don't really qualify for meds but still would benefit from schedule adjustments, and I don't think they necessarily should need a diagnosis for that. It should not arouse suspicions in people's coworkers that Bob, who is otherwise kind, dependable and competent, works an odd schedule.
(OTOH, there are other explanations for the weird schedule. Substance issues, unusual home life, etc. I think people generally should be tolerant of weirdness, but ready to hear about the seemingly brilliant people's awful struggles.)

Right, I think this is the real answer. I don't (and shouldn't have to) disclose my bipolar to my boss / coworkers under any circumstances, but a culture that allows for the fact that not everyone performs to the best of their ability under a traditional 9-5 goes a long way to being inclusive without singling anyone out.

I'm bipolar II and I'm right there with you on work output and aligning your schedule with your illness, however as others have mentioned it's unfair to assume the subject in question is also bipolar simply based on his work schedule.

I could easily be wrong but I didn't think he meant the engineer literally worked 48 hours without sleep or rest, then literally slept for 48 hours. I took it as: the engineer regularly shut out everyone for ~2 days straight and did long, extremely focus coding sessions, then shut out all work for a couple of days to decompress. Taken that way, it's not bi-polar or mental-health issue at all. Seems like this engineer just had the guts to stand up to everyone's ordained-from-the-heavens schedule of interruptions: "I'm gonna ignore distractions for two days to work, then ignore distractions for two days to rest."

I would have floated the suggestion of a contracting arrangement for the high-performer.

I've been that guy before, at my first serious early-stage, well-funded startup.
The founders and executive team completely fucked it up. They kept hiring crappy/unmotivated people, prioritizing growing the team in quantity over quality, and with every added mediocre head it only amplified the morale drag when I'd be delivering huge progress after multi-day sleepless sprints while everyone else was barely getting anything done in the 9-5 office productivity theatre of standups and meetings.
I started absolutely dreading coming to the office after completing one of my kamikaze sprints. The VP of Eng had established this twisted pattern of holding a standup the moment I leisurely walked in the door at whatever hour I happened to make it in after not being seen for days, which for over a year was the weekly norm. Everyone in engineering would have little to nothing to say about their progress, and I'd drop another mother lode. It just made everyone else feel inferior, and I started to increasingly abhor their lack of progress and feel like I was the only person actually taking the opportunity seriously enough to make an effort.
It culminated in my abrupt departure three years in. And for years afterwards they failed to deliver any major new features successfully. Burned through many more millions of dollars, before eventually going bankrupt.
My mistake was not leaving earlier. That experience left such an awful taste in my mouth I've basically never made that level of sacrifice of my own life/time at another company since.
Edit:
To clarify, the hard lesson I learned at this job was that no amount of individual contribution can save a sinking ship. This particular experience was 15 years ago, and I've worked at numerous startups since, some with successful exits. I haven't seen any correlation between the amount of my contribution and the likelihood of a successful exit, absolutely none. Surely this is different for founders, but I haven't gone down that road yet. What I have seen however is some companies are far more dysfunctional than others, and the best thing you can do is learn to identify them quickly and RUN, the opportunity cost is too great.

I intend this as a nudge for you to introspect, not as a criticism. I've shared your perspective before, and have found much more satisfaction in looking at my own behavior to understand what of my experiences were true facts, and what were stories that I told myself.
For me, the reality was that my ego needed the boost from my perceived superiority. I had little else in my life that I Was proud of. Looking back, I understand how my behavior was an expression of a great deal of talent plus insecurity.
I've spent a lot of time working on myself, and my career and life satisfaction are significantly higher because of it.

Yeah, no, I think you're misreading my comment.
I probably should have mentioned somewhere, I'm not that talented. I've worked enough places to know I'm just average. My apparent special ability is in the long hours department. If I commit to doing something, it's getting done, to a fault. I've been this way since my teens, staying up for days without even realizing it while figuring something out.
I'm already too introspective, you have no idea.

I was a database consultant at top-5 tech company. Called in for a 6-week project to help a client land a multi-million-dollar contract. They had tried to speed up their code for 2 years prior to this. But had reached a bottleneck they couldn't overcome.. and without which, they would go to a competitor (wink wink) platform.
Me & another consultant were brought it. Early on, the client decided to put me in lead. I tried some things for 2 weeks, with them watching my screen to 'learn'.. and nothing was progressing. One day, I told them I need to work alone, spent couple nights awake, until I got a light bulb moment to process queries in parallel instead of sequentially. Found sample code on internet, modified it to work on client codebase, prepared a demo, ignored writing a 'status report' (which pissed off the Project Manager), and did a demo to the clientele of 15 managers, directors & SVP - all in the span of 2 days (wed to fri).
Guess what had happened during those 2 days behind my back? The client, PM, and my manager had decided to replace me with a more senior architect starting Monday, and were ready to take me off on Fri at 3 pm. At 1 p.m I did my demo, which literally floored them. I then came to know about the machinations, and then the PM and my manager called me at 4 p.m apologizing, and saying they definitely wanted me on the project. I told them it was a perfect storm of mis-understanding, under-communication and over-reaction, which given the project's short & intense deadline, was just part of the game, and to forget about it and move on.
During my annual review, the Client/PM/Manager called me a 'cowboy' and gave a 'poor performance' rating. I told my manager that I accept the first part as a compliment and reject the second part as incorrect judgement.
I got fired. I left with a smile on my face.

This.
"Manager time" and a set workday are there for reasons. There is no one so brilliant that they don't need to collaborate and in order to collaborate everybody needs to be following the same book of rules.
> I often think about how I could have better allowed his brilliance while not alienating the rest of his team, but in the end I failed.
Expect your brilliant engineer to be in the office during core business hours, and if he can't brook that schedule, fire him.

I've just started a new position in the last couple of months, and my junior status and need to learn a large codebase and set of tooling has me studying almost all day every day.
I'm pretty sure I'm absorbing this massive application and all the external transactions it does pretty fast, all things considered.
If I was constantly interrupting my train of thought and research to 'sync up' or 'collaborate' or whatever other personal fear of missing out that you're strapping your team into massaging, I'd dare say I won't be a solid contributor anywhere near as fast.
Assume everyone thinks the way you do and you throw away the chance for them to excel under even a slightly different structure.

On the one hand, you had a desired result: more of your heroes.
On the other hand, you had the result: failed attempts by compatriots to emulate the hero.
Maybe the problem wasn't that you had a hero, or too many non-heroes.
Maybe the problem was you.
The idea that everyone can perform the same way when given the same opportunity is local to you, the manager. Perhaps what you needed to do was recognise that some members of your team couldn't be the same kind of hero - but maybe there was another quest for them. Maybe the heroes you thought your were enabling by letting them follow the same schedule rules, really actually just needed you to let them be a different kind of hero: the kind that gets things done on a normal, 9-5, business-like schedule.
There is room for this experiment to be repeated.

Knowing what you know now, how would you manage this situation again?

How about letting people try their preferred schedules, and then circling back and showing (some) people that it's in their interest to follow a "9-5" schedule because you actually saw them performing better? And then leave it to them to decide if they want to underperform and face consequences, or do what works well? At my job I get paid how good my boss thinks my work is, not how good he thinkgs it could be if I worked differently.

An advantage of having software devs that can't communicate with one another (for whatever reason) is that it encourages de-coupling of parts of the system/application which ultimately makes the whole thing easier to grow and maintain.

Inverse Conway's Law; organizations are encouraged to create isolated, disconnected teams in order to benefit from modular maintainable code with clear and distinct interfaces.

Sounds like a false equivalence. This person had clearly different strengths and they’re best handling different kinds of work such as prototyping, speculative stuff.

Building software is social thing rather than lone wolf thing. I have come to realize that it is much better to hire people who have good communication skills and not be a problem for other team mate no matter how brilliant they are.
If they are really brilliant and you want to keep them with special treatment, promote them with a very visible title that clearly tells other why they can not get the special treatment which he gets.
But in my opinion if you look deeply these people are more of liability than asset for a general average SWE scenario.

I don't doubt the brilliance of this guy, but sounds like he was (ab)using amphetamines, honestly.

Absolutely. It's pretty much the only way to work 48hrs straight.

I must disagree.
I've done a small number of 48 hour stints in circumstances where the need arose, and I've never in my life touched amphetamines or anything else like them.

Perhaps it's easier for some. What was the need?

Eh, you said it yourself "small number". Sure you can do it one time here or there, likely with heroic doses of coffee for the second 24 hour period.
But consistently doing this as described in the thread isn't "mania" phases of bipolar. It means one is on stimulants.

I worked with one client that had a true genius like that, and their solution seemed to work well -- they took him off the "team". He became like a little R&D department, reporting to top management. This allowed him to work away at his pace and in his fashion. He was available to projects as a consultant, which helped reset expectations as to how he would engage with teams day-to-day. They would assign bright people to work with him sometimes (akin to a research assistant), which helped drive an incentive in others to achieve that kind of excellence in the hope that they can attain the same autonomy.
It seemed to work out well from what I observed.

That is really good to way to handle such people - it is a win-win situation for everyone.
10x gets flexible work hours and, more importantly, interesting and varied projects.
Team doesn't get annoyed by one odd guy, but they are still available to support them, and other teams.
And there is mentoring in there too - this system basically makes them share their knowledge and thought process with potential others like them.
EDIT: There is also a benefit of not having them be a cornerstone of any project(ie - if they leave it fails).

Perhaps, the answer to the question you have at the end is to allow and encourage work from home

Honestly any "rockstar" who can do this I give one piece of advice. Your hard work, your massive productivity will NEVER be rewarded appropriately in relationship to your peers. Show up, work less than everyone else and still outproduce them. Use the rest of the free time you have to other things. "Work from home". Show up to the office and grow a new skill (further compounding the value delta between you and everyone else) or make quality of life improvements to your working environment (that thing we wanna automate but never get to).
Much of work is theater, and the only time you should put on a show, should stretch your legs is when there is an emergency in production (its down and your not making money) every other "emergency" is bluster and poor planing.

Nobody wants to recognize it but this is the real answer. No company (that is not your own) deserves that level of dedication.
People ask “what am I supposed to do, slow down to their pace?” That’s exactly what you’re supposed to do. Put that manic energy into things that will pay off for you later (like passive income), not make your manager’s bonus.

Tell the other employees that they aren't privy to their coworker's personal situation and that you are at liberty to allow any employee to not show up a few days a week, if you believe doing so is essential to their physical or mental health, if it's not hurting the bottom line, and if it's not a quid-pro-quo situation.
If the other employees want more time off, the correct solution is not to ask them to pull all nighters but just ask why. Usually extra time off can be accomodated with occasional work from home or allowing shifted start times. Or, possibly, your employees didn't even want the two days off a week -- maybe they were just feeling left behind and unappreciated that you just loved that coworker so much, and they came to perceive his odd working hours as a status symbol and reward.

I worked in one team where they declared "scrum hours", which were 4-6 hours during the day everyone agreed to be in office. This gave enough flexibility to creative people and enough face to face with people who wanted questions quickly answered. Not sure what the best balance is, but that seemed ok.

I gladly encouraged him to work when he wanted, sometimes that meant he'd work 48 hours straight and sleep for two days and show up Friday.
It's extremely common for brilliant people to be twice exceptional. Problems like ADHD, ASD, OCD, etc. are fairly strongly associated with very high IQs.
This means if they pull an all-nighter, it's not because they pushed themselves to be productive. It's because their brain was on fire with an idea and they needed to get it all out right now and literally were incapable of sleeping until they could get it done.
That can't be replicated from the other direction. You can't say "I know! I will stay up and work all night and it will be brilliant!" That's not how that works. Not by a long shot.

I work in an FAANG where the director in charge takes people like this and just forces them to work from home. WFH is normally not allowed so you have to be in the exceptional tier to be offered it, and that gives you the flexibility to manage your own schedule. It limits the ability of those people to influence the culture.

"One other lesson needs to be drawn explicitly. A project is not a house of cards which collapses when a single "key" person is removed. At least, it should not be; but often, when management thinks it is, the prophecy becomes self-fulfilling. That was one of the lessons in Mark's case, for if a little less reliance had been placed upon Mark, his manager might have populated his team with other than trainees. After all, even if the "key" man is as contented as a cow with his work, people are sometimes inconsiderate enough of their managers to get sick, to get drafted, or to die. No, if a manager wants to run a stable project, he would do well to follow this simple maxim: If a programmer is indispensable, get rid of him as quickly as possible."
"The Psychology of Computer Programming", Gerald M. Weinberg

Could you have worked out a consultant "pay by the hour" arrangement. As long as he pulled his hours for the week it would still seem like a great investment.

I've been such an engineer: hard to manage, but, I'd dare to say, brilliant. First 5 years of my career were painful: I didn't understand why people were often upset about me, why they wrote poor peer feedback and why I wasn't given the formal role to drive projects. Then I bothered to learn some people skills and corporate politics. These days I don't bother to work more than 2-3 hours a day: most of the time I hang around, talk to people and make connections. Those 2-3 hours are more than enough to deliver piles of work and get outstanding perf reviews. Because I talk a lot to others, everybody generally likes me and I get good feedback. The unused energy and competence goes into side projects. I even started a side company. Now when my manager talks about the importance of showing more leadership, I calmly admit how right he is, and at the end of the day head to a dinner with 2 VPs and one CEO to discuss things related to my company.

Beautiful... a living example of a mini thread I had with another commenter above!

So what would you and others in this thread do if, through some stroke of luck, you had hired the next John Carmack?
Are you saying that would be a guaranteed liability?
If so, how good is too good? You need to be sure to let your engineers know to stop progressing before they get there.

The ability to work during normal business hours, dealing with interruptions and collaborating with your colleagues, is a skill that every engineer should develop.
This skill doesn't come naturally to some people, but it can be developed and it will make you more productive.
In particular, develop the ability to enforce encapsulation on your mental model of the program you are working on, so you don't need to keep the entire thing in your head all the time (this will probably make your code better too). This makes it easier to get back into the flow after being interrupted.
The most productive engineers I know work during normal business hours, get interrupted constantly because they work on important projects with a lot of stakeholders, and get a lot of work done anyway. That's what 99% of engineers should aspire to. There are very few rockstars like Carmack who are so good that the benefits of their crazy work styles outweigh the drawbacks.

> That's what 99% of engineers should aspire to.
I wholeheartedly disagree. You're trying to force a generation of imagination into a box. That will only destroy the very imagination you need.

So, I have a different and more sinister version. My sinister version is yes, yes, please, keep those imaginations in the box so that I may continue to have a monopoly.... whwhahahaahhaa
----
I'm a principal engineer with a fully capable imagination, and I once got the feedback that my creativity was "transcendental"; the reality is that I don't confine myself to schedule, and my only real discipline is using English to describe my thoughts and improve as a writer.
I try very hard to get people to think out of the box, but it is really hard because 99% of the work does not require "divine inspiration". Most people gravitate towards this advice because it is most applicable, and it becomes a virtuous cycle for them.
However, it creates a vicious cycle of the Pareto distribution where 1% of engineers can actually use their max level of creativity and use the full breadth of computer science.

OMG, resistance to change is so crazy. I've fought for years to get teams to adopt a relatively simple pattern (complete with transition plans to minimize pain). After the change finally happens, everyone talks about how amazing and brilliant it is, and if I ever have big ideas like this "please share them."
So, I bring up data quality, and how we need a centralized test architecture! Same. Blank. Stares... and I'm another year in on shifting the needle, while random reports spontaneously stop breaking and we wait for customers to report data outages.
Blows my mind.

Oh, and there can be good reasons like inertia. However, it is very human to resist to change since incentives are aligned with status quo. It is a frustrating field to say the least, but at least some companies fail providing opportunities to try again.

What software engineers need to learn is that their skills aren't magic, and they don't need to be coddled to be entirely productive.
So many engineers have learned this, that if you can't, you aren't competitive in the field unless you're literally in the top 0.001%, and no, you aren't.

It's a balance.
Part of management's responsibility is to keep interruptions under control. If management does nothing so that everyone goes directly to the engineers; management isn't managing.
Specifically, this includes making sure that everyone is onboarded so newcomers don't need to go to the more experienced engineers to ask trivial questions. It also includes making sure that processes are defined and agreed on by stakeholders, making sure that people don't bypass the ticketing system, and sometimes reminding certain employees about things like manners.

Yes, and also most people spend most of their time working on things like CRUD web apps rather than pioneering rendering techniques. Not only does the former not need the intense focus of the latter, but it also does require actually talking to stakeholders.
Also, most people have not been described as having "no empathy for other human beings" in a psychiatric evaluation.

Science says you're wrong and not only wrong but this mistaken belief some of these people hold that they can multitask or be interrupted without significant loss of productivity is actually an admission that they are the worst of multitaskers. [1]
The mind is single-core. There's no black lotus you can huff or secret technique to master to make it more than one core. And the inertia returning to its task is significant.
[1] https://www.npr.org/sections/health-shots/2013/01/24/1701601...

Sure, but most engineers are working for a business and most businesses don't have perfect processes.
I think we can say (1) engineering productivity is severely impeded by interruptions and (2) it doesn't hurt to work on skills to help yourself get less impacted by disruptions.
You're right there's no secret technique, but documenting your work and thoughts, keeping TODO lists, breaking down large work items into small chunks can all help distractions not ruin your day.
But, these are effectively "hacks" and the only way to ensure highest possible productivity is to have processes which prevent engineers from being interrupted

It all depends on what you are optimizing for.
You can do a lot of work in parallel if you have the correct coroutine architecture. That involves encapsulating information in a way that you can put it down and pick it back up efficiently.
An upside of developing this skill is that if you become adept at storing the relevant information, you will be better at handing that information off to another person.
Further, absolute productivity at a single task is rarely the most important thing. If it is, then you've reduced yourself to a cog or a worker bee.
Taking responsibility for the direction of your work means accepting that you need to be part of the decision-making process, which will lower your absolute productivity, but (done well) will increase your overall effectiveness.

but if they don't get interrupted, what's the cost of it vs the cost of them actually being interrupted? Did someone else spend a day trying to solve a problem they could have solved in minutes by interrupting the lone genius?

This. If you have one person holding everything in their had blocking other engineers who can’t get around then you are just wasting resources.

I think you've missed their point. Those engineers are aware of the cost of context switching, and because they plan accordingly they're able to get more done than those who don't

Awareness and planning cannot compensate for the fact that lost productivity is lost productivity.

I tend to agree with you, but I'm compelled by the argument that organizing your productive time in a way that minimizes the impact of context switches will make your programs much better anyways.
There might be a good reason why code developed under extreme focus also tends to be inscrutable to others.

> There might be a good reason why code developed under extreme focus also tends to be inscrutable to others.
Wow. I have never thought about it this way. That's quite a profound insight. Thanks.

On the other hand, extreme focus can and should be used to make a complex algorithm simple. It all depends on the programmer's competency to begin with. If he/she doesn't care or know how to make code readable, it never will be readable despite their level of concentration.
The corollary is true as well. I, as well as many others I imagine, have had to fix and maintain dumpster fires of spaghetti code developed under the standard distraction-filled modern business day.
Distraction doesn't beget good code; instead, a good programmer learns how to be as productive as they can despite the dysfunction of a typical modern business.

I'm writing this under the influence of Deming, but could you be confusing individual productivity with productivity for the whole department, company, country, world?
Any engineer is only as productive as the system she works in, and a system that eschews communication for long periods of solitary work is not, generally, a productive system.
I vaguely remember reading about an old study from one of those telephone companies in the '60s or so about engineering productivity, and they found that the single thing that set the "best" engineers apart from their peers was in how much more they communicated. I haven't been able to find this study, but if someone knows what I'm talking about, please shoot me a link or something.

Was it Hamming's talk?
https://www.cs.virginia.edu/~robins/YouAndYourResearch.html

Might have been! Haven't taken the time to read it yet but it looks very interesting. Thank you irregardless!

Just to attempt to explain why the responses to this comment seem all over the place:
'Productivity' is subjective to the business and position. In your 2-person startup, productivity might be shipping CRUD functionality in triplicate and setting up the bones for a larger application. In an enterprise, productivity can simply be not _reducing_ productivity while doing something. A develop and a manager being productive also look very different. I don't think your point and GP's point are mutually exclusive.

> get interrupted constantly because they work on important projects with a lot of stakeholders
Are they really OK with this? Constant interruptions is the hallmark of a broken process and usually means the company is a bad employer and the projects are in trouble. I'd guess those "most productive engineers" handle that situation usually by finding new employment.

I agree, some of the best engineers I have worked with do this. On the other hand, I disagree that all engineers are capable of working best like this -- I don't think everyone has the same aptitude for the same things as everyone else.

I somewhat disagree.
More specifically, as an engineer your ability to collaborate is a big factor in your effectiveness. Even as an IC, you are being paid in part because your experience and skills help the whole team, not just your code.
However, it's impossible to get good work done if you don't have contiguous blocks of time to focus. Even if you take great notes and write things down, momentum is definitely a thing. I've adopted the practice of blocking out 2-3 hours at a time on my calendar the morning of, so that they are not available for meetings, which guarantees me quality time to think and work. If people ask, I'm busy. If people ask why I'm at my desk when I'm supposedly busy, it's because I have to block time for quality thinking or no high quality thinking gets done.

> In particular, develop the ability to enforce encapsulation on your mental model of the program you are working on, so you don't need to keep the entire thing in your head all the time
This one is hard, because the company will push you to make the model as complex as your brain can bear, and all of our programming tools are designed to support the most complex program the toolmaker could imagine. And on your resume you want to put the most complex set of capabilities that you could possibly put. And in your mind you want to be the most dangerous programmer you could possibly be.
It took me 20 years to realize that there are ~0 problems that necessitate more than an intro-to-programming level of tooling.
It took that long because the whole ecosystem around me pushed me away from transparent coding towards grandiose coding.
Even now, I can rarely write simple code for hire because my coworkers have installed a veritable AGI of declarative tooling, and not using it is more conspicuous than using it.
But I try. You are absolutely right plain (not fancy) code is the ultimate goal.

This. This so fucking hard. The whole point of writing clean code is so I can spin back up on it in 15 minutes instead of the 30 mentioned in the article (or often very much longer).
Literally everything I do at my job is in service of this fact, and no one else where I work understands that. :/

This comment could be greatly improved by some tips on how to do these things. As it stands, this comment sounds like an imperative to merely subject oneself to something and endure the discomfort of it, without any indication that the reader will build any skill.
Since changing workflow to something dramatically less-productive is also something that can disrupt a person's healthcare and housing, people are understandably going to be skeptical.

Naa, this is totally backwards. Organizations should strive to decrease the number of interruptions and be flexible enough to allow people to work in environments that let them thrive. There is no good reason to say people should get used to poor working environments. All of the research shows that interruption doesn’t last for the two minutes someone needed to get a ticket judged as a 3 for the board, it lasts much longer and effectively resets your focus.
A good practice for engineers is setting periods of time for non-critical interruptions, like an engineering office hours. Set periods of time on your calendar as “meetings” and disappear into a room to work for an hour, shut off your messengers.
The world usually won’t blow up in the hour that you’re gone, but you will be a much happier and more productive engineer. We’re usually pretty effective when we time box things, so these methods have helped me drastically improve my focus.

I feel like we're only having this discussion at this point because:
- Agile brought interruptions to a new level of pain
- We have too many instant interruption communication points (slack)
- Open Offices have made interrution far worse
There were books about this concept 30 years ago. It was totally recognized that you shouldn't break up an engineer's time into tiny chunks with 1000 cuts worth of meetings.
But we threw it all out the window in the last 10-15 years with the rise of Agile + Open Office + Instant Message/Always-On communication programs.

Out of all of these things, open offices have been the worst in my opinion. At least with slack (or whatever other messenger you use) you can ignore that until your thought is complete or you want to make a quick note of your thoughts before allowing the distraction. When someone taps your shoulder it's much harder to ask them to wait, so it happens much less than it should... not to mention the constant passive distraction of people moving around and having other conversations.
We used to be in small offices of 2-4 people. That was perfect and I miss those days. The office looks a lot nicer now that it's open, but it's a disaster from a concentration standpoint. But, I think a lot of managers like the open concept because it's easier to see people and because it does often look nicer and often has more natural light.

I have never worked in a 2-4 office and certainly not a 1-office, but I find about 10 in an office is manageable if they are all quiet non-phone-calling people.
I worked a place with 400 people in open plan close proximity, where your workspace doubles up as a corridor, and no meeting spaces, so it also doubles up as a meeting room for any teams meetings. It was impossible to concentrate. That drove me to some Howard Leight earplugs, beefy headphones with "the ocean machine set to 9". The impomptu meetings now sounded like a squeek, but it was still distracting.
I had to leave that job because of this and other negative effects of a cattle-like approach to handling software talent.

I completely agree that open offices designs are completely terrible and make work very stressful. I don't see agile and slack as equivalents though as how they get implemented completely dictates how this plays out. My current work is agile and we use slack and I have 0 problems with being interrupted. We also don't have the issue with open offices as well, given that we are 100% remote.
Personally I think the fully remote fixes half the problems in this area as it makes meetings harder and emphasizes communications like slack as being real channels (with processes and conventions), vs. a side channel that people feel easier to bug you personally on.

> We have too many instant interruption communication points (slack)
Depending on the company culture, you can choose to just not respond for a couple hours. "Sorry, I was working through a complicated chunk of code and I needed uninterrupted focus." "Yeah I saw your message, but I was in the middle of something, and I needed to focus."
I do that on purpose. If it's not urgent, even if they say it is, it can wait. Eventually people start to get it and stop expecting real-time responses.

Just as a follow on...
At one point I had to read a management book about this problem, it was probably published in the 1990s, it was Pre-Agile Manifesto for sure.
It had recommendations like: - Meetings should be first thing in the morning or right before lunch, or at the end of the day
- Engineers should only log into email once or twice a day
- Stuff like close doors when intensely concentrating to indicate your busy/concentrating
Email, Slack, etc.. we can exit out of. But there is an expectation IME these days that we respond to things quicker than in the past.
With respect to Agile.. if you're in a small enough org where there's only one standup you can have it in the morning and stick to these guidelines. But in a bigger org there are a bunch of different standups. The Managers want to go to a bunch of them, so the standups end up moved all over the day to meet the managers schedule, causing all the maker schedules to get messed up with meetings at all times of the day.
Stuff like close the door to your office sounds like another universe. I started working in 1996 (internship) and I have only held 1 position where we all had offices. That was in a facility/group that was originally a research division. That office did get razed at some point after I left in the early 2000s to get turned into cubes/open office.

The fact that he had to work at night in order to get any concentration time would be a company culture fail in most situations. But, the devil's in the details.
> David Kushner reflected on the unconventional working style of the company's ace coder, John Carmack.
"Ace coder" isn't quite accurate job title. He was a co-founder. People act differently when they have legal ownership over their work.

When you talk to effective people, you quickly learn they get most of their work-work done before 10am or after 5pm.

I wonder, sincerely, if this is to do with the sun / the idea that other people are awake and there is opportunity for disruption...

Sometimes you get the most brilliant of ideas in the shower after your work day, and you just can't wait till you get back to work next day (also because you know you'll have a ton of meetings anyways).

I work very late into nights on the project I created. I hate myself sometimes for doing this because this now the company's cash cow and I get nothing more than any other engineer. I've contemplated quitting but I see no benefit to this, it's still one of the coolest projects I've worked on. It's not just legal ownership that can drive people.

Why not just put your resume out there and see what happens?

As a maker (individual contributor), I have been having this issue a lot, but my attempts at pushing back do not seem to be going so well. Any time I reserve a large chunk of time on my calendar, people set up meetings on top of it anyway, or message me asking if that block time is "real" (as though quiet focused work isn’t a thing).
My days are filled with little dabs of 30 minutes here and there that are barely enough to remember what I had been working on before another meeting started, so I normally end up getting my actual work done late at night after an early dinner, which my wife is not particularly happy about.
Any recommendations? I’ve broached the topic lightly with my manager but don’t want to come across as whining, so I’ve generally just been trying to push back on meetings in the friendliest way that I can.

Maybe link them this article and phrase it as an experiment. If velocity increases then your manager will know it is worthwhile.

If you can find another individual (or two) who's dealing with the same problem, you can schedule a block of time with them (a meeting) and work side-by-side. May even collaborate.
Name it something important: critical feature optimization, application security audit, system integration... do not call it focusing on your work.

Do you have anybody in a project manager kind of position (who is responsible for delivering things as fast as possible). I'd talk to them and tell them that you can't get anything done if you constantly have meetings, and ask if they could be scheduled together. I feel like this might work better if it was a company or team policy rather than just you trying to do enforce this by yourself.

>people set up meetings on top of it anyway, or message me asking if that block time is "real"
Your problem here is you. You were booked. When someone sends you a double booking, hit "DECLINE" and they get an email right away saying you declined it.
Then you say "Hey I already had something in my schedule for that time, can't make it. You have access to my calendar why would you make meetings when I'm busy? That isn't very respectful."
If someone asks if a block of time is "real" always say yes. your problem is that apparently you have blocks of time that aren't real. if you only have real blocks of time in your schedule, nobody will guess which aren't or are real.
If someone asks you in person, have the backbone and willpower to say "Hey I'm already booked" and suggest another time.
You're the one causing your problems, but you're describing it as other people doing it to you.

This can be difficult to do in certain contexts. This approach could easily cause them to be perceived as arrogant, "not a team player", or some other cliche. If their calendar is open to others (so it shows event details more than just free/busy), it's hard to portray those blocks of time as equivalent to "real" meetings.
Involving your manager is potentially a great step—though you have the best gauge as to whether it's the right move. If you've discussed your approach with them, they can provide some much-needed cover if colleagues complain that you're not available enough.

Again, this is why you
1) Start from the 'respect' angle.
2) Suggest an alternate time so that it can work.
3) Leave a paper trail.
I would only involve a manager if it became a serial issue and you've made your concerns clear and in writing.
Whether you come off as disinterested, not a team player, or just busy and the other person isn't willing to respect your schedule is up to you.
But it all depends on you.

The problem is that when you do this, and then don't go to the meeting, and then a decision is made that you don't agree with, you are told, "well you had a chance but you didn't come to the meeting".
The other problem is that sometimes people will literally see you working in your cube/office during the meeting and then ask you why you declined if you clearly weren't busy, because they don't equate coding with being busy. Sitting at your desk == not busy in their mind.
So now you have a political problem because you're seen as uninterested/not a team player.

>>Sitting at your desk == not busy in their mind
Maddeningly, these are the same people who feel like you have to be in the office 100% of the time so they feel like you are working.

Thats why you suggest an alternate time, so that the onus is on them. Alternately if you know someone competent and willing to attend to make sure it goes right, ask them if they'll go.
Whether you come off as disinterested or busy is up to you.

>The problem is that when you do this, and then don't go to the meeting, and then a decision is made that you don't agree with, you are told, "well you had a chance but you didn't come to the meeting".
I would have if the item, I cared about was on the agenda.
This is why agenda are a) important b) should be sent out 24 hours or more before the meeting c) should be rigdly followed.
Anything else is either poor communication or a waste of productivity.
This gives everyone time to review the agendas. Making a decision which is worth attending,which is worth escalating.
Beside the manager should be representing you anyway.
>if you clearly weren't busy, because they don't equate coding with being busy. Sitting at your desk == not busy in their mind.
Coding yes. A skype meeting would be busy in their mind.

> so I normally end up getting my actual work done late at night after an early dinner, which my wife is not particularly happy about.
Until that stops, they won't knock it off. Start telling them exactly what you're doing in those time blocks and how much the meeting will make that slip by. Do not work after hours. If they want to pay you to sit in meeting rooms rather than ship features, that's their choice, but you have to make them choose, or they'll take both.
[EDIT] mind, make them choose by communicating. Email (or whatever your management-tier uses to communicate) is your friend. Explicitly call out your expected meeting burden in estimation sessions and politely but firmly alert (send an email/message) when that burden is exceeded. Bring it up in retros. This is especially effective if you have someone up the chain who wants features shipped and who is not the one calling these meetings. Part of their job is to make other people knock off unproductive shit. Give them the info they need to do their job (that you're being scheduled for too many low-value meetings).
Your only other alternative is to start delegating, until you're accidentally a "lead" and like 50% of your time is supposed to be meetings, another 25% delegating, with the balance helping other devs getting unstuck.

I wonder if you could start the blocks small and then grow them over time. If you have half an our reserved somewhere, maybe people won't schedule a meeting against it. Then make it an hour, after a month and hour and a half, etc.
Or just block out the four hours you need by filling it up with loads of fake important-sounding half-hour meetings.

My mom was an administrator at the local hospital, and always seemed to have too much on her plate.
The thing my dad would always criticize her about is that she always picked up the slack.
If you are putting in a valid effort, you have to let things slip. Otherwise the people above you won't know that you are being assigned too much.
The first thing you need to do is stop working at night. You are paid to work during the day. Anything beyond that is you taking on unpaid work.

There can be only one primary task.
When this happens, the question is, "what is worth what?"
You must pose it to them, or others will ask for and expect both. And where they lack knowledge, this must be escalated to someone who can make the call and account for said call; otherwise, you are already accountable for commitments made prior to their request.
Doing both is not realistic, because there can only be one primary task, and this is why you end up doing work off hours.
I would share more calendar details, put what the task is on the time block, and in general set up that question.
Others will attempt to schedule your time so they do not end up doing catch up work off hours too.
It is you or them, or something just is not as important as everyone thinks it is.
Which is it?
Also, make task switch time clear.
A 30 minute meeting in the middle of, say a 2 to 3 hour block of time, may actually cost all or reduce the effective time to a small fraction of what is allocated. One effective way to handle this is to ask how many more meetings can now be scheduled into this wasted block of time?
It can also mean moving that block slightly, allowing meetings at the very end of it, or before it starts. Either can be cheaper, with meetings at the end of it being cheapest generally.
Your whole pushback is centered on there can be only one primary task.
That is as real as it gets. Use it.

I wholeheartedly agree with the techniques others are recommending for improving the situation, but at the same time I think you should look for ways to cope with what you have as you make the transition.
I would best be considered a mid-level manager with 3-5 additional projects to tackle at any given time, and I face this problem on many different scales. Best case, I'm trying to get longer tasks done, and the longest uninterrupted intervals I can get are about 20 minutes. Other days, I need to complete 3 minute tasks and the longest uninterrupted time I can get is about 40 seconds. In either case, I outline the things I need to get done so that I can track where I am and quickly be reminded after an interruption. If the list ridiculously overflows the time in my day, I go further by writing down the priority order to make sure I don't lose track of that important detail. From there, I tend to get into sticky notes: when I'm interrupted, I write myself a note sufficiently detailed to quickly resume after the expected duration of the interruption. When people come to me with non-immediate concerns, those go on sticky notes to address when I'm not in the middle of things (or it can just stay in email if you're excellent at controlling and addressing your inbox). All sticky notes get addressed or stored before I leave. The handwritten aspect is important because sticky notes take up space, and each additional transfer of them takes time vs CTRL+V.
It's far less enjoyable than having a block of time to focus with minimized task-switching overhead, but maybe it can help you return some of your work to your actual workday while you improve the situation around you.

Without knowing much about your situation, this could indicate either poor culture in your company, or poor management. In other words, is this really a sign that you should get another job (or another assignment under someone else)?
That being said, assuming you like your job / manager:
> I’ve broached the topic lightly with my manager but don’t want to come across as whining, so I’ve generally just been trying to push back on meetings in the friendliest way that I can.
Don't broach the topic lightly. Be very direct. "I have too many meetings, and I need to reduce them. As a result, I'm doing too much work at home. This is a problem for my family."
See where that goes. Before you discuss this, though, there are some things to consider:
Some people hold meetings as a form of procrastination, or as a way to feel important. It's important to figure out which of your meetings are these kinds, and decline them.
It's also worth looking at how to hold an effective meeting. When I worked at Intel in 2005, "effective meetings" was part of onboarding for all new employees. It gave us a lot of tools to pushback on bogus meetings, including a clear culture of declining bogus meetings.
It's important that you set some clear boundaries / limits, and not give in at all. (Even if this means finding a new job or assignment with a different manager.) What that something is, really depends on your relationships with your manager and peers. It could be that you decline meetings, (as other people suggest,) or it could be that you demand better planned meetings in order to attend. What's important is that you set some clear boundaries, and leave if they aren't respected.
Finally, if you don't get much support from your manager, and you still like your job, I suggest bringing the problem up the chain of command.

I am in this situation pretty frequently. Are you just a solid communicator? I know I tend to get roped into meetings because I'm good at leading meetings, while other engineers are frankly terrible at it.

"Damn, it, I have PEOPLE SKILLS!"
But seriously, it seems to me sometimes, that having a "meeting guru" would be truly helpful sometimes... a SPOC that can filter all meeting requests by the email / 5 minutes / required vs inflated attendees / agenda / etc criteria before they even happen.
Most of those questions aren't detail specific, so someone well versed in asking them politely and choosing the appropriate action could save so much time and attention suck.

>a SPOC that can filter all meeting requests by the email / 5 minutes / required vs inflated attendees / agenda / etc criteria before they even happen.
That's the project manager's job. The more meetings they allow. The more the project suffers. The more that are missed. The less poltical power. So they need to focus on fewer quality meetings for the ICs. More meetings for the PM.

Last year I resorted to blocking off 11-230 every single day of the week. Sometimes people grumble about the lack of openness on my calendar but end up scheduling around it anyways.
So now I get that whole time to myself and take a lunch break either at the beginning or ending of that block.

As a high level IC, I run into this a lot and still struggle. Largely it boils down to setting expectations, sticking with them, and having support. I have to push back on meetings, along with manager support for 'no meeting days', task offload, WFH, etc. Some weeks are better than others.
The solution (if any) will depend on your company, and position within it. First is manager support. Without it, you're stuck. During 1:1s, sprint retros, its entirely valid to say something to the effect of "I couldn't get X done, because I had to spend most of my time in meetings. I need X chunk of focused time to get it done." A manager should have your back and be able to push back on others to keep your time free for non-meeting work. The answer should not be to work more hours.
Some of these tactics won't work unless other people who need your time are aligned with this. That includes things like maker hours -- if one team has them, and another doesn't, its bound to not work well.
The main questions around any meeting I ask are:
(1) Is the meeting necessary? Is there a clear agenda? Can this be answered in email or a 5 minute chat? Often people schedule a meeting, and leave the thinking for later.
(2) Do I need to be there? Without me physically present (or giving out of band input via email), will the meeting fail or have a bad end result (like a bad decision), politics, etc.
(3) How urgent is this? Frequently, meetings are scheduled for the requestors' convenience. Not the attendees. Sure if its a high level meeting where its hard to get everyone in the same room, you might be stuck. Most of the time, that's not the case and gentle pushback to reschedule is fine (give options!).
Locate other distraction sources and figure out how to manage them:
(1) Sources of toil -- Do you frequently spend time on tasks that could be automated or otherwise made to go away?
(2) Are people always coming to me vs my manager or team? Ideally you should not be the single source for all things. You want to train people to bug your manager or team (mailing list or group chat) and not you. In other words, if you're busy, do you really need to be L1 support all the time? This also promotes cross training.
(3) Other co-workers -- Sometimes headphones just don't signal "go away" enough. Especially in open offices where everyone may be wearing them. Can you WFH one day a week and 'hide'?
(4) The internet :)

Just reply that you can't make the meeting, you don't have to give them a specific reason.

> I normally end up getting my actual work done late at night after an early dinner, which my wife is not particularly happy about.
Whatever else you do, don't do this.
Work is simply not that important.
If you constantly perform miracles, no one is inclined to fix the problems.

>Any recommendations?
Yes. That 'maker' time is a 'virtual' meeting.
If you can schedule it with a name. E.g. TPS report meeting with Bob it is much more respected. Your in a meeting, so you must be very busy.
Harder in an open plan or Easy to see office
Works best with a couple of friendly coder from another site in the company.
Set up a notebook to skype with each other then mute it. Pop headset on.
You must be busy with all those people in that zoom meeting.
They will respect meetings with other coders in a way they won't respect make time.
Make sure it's regular on the calendar. Remember to mark how your most productive work comes out of the "pair programming meeting"

Sometimes the problem can be one of self-definition, or of self-definition over time. Professionally, I have had years where I was definitely in maker mode and years where I was in manager mode. There are times when for a few months your head is down and you're just making stuff. Then the making slows down and what you've made goes into maintenance or into a next planning phase where lots of things have to happen at the same time.
The problem can be that some developers see themselves as forever in maker mode: in other words they treat being asked to talk and discuss things as mere interruptions.
A lot of managers I think are quite traumatized by this in a way: they can feel like they literally have no power to make things happen. As a result they may well over-react over the course of a career and treat anyone in maker mode as simply another developer who won't talk to them.

Phew, thought I was the only one who went through these cycles. The maker > maintenance > manager/planning cycle always feels unsettling during the maintenance phase.

https://hn.algolia.com/?q=manager+schedule
http://paulgraham.com/makersschedule.html
And 7 days ago : https://news.ycombinator.com/item?id=21440456 ( The Manager’s Schedule Is Holding Back Remote Work )

The endless focus on "rockstar" productivity seems misplaced to me. This is a profession. You're going to be doing it for a long time. No need to burn the candle at both ends.

A few things that I've found helpful:
1. I start my day a couple hours later than typical for my organization. This both lets me work quieter hours and shaves time off my commute.
2. From 2 p.m. on is reserved as "Real, Actual Work" on my calendar.
3. I check email a few times a day. Any other time, Outlook is closed. Those who need me immediately can call my phone or visit my desk.
4. At least once a week, usually Friday, I work either as late as I can or until I reach a suitable milestone. The clock doesn't matter.

> At the same time, real work is not getting done. Meaningful work is usually done quietly and in solitude.
You can do great work by pairing or mobbing too. Being isolated is good, but it's harder to learn new things working by yourself.

"it's harder to learn new things working by yourself."
I strongly disagree. I rarely learn anything of consequence when working with others. Pairing and mobbing strike me as fads.

Some people thrive in that kind of environment (XP and all that), I know it sucked the soul out of me the one time it was forced on my team at a prior employer.

I generally do not work well if there's someone staring at me as I work. I also have my own, high-productivity, quirky ways of using computers that mostly only work for me in solitude.

Interesting, I guess it depends on the person and on the thing you're learning like someone else mentioned. I do think you need some time by yourself to really go deep at your own speed to learn something.
Pairing and mobbing are not fads, they've been around for a while and in my experience they've been very useful, I'd recommend you try it with someone with experience with it.

> harder to learn new things working by yourself
Depends on the things. Another person might be able to share a few tricks with you: you may not know that you can drag the lower corner of an excel spreadsheet cell to copy formulas, for example, or that you can use "cw" to change a word in vi. On the other hand, learning something like relational database modeling or functional programming requires dedicated focus that another person is probably going to get in the way of.

>Being isolated is good, but it's harder to learn new things working by yourself.
Code reviews I feel provide a good avenue for learning how others have done things.
I've hit blocks in the past while working by myself however I feel part of learning is hitting a block over and over. Only once you truly grasp why other solutions don't work does a new novel solution really fit in completely. Moreover unless you truly try to solve it yourself you don't develop the skills to solve problems.

It's often less the "manager schedule" that is the problem, but getting screwed into complying totally with the "customer schedule."
The one that has been the bane of my existence for years now is the 9AM daily call with the customer that is on Europe or Delhi time. It just destroys the day when you start things off with that kind of thing, and get immediately tossed into placating and containment mode. Then whatever you thought you might be able to do for the day gets tossed out the window in order to react to the latest fire drill before the next call. It's entirely reactive, rather than proactive, and it is soul crushing.
It's almost lunch time now, and I haven't done anything worthwhile yet today, other than try to bring some kind of order to this chaos and triage.

Unfortunately, your role is "customer support engineer". Ideally there is another team that does not directly interact with the client that is actually able to get real work done on the product. Try to get on that team.

You have to wear all the hats on a small team, unfortunately.
Between Thanksgiving and New Years is typically one of the better periods of the year for getting real work done, so there is that to look forward to.

I find that the simplest way to avoid getting stuck on someone else's schedule is to get a ~month ahead of your expected productivity (even if that means sandbagging estimates, or working extra, or accepting a bad performance rating because you are holding back on reporting your accomplishments), and then whenever you are asked for status update for management/customer, report what you were working on last week/month, not what you are working on right now. This means you are never playing "catch up" externally to yourself. It's like having a month of living expenses saved in your bank account it's a month of political capital saved up at your job.

Carmack was able to choose his timings because it was HIS company. People worked for him, not vice versa. To be the master of your time, you have to work for yourself, not under someone else. When reality and idealism clashes, reality wins.

Couldn’t say it better. This is something most people who work for others don’t understand.

> The reason why many managers fail to see and address this problem is that they are used to looking at communication and assume it's a good thing. Because they see activity. People are attending meetings, talking to each other, the online presence indicators are bright green. Clearly, a lot of work is happening!
Yes, this. And a similar problem occurs when manager-types try to come up with metrics to measure programmer productivity. Their yardsticks for what constitutes meaningful work, as a manager, cannot simply be translated over to makers.

>manager-types try to come up with metrics to measure programmer productivity.
Plenty can. The CFO types look at profit per commit/schedule whatever.
A lot of middle managment types look at activity per commit.
The real issue here is that mangement by productivity data. Means most management is deadweight that can be replaced by a spreedsheet with the ability to send form emails to those falling behind on the metrics.
Anywhere else would be downsized, but management has enough power go protect it's own existence at the expense of the company.

The core message is true: Constant interruptions are bad, dedicated periods of focus are good, managers should help foster sustained focus for their employees. I think we can all agree on that.
However, this isn't an unbiased article: This company wants to sell you a SaaS product that they think will reduce interruptions. They have an incentive to make you think that the manager's schedule is as terrible as possible, because they want you to sign up for their SaaS tool. In my experience, each additional SaaS tool piled on to developers, no matter how well-intentioned, just introduces more distractions and overhead. Reading toward the end suggests some possibly helpful tools, but I'm not seeing anything that can't be accomplished with some common sense and existing tools.
This blog post has unhealthy amounts of exaggeration and hyperbole. Consider the "Actual Schedule" chart in this article that only shows blocks of "Ruined Morning" and "Ruined Afternoon". Or the claim that a single standup meeting can blow an entire afternoon because it interrupts the afternoon flow. The study they linked doesn't even support such excessive problems with disruption.
These exaggerated narratives are seductive for two reasons: First, it's true that interruptions come at a cost to focus on other tasks. Second, it gives us an easy out to blame everyone else for our lack of productivity or focus. Did I waste my afternoon on Twitter and HN instead of getting my work done? Well, I read an article that says it's my manager's fault for that 30 minute scheduled meeting that I've known about for a week. It's always tempting to blame someone else, especially when there's a shred of truth to it. I'll admit that I fell into this trap for a while when I was younger.
Having grown up on "Maker's schedule vs. manager's schedule" I was a die-hard believer that managers had it easy, while engineers got the short end of the stick due to all of those pesky distractions. When I switched to management, I was shocked to discover that I still needed periods of sustained focus and that I still had problems dealing with interruptions. The maker vs. manager distinction I had learned about didn't really exist, but in the manager role I had no choice but to work around it. Once I stopped blaming everyone else for my poor ability to recover focus or get into flow states, I became much better at managing my own time.
I firmly believe that articles like this are counter-productive, because they send a message that poor time management and excessive time wasting are not your fault, and therefore not your responsibility. That mindset closes the door for any possibility of improvement, which is the opposite of what you want. Yes, it would be great in an ideal world if we could work for a week straight without interruptions, but that's not reality. Instead, focus on skills to better manage your own time and plan around interruptions.
Practice responding to people with "I'm in the middle of something right now, can we talk about this after our scheduled meeting in the afternoon?" to coalesce your meetings together. Or statements like "I'm happy to help, but I'm really busy right now. Can you write this up in an e-mail, cc my manager, and we'll look at it in the morning?" If your manager is to blame, broach the subject in a professional manner and politely ask if your manager can help batch your interruptions into a single daily conversation. Put it on the calendar if you must, but the important thing is to take charge of your time management.
Finally, put deliberate effort into getting back into a flow state after interruptions. If your first reaction after returning to your desk is to open up HN or Twitter, then you're part of the problem. I've found that putting my headphones on and spending 10-20 seconds mentally retracing my steps before the interruption is very helpful.

> This blog post has unhealthy amounts of exaggeration and hyperbole. Consider the "Actual Schedule" chart in this article that only shows blocks of "Ruined Morning" and "Ruined Afternoon".
I found it to be a very clear illustration. I don’t think “ruined” should be read as “completely wasted”. A lower sense of focus or flow is a realistic outcome of a schedule like that, in my experience.

Context switching is expensive. I agree with the strategies you shared for better managing time, but you seem to be interpreting the article as literally manager vs maker, as if there’s a strong adversary between the two, when in reality, an engineer who’s expected to attend all the meetings and also be able to turn around designs and code is just not going to be as effective because of the high cost of context switching. The authors point stands.
Somehow you managed to see the worst in this, making the article about yourself, and you even accused the author of purposely misleading to sell his or her product. If you’re a manager, I would encourage you to be more open minded, for the sake of your employees if nothing else.

I think the parent post was spot-on.
> an engineer who’s expected to attend all the meetings and also be able to turn around designs and code is just not going to be as effective
Then maybe they are having too much asked of them. Or perhaps the meetings are actually more important than the coding tasks and that is why they get priority.
People need to learn how to delegate and how to let go. There is only so much time in a day. Either you delegate production tasks to someone else, or you let go of control and let people make decisions in meetings without your input. Both are valid responses to time pressure, and usually you need a mix of the two.

>Or perhaps the meetings are actually more important than the coding tasks and that is why they get priority.
If that is the case. Then the programmers KPI and perfomance review should be based on how many of these meetings they attended.
Hell if meetings really are more important and add to productivty. How about paying meeting attendance bonuses?
No one will put there money where there mouth is because they know it's a waste of time to have a meeting that could be an email.
They need to look busy to justify their own salary

My impostor syndrome briefly reappears every time I read articles like this :) I don't feel any state of "flow" or "zone" or whatever, and certainly wouldn't consider my entire afternoon ruined because of a single meeting in the middle as illustrated in the article. If there's a hard problem to solve, sure, I'll work on it until 4 AM because I have a hard time letting go of unfinished things, but that's mostly throwing hours at the problem and I don't think I'm massively more productive than during the day at the office.

Intense focus can be a symptom of ADD/ADHD [1]. I've always wondered if software developers who experience flow/zone (myself included) have varying levels of mild ADD that presents as intense focus.
[1] https://www.additudemag.com/understanding-adhd-hyperfocus/

If you genuinely are an X times programmer, unless you find the right environment, it is irrelevant. You will find under-utilization is common and so burnout comes quickly. As you can see in the comments, many places are unable to find ways to maximize your productivity. And once underutilized, you are of less value and so less valued. And even though these places will want you, they are a catastrophically bad match.
Since the risk of burnout from frustration is real, if you value your career, you will need to leave such places quickly until you find one that can utilize you maximally.

Conversely, get better at handling interruptions. In almost every non-junior role (not just "manager") you will be required to deal with many things throughout the day, coding being just one of them.

> almost every non-junior role
To me, this sounds far from being universally true. Some Sr. roles allow for hard-split meeting days vs. productive days, and moving to six week self managed "sprints" with regular updates to a draft publication instead of shuffling vaguely defined tickets around a board.

>Some Sr. roles allow for hard-split meeting days vs. productive days
Such as?

I'm not sure "get better at handling interruptions" is possible. If I'm juggling a dozen ideas in my head and am interrupted, that tower is going to crumble regardless. If you're suggesting I rebuild my methods of developing from the ground up to avoid that mindset, that's a huge ask. I'm not convinced it's even possible. I'm able to muddle through a task with regular interruptions, but I'll be more likely to make mistakes and it will take longer. There's a world of difference between what I accomplish in an "office" day vs a "coding" day.
I think the article has it right. Dedicate some "office hours" to being interrupted, but recognize that some people are far more productive during long uninterrupted periods.

Any tips on how to do this?

It’s practically from another era at this point, but on this topic I cannot recommend enough Time Management for Systems Administrators[1].
Ops Engineers have the Firefighter-Maker-Manager dilemma to contend with. The techniques to balance reactive work with planned work adapts well to SWEs in open offices with too many meetings.
[1] http://shop.oreilly.com/product/9780596007836.do

To be a SW rock star you need to master 3 languages:
1. The programming language used and its (de facto) standard libraries
2. The language of the important design- and tooling patterns that are useful in the said programming environment
3. The language of the Problem Domain.
If you can master all three, then you are a rock star your productivity will be much higher than those of your colleagues who have not achieved the mastery of these.
Now what is the language of the problem domain? Often it is just the methods and functions already present in the application. Here whoever made the original design has a clear advantage over others who started working on the same application later.
When starting from scratch it is the language of the business, say accounting terms, and their meaning if you are building an accounting system of some kind.
The code is just something written in these 3 languages, if you can speak in those languages you can write the code down, and can read it and understand it and thus modify it further.
To master all 3 of these languages can take a lot of effort over time. But so it is with true rock stars. Think Jimmy Page, he had a long career on stage and in studio before he joined Led Zeppelin.

Who are these managers with nice even 1 hour blocks? My time gets chiseled down to 30 and sometimes 15 minute blocks, with rampant double scheduling.

> At the same time, real work is not getting done. Meaningful work is usually done quietly and in solitude.
I don't really like this definition of meaningful work. Yes, there are some tasks that require focus and inventive mental work. But those aren't the only tasks a "maker" faces. And they aren't always the most important ones.

Totally. These days what I do is I allocate time for features/product and just go hard on it for Standups [1]. I do say 1-2 weeks building product as if it were a hackathon. When I am done, I go back to marketing & sales, in the manager's schedule.
So in short, I do things on consecutive days:
* to code, I do maker's schedule.
* to sell/talk to users, I do manager's schedule.
I'm feeling like writing on the topic as well, as it can be valuable for other solo founders too. I struggled a lot in the beginning when building Standups.
[1] https://standups.io

Why do you do both? Why not stick with the one you enjoy the most?

Because to do creative (product: code/design) work I have to really get uninterrupted streaks of work.
But to do sales, talking to users, I have to do it on the manager's schedule, with the typical slots within a day calendar schedule.

No. You misunderstand. Why do you want to do both creative work and sales?

I'm curious what the meeting schedule of Bell Labs was like. I get the sense that the researchers had plenty of time to invent, take naps in their office, and at the same time bring a lot of stuff to market.

This is kind of true but the article is pushing it a bit far. In the schema there is an afternoon with block of two hours. One would hope that a maker could do something in a two hour block...

I agree with the post's view of maker time. I disagree with its ideas around manager's ideal schedule. My experiences as a manager were that the disruptions of hourly 'something new' were unhelpful for strategy development or even moving the tactical horizon to something past 'next week'. This resulted in my 'actual' work being done before anyone else arrived or after everyone else left. I have met very few managers who did not have similar concerns.

I was digging this blog until...
"The most straightforward way to address this is to build a team knowledge base. Not only does that minimize the number of repetitive questions bounced around the office, it allows new team members to basically onboard themselves."
# Insert nuclino advert #
Right....That's a culture thing, more than it is a software solution. You can only use a software solution to aid the culture, not the other way around.
In my experience, This culture needs to come from the top-down.

Good idea in theory. Almost impossible in practice.

I have always time shifted my working hours, at SAIC, Angel Studios, Google, and Capital One I would arrive very early to get some quality thinking and coding time - and then leave early. Some people at work probably thought I was goofing off, but they would roll in at 9am and not know I got to work hours before they did.

As a manager it's very hard to get everyone else on board with this

>As a manager it's very hard to get everyone else on board with this
If management was easy then everyone would do it.
How about this for a start? You taking total control of your direct report's calendar. They have read only so can see what meetings you have scheduled they should attend. You book the meetings.
Anyone who wants a meeting has to disturb the manager (so there will be fewer requests) and pushback will have more force.
It's not whiny engineer saying they can't attend the meeting. It's the manager saying they are too busy.
You could also send just 1 report to a meeting instead of the whole team. Since you control the calendar you can choose who goes.

Paul Graham is so very, very right when he highlights the limitations of managers' view that "one hour" is an important increment of time.
For me, the most important interval is a decade. Get your big goals right, and that huge swath of time will let you do something hugely transformative in your work, your sidelights or your personal relationships. But to get there, you need the stubbornness to work through the hard stuff for a long time without immediate rewards.
You also need the freedom to reinvent your approach a couple times, without feeling embarrassed or doomed.
Being a maker calls for a totally different clock.

The makers response should always by default be. “Do you want i know or when its done” then after that a discussion about delivery schedules can be had.

Agreed wholeheartedly, in fact I try have meeting days and work days, the workdays I am usually working from home.

Erm, working at night has some serious health disadvantages. even if you get enough sleep during the day. One of the worst things you can do is switch those schedules regularly.
Some people may be able to do this, especially for a few months or years. Many however, will break down sooner or later!

This should be the top comment in the thread. This kind of work schedule is not healthy or sustainable. Long term success is like running a marathon.

For most people that's probably true. But I definitely know people that are just like that to the point that it's at least sustainable for them. They were absolutely brilliant, but kind of manic at times, and that's just how they worked best. They'd work for like 20 hours straight without eating and then come home, wolf down some food ravenously and sleep for 14 hours. Who am I to judge the schedule they chose?

Those people may actually exist. But it is easy to miss that they may indeed have pathological (hypo-)mania (and the occasional depression). Or that they take certain drugs. Or that their health indeed suffers. Or that they do break down after a few years.

I have heard this before (long haul stewardesses and breast cancer I think) but was that researched enough to say it like you say? Quite a lot of people who do this for decades without issues... I can see how it can be bad for people, but is the cause of that too little sleep, some reason of anxiety being unable to cope with 'the day', doing drugs, some stress factors that make it easier to work when the rest sleep etc; if one exchanges night with day fully, has that been proved to be objectively bad?

There may be people who can shift their night cycle, maybe even because of genetics or circumstance, but medical science says that circadian rhythms are hard to change and changing sleep cycles too fast leads to issues.
And this may also be a case of how many problems you have. Night shifts might not be a problem on its own, but throw in a little depression, or getting overweight, or whatever, and it's going to suck big time.

My suggestion is that you get rid of the managers and have senior engineers manage themselves.

That's why remote workers are more productive, provided they can get isolated at home.

Actually someone understands my trouble

So much truth...

interesting

Reply on news.ycombinator.com