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.

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.

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.

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.

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.

Or I need to stop saying it that way myself.

MMMV?

One thing I noticed is that I’d probably feel off calling a group of female coworkers gals, so I tend to refer to them as women I work with.

Conversely though, I rarely refer to group of male coworkers as men I work with and would probably say “a couple of guys at work” or something.

Language is funny like that, and intent, tone, familiarity, and cultural background matter a lot too.

For instance I’d never call anyone honey at work, but when an older black woman would say something like “oh honey, we can’t do this like that” it was totally fine because it was quite clear that was just her lexicon and it wasn’t uncomfortable for anyone at all.

Life is full of ambiguities, generally if you have to ask “might this make someone uncomfortable?”, I generally just avoid it.

Which can be a bit tough for me sometimes, I definitely grew up and would pepper my speech with curse words as in “oh shit!” Or “holy fuck really?”, but I’ve learned to limit that a bit over time.

Know your audience.

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

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

Time to let go.

(btw might look into Aspergers/ASD)

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.

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.

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.

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.

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.

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.

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.

Well intentioned work can still be bad or not usable or not the thing the code needs right now.

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

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.

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)

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

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

    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. 

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.

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

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.

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

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

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.

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.

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

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

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!

“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 was a lot happier and less busy trying to be a 3x engineer making everyone else into 1.5x engineers.

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.

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.

This causes other people to have to follow the style, but it also prevents them from making something worse.

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"

    "The cure for this, both in software development and 
    elsewhere, is both simple and difficult"

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.

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

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.

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.

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.

A group of 10 seems too large and counterproductive. I think a group of roughly 3 seems about right.

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. 

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.

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.

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.

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.

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.

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.

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

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.

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

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

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

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

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.

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

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)

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.

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.

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.

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.

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

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.

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.

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

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.

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

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?

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.

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.

McCarthy's 1995 book "Dynamics of Software Development" has a chapter devoted to this phenomenon.