Highlights from the Comments on Elitism as Mid-Career Growth Engine
Strong opinions, loosely shared
Simplicity is for elitists.
Maybe some of you remember Didier Verna's [blog post on] Lisp, Jazz, and Aikido.
It's not hard to sympathize with Verna's feelings. These are all based on a similar set of philosophical guideposts: maximal output for minimal input, maximal possibilities of self-expression from a minimal set of generative rules, and understanding the deep "essence" of the craft, so that when you add your own contributions, it is by finding the "essence" of the addition and harmonizing it with the essence of existing work. And these are appealing because they give the feeling of tremendous power and the sky being the limit.
But the real world runs on the philosophy of Visual Basic, punk rock, and mixed martial arts, which are all based on a different set of philosophical guideposts:
a) focus on practical solutions to real world problems;
b) make getting started as easy as possible for everyone;
c) it doesn't matter if added components harmonize with the original;
what matters is if they contribute significant value on points a) and b), i.e., it's okay to get messy.
First of all, the linked-to essay is excellent. I highly recommend reading it.
Second — I think the idea of “philosophical guideposts” hits on the essence of my argument. The elitist sets these guideposts and ranks people and practices according to how well they represent them.
bitwize’s “real world” and Verna’s “beauty/fun/unity” guideposts are just two examples. They are philosophical lenses that you can be consciously aware of, and that you may be able to take on and off. But importantly — you think they matter, that there is something objectively right about the guideposts.
For Verna, that means striving to find unity across in multiple spheres of his own life. For bitwize, he is comfortable making a universalizable statement on what philosophies matter in the real world. Presumably, he would think that “beautiful-code-for-beautiful-code’s-sake” is, well, for amateurs.
This transition from junior to senior includes another important skillset: balancing social dynamics against engineering realities….
Bringing this [elitist us/them] practice into a situation where the target is a member of the group's work changes the dynamics such that you have to mind your Ps and Qs again -- and so, dampens learning.
A few readers mistook (understandably) my stance on elitism as “permission to be a jerk,” but “having an opinion” is not the same as “making people feel bad” or “being obstinate and incorrigible”.
An example: Academic institutions frequently invite speakers to give research presentations. Do you know what the most cringe-worthy moments are? When, following the talk, the audience is silent — no reaction.
The best moments result in a spirited exchange of ideas. But you can only have that when two people have perspectives, and those perspectives differ and need to be reconciled. It doesn’t have to be personal conflict, although it sometimes spills over into that. But it has to be conflict, or it’s just another lecture.
It stands to reason, then, as you grow, you want to put yourself in positions where you can generate healthy conflict so that you can synthesize and support the larger community’s growth.
I think it’s even simpler than this white/black belt metaphor.
Driving your career forward requires delegation, scaling yourself through others. Doing this effectively requires having strong opinions. The author is referring to these opinions as elitism, which is jarring to me. It could be elitism or simple pragmatism.
The elitism framing from an essay by Venkatesh Rao a few years back. His definition of elitism there is political: “a subset [of society] that regards itself, and is regarded as, entitled to a sustainably better than average human condition, with attendant privileges.”
When we say, “driving your career forward” we are implicitly regarding a certain class of person higher— the subset of society who have reached senior management, or staff engineer, or whatever. There’s a value judgment there, and in tracer4201’s case, that judgment is favorable to people who (presumably) can build the business through pragmatic decision-making.
What interests me is the non-default-path judgments. If I decided, “Independent consultants are the real elite,” then my orientation changes. My pragmatism needs to serve a different goal — that of allowing me to bootstrap a business, get clients, etc.
Where does the motivation come from? How do you quickly evaluate new situations? That’s where the elitist lens becomes useful: you can immediately identify the playing field, the players, and the game, then react accordingly.
I didn’t read the article but my infant is teething and I didn’t sleep last night - but this article is terrible right? Hand-drawn charts?
I can assure you, OP is a total clown.
I have come into serious conflict with one of my coworkers over this. He thinks everyone (except him) is either overengineering or underengineering everything all the time, but usually he just doesn't understand the problem context and is making assumptions that turn out to be incomplete or incorrect.
It's a great lesson in humility to realize that no matter how smart or capable you are, you don't know what you don't know until you find out that you don't know it. I used to be a lot like him until I got slapped around pretty hard (metaphorically) as a result of my arrogance.
When is it most useful to get slapped?
If you get slapped early, you might get discouraged. In any case, it’s a cruel thing for others to do. They should be lending you a hand.
If you get slapped at the top, there could be political consequences for your larger project and others working with you. Being slapped is part of the game, but by then you would hope to be strong, so that you can endure it and/or slap back.
But getting slapped around when you’re in the mid-career — established but learning — is one of the best ways to learn and grow. But you won’t be slapped if you never have opinions, and you can’t be humbled if you never take risks.
Now, later on, maybe my emphasis is more on business outcome than perfect implementation or maybe I've been involved in making enough abominations due to time pressures and architectural compromises that I can read those forces in other people's work.
Either way, I don't feel that kind of disgust anymore. It's code. No one is going to read it. It will be replaced next year. It works or it doesn't. Having to rip stuff out when the business changes or someone ways to use a different stack for resume reasons is part of life.
I wonder if this is an adaption or a maladaption.
Or maybe this is enlightenment. And perhaps the road to it goes through pressure, compromise, and abomination.