So, some dude with an opinion started a thread about the mythical "10x engineer" and how to spot one. As someone who fits into some of the stereotypes that get thrown around about that term, or as someone who has exhibited more of those stereotypes in the past, I figured it'd be useful to compare and contrast, sample size of one, where I'm at vs. his opinions. On one hand, stereotypes have basis in fact. On the other, many stereotypes lead to dangerous cargo cult behavior that is not only harmful to everyone with the flawed notion of what a 10x engineer is, but also to any industry their flawed-view startup enters into. Which, well, software is eating the world, so there's a ton of harm that can be done by renegade startups, flush with venture capital, disrupting (in the causing-chaos/mayhem sense of the word) existing systems with oversimplified, low-quality-but-subsidized replacements. But I digress. Let's start off with...
Actually, maybe your meetings just suck, or you do really have too many of them, probably with no set agenda, so you're wasting everyone's valuable time (at least I hope you value everyone's time in your meeting, rather than taking hours out of their day for the fun of it). If you have a meeting, and the reason is one of:
...and you have very clear boundaries on those meeting topics, sure, have the meeting. Heck, add in a weekly sync meeting between stakeholders, as long as the meeting is allowed to end in five minutes if there's nothing to talk about. But use asynchronous communication until it's ineffective, because meetings that could've been emails are a time suck. Worse, when you have a truly important meeting, your invite will be treated as if the sender was The Boy Who Cried Wolf.
I'll be the first to admit that I have a borked circadian rhythm. Fortunately, various clients are willing to put up with my sleep schedule that matches Hawaii Time more than it does Central Time.
That said, this tweet is quite office-centric, and I'll bet you $5 in heavily-depreciated cryptocurrency that the "office" he's referring to is an open-plan bullpen that works best when everyone is working from somewhere else. Going hand-in-hand with meetings, there's the concept of maker versus manager schedules, and productivity dividends paid when you can actually hit a deep level of concentration are enormous. It's hard to get that with distractions, whether in-office or with Slack (it's always Slack) bugging you every five minutes. So the concentrated work gets done after everyone goes home (and nominally offline). Hopefully said concentrated work is on the right thing.
So yes, I'm saying that this tweet has baked into it the given that his office environment is a hive of distraction.
Feels like Shekhar accidentally a few words here. Anyway...
Yep, I like me a good dark theme, to the point that I've tweaked an existing dark theme for GitHub to fix cases where the original theme author didn't keep up with the site's new CSS classes. Yes, if you're working later, you may get less eyestrain by running a dark theme on all the things, without having to color-shift your display (hello f.lux, which has been largely supplanted by stuff built into OSes). Yes, I have no idea why Slack doesn't have a dark mode built into their desktop app in A.D. 2019. Yes, I even know a few keyboard shortcuts so I'm not having to swap between keyboard and trackpad (yes, even on my desktop) to get stuff done.
But dark themes do nothing at this point to pick devs of any acuity out from the crowd. And I don't follow the keyboard wear story at all...unless he's saying that devs have to use global search all the time rather than bouncing between function definitions in their editor...or maybe he's saying they're unimaginative with variable names. Moving on...
The first part is patently false, basically whatever way you slice it, particularly on a project with an actual team of devs (not a team of one...and yep, I've been a team of one on plenty of small projects). In any case, hopefully your star-student dev is using someone else's code, rather than reinventing the wheel for everything, because the latter is less productive (and maybe even less correct) the vast majority of the time.
Heck, at a certain size of project (and that size isn't very large), you have better things to do than to keep every line of code in memory, though hopefully your codebase is consistent enough that when a feature request or bug report comes in there's a logical place to go to change the code to make the ticket go away. And yes, having a consistent, memorable, maintainable application design decreases the size of the feedback loop for bugs. But if it takes a 10x dev to realize this, we're all doomed.
Going back to the first part of the statement, if you know every line of code in the system, that means you either wrote or reviewed every line of code in said system. Congratulations, you're now a bottleneck. Have fun never having vacation time ever.
It's quite difficult to be simultaneously a jack of all trades and an order of magnitude better than folks who more carefully play to their strengths/interests. Maybe impossible...and that's discounting Shekhar's contradiction with the same tweet: UI work is front-end, and treating it as less-than puts your business at a disadvantage. Yes, even Twilio has an extensive UI.
I say this as someone who can do everything on his short list of buzzwords, but realizes that for larger projects he absolutely shouldn't because two people playing to their strengths...and communicating properly...can end up with a better outcome than one person doing their own thing while wishing they didn't have to write browser code. Yes, I love Vue, and can build a front end if my arm is twisted enough. No, I'll avoid opting into that position nine times out of ten.
This is one of those "how long is a piece of string" tweets, combined with the built-in assumption that said engineer's original thoughts correctly portray the problem being solved, such that there's any hope of writing code that solves the right problem. Being able to hammer out an arbitrarily sized feature in two uninterrupted half-to-full days (sorry, nights...remember that the office is a madhouse during business hours) is of little value when it's the wrong feature.
One super important skill I've at least somewhat picked up is asking dumb questions until both I and the person being questioned (aka stakeholder) both have a clear idea of what's being built. This includes determining tradeoffs where providing a 90% solution takes 50% of the effort...and in many cases it turns out that the simplifying assumption for the 90% is perfectly acceptable all around. Yes, that means not putting fingers to keys in your development environment of choice right away in many cases...though in others it's useful to frame up a couple trivial code paths to clarify discussion of what to fully build.
Pause. No pause. Or maybe 10x engineers write bugs and typos too (spoiler alert: everyone does).
As for memorizing methods, parameter orders, etc., nope. You end up with diminishing returns pretty quickly as long as your tooling (IDE or the like) is decent, and/or your language/framework has good documentation. Yes, if you use array_map() and array_filter() in PHP enough you remember that the parameter order is reversed between the two, and you can probably remember that "i" in the language's date formatter stands for minutes (because "m" and "M" are month). But if it's so painful to look something up that you use once every three weeks that you commit it to memory instead, your docs probably suck and you should contribute fixes to said docs.
This is starting to sound like 10x engineers don't actually sleep. That, or their order-of-magnitude-better productivity is largely offset by attempting to scale fifteen different learning curves at once. While a healthy appetite for learning things is how I got where I am, and in certain areas I'll jump at the opportunity to simultaneously train and bill, at some point you need to quit switching between flavor-of-the-month frameworks and start delivering actual business value. And if you have to switch frameworks every month because last month's framework was a horrible decision, well, slow down and make better decisions.
I completely understand this pattern, because I have to actively try to avoid these behaviors myself when working on a team. But the fact that that's a struggle isn't license to put that behavior on a pedestal, because doing so is a one-way ticket to burnout. Yes, you can burn out high-performing devs by throwing them in the ring with junior hires and expecting them to have the same development velocity while imparting knowledge to others, but you need to find a balance where mentorship can happen, otherwise you'll be at a competitive disadvantage to organizations long-term who can figure that bit out.
As for interviewing, I'd argue that standard technical-position interviewing is broken, so the fact that folks who'd rather be coding than interacting with people highlight issues with technical-position interviewing is more a reflection of the broken institution than anything else.
The type of person he's describing here...which does exist at least in part...may think they're writing quality code. Heck, they may project that aura to anyone who dares to question them. But knowing exactly how the code has to evolve? That sounds like a merger of developer, technical stakeholder, and prophet. Sure, there are more brittle ways to write code, and if you understand enough about the domain you can avoid some of those, but it doesn't get much better than that.
As for design docs, you want enough documentation to ensure folks who aren't reviewing your code can confirm that you're building the right thing, but little enough (or, rather, non-redundant enough) documentation that keeping the docs up to date is something that, well, actually gets done. In any case, arbitrarily capping the amount of documentation for a project sounds more like someone either lacking or at least under-appreciating solid communication skills to me.
Lolnope. If they're so effective that they're an order of magnitude more productive than their peers (that's what 10x means right?) then, unless they're a social pariah (which, based on the above, they may be), there's a huge incentive for them to job-hop to ensure that they're extracting nearly as much value as they provide. Or maybe real 10x devs are all lazier about commanding their actual value than I am, in which case I'd rather not be an underpaid 10x dev ;)
As for "non-value-added activities", if training is non-value-added, fix your training. If process is non-value-added, fix your process. These issues don't just affect your magical unicorn 10x-ers.
Okay, so that ended up being less about me and more about opining on flawed assumptions (some of which even sound good on the surface) built into Shekhar's thread. And I've disqualified myself from being a 10x dev by stringing this many sentences together in English rather than, erm, Elixir, I guess? (note: I have no problem with Elixir and hear Phoenix is a great RAD framework).
One final note: there's absolutely such a thing as someone who's 10x as valuable as an individual contributor as they would be as a manager. This is why a number of solid software organizations have individual contributor promotion ladders (and pay scales!) that run alongside, rather than stopping short of, management bands. But those higher tiers bring with them the expectation that those folks are force multipliers. As opposed to bottlenecks who insert themselves in an organization such that everyone else is blocked at 10% productivity rather than executing properly as a team. Which might even look like the bottleneck is the 10x dev...yeesh.
