Hacker News Reader

Comment by heyflyguy | Hacker News Reader

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.

View on HN

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 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 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.

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.

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.

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 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.

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.

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.

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!

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.

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.

"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

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.

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 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.

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.

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.

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.

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.

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

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.

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

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

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 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).

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.

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.

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.

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.

Reply on news.ycombinator.com