In praise of “normal” engineers

>> I know of only a handful of orgs that actually manage to build strong teams of really strong engineers

The best teams I've been on work like a team in sports.

You have the guys who are really good, really sharp developers. They know all the ins and outs of the framework, but are insanely specialized with one thing, but do the majority of the heavy lifting. Then you have the mid-range guys who are more of the JOT guys. They know UI/UX, accessibility, front-end dev and some back-end stuff. Then you have all the entry level rubes. The guys you can give them something to do and they'll figure it out. They're usually learning as they go, but can handle tasks with some direction and hand holding. As the project runs on, they get more comfortable with the processes and tasks so they need less direction and hand holding.

Building teams is all about finding a good mix of people who compliment each other. Too many of the really sharp devs and they'll be arguing over everything. Get too many mid-range or entry level guys and it will slow down the whole project. You also have to have devs who are comfortable with their skill level and know what they're expected to be doing. Too many times I've been on teams where the mid-range guys start bumping heads with the senior devs. Lunch becomes a rage fest over what we should be doing better. They think they should a lead dev, not the guy they don't like.

The last thing is your senior/lead devs have to have the right attitude too. I've been around some insanely sharp lead devs, but they're complete assholes. They know everything, you know nothing. You use shit frameworks, they're always on the cutting edge and your an idiot because you like Angular not something bougie like Svelt.

The key in all of this is finding the chemistry that works. When you get that chemistry, you can capture lightening in a bottle and really build some amazing stuff. When it works, its the coolest thing. People are dialed in, they're enthusiastic about what they're doing. They're willing to work longer hours to make sure the product we're building is incredible. The team is happy, delivering and working on faster sprints and things just feel effortless.

You think people not liking each other is an insane statement? I'll paraphrase Thomas L Friedman on a recent thing he said about the middle east. He said, paraphrasing "never listen to what an Israeli or Palestinian tells you in English, always see what they say to each other in their own language". Obvious insight, but not well practiced.

Do you think the amicable discourse on HN is indicative of feelings? Do you think the Hi and Hellos you get at work displays the true fabric of things?

I'll just start with small examples in case you want to keep the convo going:

1) Leetcode is a thing

How? Dude, there's dislike of a certain type of developer and obsession toward the idea of another type of developer.

2) Agile is a thing

How? Dude, there is dislike for the autonomy and value a developer brings.

3) How do you turn a "normal" engineer into 10x engineer

How is this question constructed? What is "normal" and who defined the ideal "10x"? How do you turn your "normal" wife into a dime? What? What kind of question is this? The business dislikes the price of a developer, how do we get more value for what we paid. These are the things you have to read into.

...

N) Plenty more examples, the tech industry operates on shade because our PR game is so fake (seriously, remember the ping pong tables?)

---

Which brings me back to "people don't really like each other" and good operations need to manage that.

I tend to think that much of the difference between great and mediocre engineers comes down to mindset. The great engineers I've encountered have a commitment to making everything they touch better. They are adaptable and persevere. They believe they will either succeed at the task at hand or conclusively determine that it isn't possible given the current constraints. They recognize that failure will happen and do not get discouraged by it and instead see it as an opportunity to growth. When they encounter an issue caused by systemic problems, they will try to fix it systemically. They will not ship the first draft and will take a little it of extra time to get things right, which slows the initial release slightly but more than pays for itself with a dramatically lower maintenance burden.

This type of engineer is often misunderstood and underappreciated by management. Management is often motivated by immediate short term goals. Instead of cherishing the work of the engineers who build the foundational systems that will enable the long term success of the org, they complain about them missing arbitrary short term goals and accuse them of doing engineering for engineering sake instead of real work.

Management will celebrate the coder who whips up a buggy, but cool, feature in a week and will look the other way at the fact that the feature will always be a little bit broken because of its shoddy construction and instead will allocate some lesser engineers to maintain it. If instead the feature had been built correctly from the start, it may have been launched a bit later, but the overall cost will be much lower. Moreover, the poor engineers who are forced to maintain it (and let's be honest, the people who quickly churn out shoddy but shiny work almost never have to maintain it themselves) will not only be wasting their time, they will be actively internalizing the anti-patterns present in the code. This both inhibits their growth and understanding of good design principles and teaches them the bad lesson that crap is good and unless they have a uniquely strong character or good mentors, they will tend to either become demoralized (hurting their productivity and value to the company) or they will internalize the incentive to get out of maintenance work and build shoddy features of their own to pass down to the next poor soul.

The truly great engineer is the one who breaks this cycle by building extendable systems that are correct by design and takes accountability for everything they ship. They raise up the entire org both by their work and example. In the long run, they will be far more productive and positively impactful than the sloppy cowboy coder.

Unfortunately, the industry writ large celebrates and incentivizes cowboy coding so doing the right thing is very much against the grain. Indeed, the people who rise up the org chart tend to be the cowboys so they cannot even see the value of the other way and will often actively antagonize or undermine those who do the right thing (and threaten their dominant position in the org).

One of the most contentious disagreements between myself and my current manager is that I say we should trust our peers to do good work and enable them with that fundamental assumption in mind.

IMHO if you assume the people around you are incompetent or malicious then that’s exactly what you’ll find.

Further, if the people around you are actually incompetent or malicious then awareness of that fact won’t change the outcome anyway.

This is all well and good, but it all hinges on your manager not being an insane maniac. All of those systems are great with the right manager, but if your manager is a KPI chaser / VP position seeker you are cooked.

I have had managers that were essentially like a sergeant, serving engineers as a phalanx against the business so we can go fast.

I have also had a manager who was so obsessed on showing off how much better of a dev he was than everyone else on the team, that he was largely hated and all talent on that team moved away if they could. I moved, and had a much better time in data science.

I largely agree that killer onboarding, and a clear path to deploy are big wins for normalizing your dev culture to new hires. The measurement tech is always a double edged sword.