The only way to win the game is not to play at all. Do good work, don't let the company take advantage of you, make promises you can keep, and then KEEP THEM, treat your colleagues nicely, teach when you can, learn when your colleagues have something to teach you, say "I don't know" and "I was wrong", and "Thank you", study and practice servant leadership, and remember that your worth as a human is not very closely related to what's written on your paycheck.
I'd say it's usually a bad one. By staying out of politics, you're electing to be at the mercy of others, who can (and inevitably will) take advantage of you.
Which is a better use of time: staying in the same place and contending with assholes who want to take advantage of you, or shrugging it off and going somewhere else with fewer assholes?
We are always at the mercy of others, and I prefer not to negotiate with terrorists. Let them squabble over their petty ambitions; I'd rather spend my time among people who are more interested in collaborating with me than exploiting me.
Also, deciding when to switch jobs base you decission on what you have, not what you were promised or what you think you might get at your current job.
The concept of "status illegibility" is certainly an interesting one that coincides with some experiences I've had. In a former role in which I reported to the VP of Engineering, due to his lack of ability to directly evaluate work, he would base performance reviews on a weighted average of your teammates' assessment of your work. As such, it was very much, as the linked article on status illegibility states, that the "illegibility of the status of any member of a group is proportional to his/her distance from the edges of the group." In other words, performance near the median was widely praised, but performance both near the bottom or top received criticism. It was not a pleasant experience.
Another hard-learned fact that he mentions is that being good at your job is overrated. Few of us would like to admit that, but as he explains, the benefits of some automation vs. no automation greatly exceed the benefits of some automation vs. better automation. The only workaround that I've found for that is evaluating roles for their need for technical excellence. Building a CRUD app to "revolutionize the [insert favorite industry here]"? It's not going to require or reward technical excellence. Unfortunately, the kinds of projects where technical excellence is legitimately required and rewarded are relatively rare.
> Unfortunately, the kinds of projects where technical excellence is legitimately required and rewarded are relatively rare.
I find that this really depends on the situation one is in. Its true that building a CRUD app may not really require excellent technical skills, but building a highly available app that can be updated without outages, able to serve traffic in sometimes strange patterns (e.g. Lyft's traffic pattern v/s Walmart's) while being resource-efficient is still a challenge.
I'm still astonished at how much interesting, practical innovation continues to happen in our Industry. I somehow assumed that once things got standardized around certain environments, interesting things to do would stop. That has not yet happened and I am very grateful for it.
I see the word "CRUD app" thrown around here like it's always a triviality. That's only true in textbook exercises. CRUD is almost NEVER trivial in real life, especially in enterprise environments.
Aside from the fact that each of those letters in the acronym may have arbitrarily complex requirements and challenges behind it. There are _REAL_ organizational problems of getting the application designed, implemented, approved. And there's training, deployment, lifespan maintenance and decommissioning.
I mean, sure, many enterprise apps look like they were designed by an institutionalized autist in 1995 (cough... Oracle EBS) and these _ARE_ CRUD apps. Wanna be an ERP software billionaire? Beat the crap out of Oracle, SAP, Siemens, etc. Come on, they're just "CRUD" apps.
I had to cringe there a while ago, when a customer came back from a conference said he was talking to xyz CEO who told him "it's just a CRUD app" and how could it possibly be so difficult, and then proceeded to hand me his requirements in video presentation format.
CRUD apps might require business domain knowledge and good process logic but they don’t stretch your architectural skills, they don’t stretch your systems skills, nor your language skills. This is because most CRUD applications generally boil down to 1) data IO plumbing/scripts 2) SQL and DB architecture, 3) reporting. The pure technical aspects can be mastered in a few years. They are not a route to becoming a brilliant software engineer.
Sure for some no-true-Scotsman definition of “CRUD app” this is 100% true.
However even for the most boring CRUD app there is still unlimited applicability of intelligence and skill to build the right thing balancing speed of delivery, performance, UX, maintainability, and requirements compromise for simplicity. Doing this well is a path to business success far broader than winning a dick-measuring contest at FANG.
No one is saying CRUD developers are not smart. It sure takes intelligence to build good CRUD processes. Each one is a slice of a business process. Goodness knows you can spend many lifetimes doing that, and you would accumulate more and more business process know-how. That’s very valuable, and can be very highly rewarded, especially if you are the only person who understands it well. But like I said your software knowledge would quickly plateau, compared to someone who is building new green field applications that are more broad. This is just my perspective after 25 years of doing both types of work and seeing what effect they each have on your technology skills over a ten+ year period.
My problem—hinted at in my opening sentence—is that "CRUD app" has become a vague pejorative with no clear definition. All software reads and writes, there is some hand-wavy sense that software becomes interesting when it has massive scale, or in interesting domains, or embedded, or has tight performance constraints, etc. But what is actually "boring CRUD", it ranges between 5-99.9% of all software depending who you ask.
> CRUD apps ... don’t stretch your architectural skills, they don’t stretch your systems skills, nor your language skills.
then
> This is because most CRUD applications generally boil down to ... 2) SQL and DB architecture, ...
Hmm? Do CRUD apps, in your opinion, involve architecture or not? I can't tell what your position is.
In any case, CRUD is generally used to mean "RESTful", which basically means you have an HTTP API on top of the app.
Some cases I've seen started with trivial underlying NoSQL DBs, and then grew insanely complex. That's architecture right there. Even if you start with SQL, if you don't know the language and how to model the data effectively, then chances are you'll end up in a world of hurt.
> VP of Engineering, due to his lack of ability to directly evaluate work, he would base performance reviews on a weighted average of your teammates' assessment of your work
I know this is an old hat discussion, and this argument was lost ages ago, (and I don't know if you are specifically referring to this) but that situations like this happen at all really bothers me.
Assuming the "VP of Engineering" means "VP of Software Engineering" (or the "CTO" of a software company, or equivalent). If he/she can't truly evaluate the work, he/she is not qualified to be in that role, full stop, no exceptions. No one expects them to read/write code all day (often, they might spend no time at all reading/writing code anymore). But they have to be able to do so, or they have no place in that role.
In the same way that the Chief Nursing Officer at a Hospital has to have been a qualified licensed RN, and be able to be a qualified licensed RN, even if they don't actually work as a nurse on the floor anymore.
One is that sure, a VPE/CTO who cannot evaluate technical contributions in a vacuum is unfit. I agree.
However, a VPE who can't evaluate any specific technical contributions in their organization may not be failing, and in fact probably isn't.
To evaluate someone's technical contributions, there are at least two things you want to look at (there may be more, but there are at least two): resultant impact, and inherent complexity[1] of the problem. A VPE should almost always be able to evaluate the first. They're the one setting goals. They can evaluate a person's contributions on whether or not those helped meet or met those goals.
They won't however be able to know the inherent problem space complexity. That requires a level of in-the-weeds familiarity with the space that you don't get as a non-individual contributor. It's practically impossible to accurately judge how difficult a problem is to solve without either having attempted to solve it yourself, or seeing how many people perform solving it, and most of the time, you don't have many people attempt to solve the same business problem.
You also don't want to solely trust the people working on the project, they have reasons to inflate the complexity, both conscious and unconscious. So you use a lot of things to gain partial signal:
- what they say: "this was hard"
- what other people who had views of their actual contributions say: "their problem space looked difficult and I couldn't find any better solutions"
- what people with historic knowledge of the component/space say: "Their solution managed to clean up years of technical debt that I accrued when designing this system"
- Smaller impact metrics: developer velocity improved when making additional changes to the new system, etc.
But its often not possible for a VPE to directly assess those things, they don't have the context to do that for every employee.
[1]: Note that this is complexity of the problem space and not complexity of the solution. Simple solutions to hard problems are good things, complex solutions to complex problems are acceptable, and complicated solutions to simple problems should be a negative. And yes, you need to account for problem space complexity, otherwise you encourage infighting since performance = impact, then higher impact per unit difficulty will result in better performance per unit time.
Let’s test this assertion. Does it hold in the extreme?
For instance, why then does the person that VP of Engineering reports to not need to be a qualified engineer? If this is the CEO then it’s clearly impossible for them to be qualified at all of the functions they are ultimately responsible for. If we accept that the CEO is essentially incompetent at their job the way it’s defined here, why are we unwilling to accept it one node down? Is the function of that node to somehow insert all the competence the node above them lacks? We will shortly see that this can’t possibly be the case.
Another example — suppose this person has held management positions for the last 15 years. In a large organization this is likely to be true. This person last coded before some of our most popular languages even existed, and in the Node case they have missed umpteen million iterations on what a good webdev stack looks like. They also have never done modern mobile development and probably couldn’t gradient descent themselves out of a paper bag. They wouldn’t get through a phone screen, so how are you so sure their technical skills matter?
Another issue: assuming they somehow find time to keep up to date on some aspect of software engineering, how likely is it that the one area where they are a qualified developer is the only thing they manage? Or is it more likely that they manage distributed systems engineers next to machine learning specialists next to security engineers next to site reliability, system engineers in test, and Bluetooth LE on Android specialists (that’s the reality where I work)? How can they possibly be an expert on all of this? Given that they lack true expertise, why would we value faux expertise?
My simplifying assumption is that skill at a job they do not do is actually close to meaningless and in fact what really matters is their ability to be effective at the thing they spend 10 hours a day on — communication, setting directions, intently listening, resolving conflicts, and integrating the demands of the business, customers, and the people that have entrusted them with a portion of their career.
> For instance, why then does the person that VP of Engineering reports to not need to be a qualified engineer?
Because that person isn't evaluating their direct reports on the basis of their engineering ability, or even their engineering leadership ability, but their management ability. Unlike the crummy boss in the parent comment.
How do CRUD apps not require or reward technical excellence? The velocity of a SaaS business is arguably more closely linked with the TCO of CRUD software than for any other type of business/software.
Success in SaaS is really just lead bullets over units time, which is a function of the TCO of each feature and the entire system.
You're prematurely optimizing. The "velocity" of an SaaS business may be tied to its CRUD, but acceleration and fuel are the limiting factors for 99% of SaaS businesses. (i.e. marketing and capital)
It's easy (trendy?) to waste capital and attention pursuing overqualified talent to write code / design architectures that will be replaced or plateaued anyway. Less "technically excellent" work can get to that same milestone cheaper and faster.
There are projects where technical innovation and scalability are the defining feature and where excellence matters on launch day. Generic "CRUD apps" are not that.
Agreed, or found out there is no market and never used. This is a constant battle I have with the more pure engineers in a startup. Speed to feature release to allow marketability to be proven is #1. Only after it is proven, can you start to add better design. I'm even a fan of doing some process manually until it's untenable. By then I have a proven process, and know what parts need to be automated and scaled.
Of course this is different in established companies or those projects beyond the typical CRUD app.
Right, that's why there is a lot of time pressure. You start with 20 or so different overlapping ideas in your head that each might or might not be viable, and then it's a race to see how many you can get through before running out the clock.
To me though this is a strong case for why total cost of ownership matters. If your startup's chances for success are determined by how many ideas you can try out in the market before running out of money or whatever, then why wouldn't you want a codebase that makes it as fast and easy as possible to transition from one variant of the idea to the next? To me that is a form of technical excellence.
Yeah, it’s often treated as a binary proposition, when in reality it’s about the right tradeoffs just like anything else. One problem in SV culture is tenures are too short and there is too much boom/bust with rapid hiring and layoffs. When you actually stick around to see long-term impact of technical decisions you start to develop a sense for which things matter and where it makes sense to cut corners versus where you are painting yourself into one.
This disappointed me so much about the software industry. I thought it was going to be a bunch of excited passionate people working like at a Makerspace.
Instead the places I've worked at have been cattier then a sorority house.
Excitement and passion also abound where people are partly paid with it, instead of money. See computer games industry, see startups that offer much equity, etc.
Enjoy the calm of your sorority house employer, and use the time it gives you for activities of your choosing (including, but importantly not limited to) more software development. You might end up to be expected to enthusiastically work on things of your employer's choosing, 60 hours e week, because, well, it's so advanced and exciting!
> the benefits of some automation vs. no automation greatly exceed the benefits of some automation vs. better automation
Contrary to that claim, it's been my experience that bad automation can be much worse than no automation. There is usually some hard to define quality threshold below which all efforts just make things worse.
I think the article is reading far too much into this whole "positions we don't hire into" thing. Usually, those are just roles invented to keep key people aboard who are refused the conventional hierarchical rise (and raise) due to Peter Principle awareness and/or not fitting in with the execs.
Walking repositories of the history of in-house technology, software archeologists who know where to dig because they've been there when it happened. It's impossible to hire that kind of knowledge. Usually, when a position invented to keep that kind of knowledge aboard gets vacated, the hat won't even be handed on in-house to the next best candidate, it will just get abandoned.
Unfortunately, the premise of the article comes off a bit like someone sitting on the fat spoils of strategic job hopping being unreasonably envious of the modest rewards of staying put, wishing to get them on top. I do like the humble use of "programmer cred" as a non-substitute of actual performance/ability.
Some of these roles are also where some very talented engineers end up who have decided they do not want to graduate to management positions. So it's quite possible they weren't refused advancement, they were offered it but turned it down because they wanted to keep working on [X] project instead of other products they weren't interested in, or managing people where that is a skill they know they don't have.
So it's quite possible they weren't refused advancement, they were offered it but turned it down
Absolutely!
Anecdata: I have 30++ years of experience. I enjoy programming. I do not enjoy managing people. I do OK managing projects, but don't enjoy it.
Especially in the first 10++ years, when I had my yearly performance review I would tell my boss "whatever you do, don't make me a manager." They tried talking me into management roles quite a few times (and succeeded occasionally getting me to fill a technical management role in projects) but have mostly honored my request.
If I had gone into a (technical) management role I would likely have made a little more money but my stress level would be a lot higher and my enjoyment would have been way way lower. I've watched other engineers that went the technical management route and have been very happy with my choice.
Staying heavily technical isn't the right choice for everybody, but it was absolutely the right choice for me.
That's actually part of what I meant with "Peter Principle awareness", although it is definitely not what I wrote. I actually believe that not wanting a management role (what you wrote) is far more common than getting denied despite trying (what I wrote) for the kind of people we are talking about here, those who may actually end up getting a high status non-management role invented for them.
These types of highly-specific, broad scale, psycho-social analyses can be interesting and insightful, but should always be taken with a large grain of salt.
After all, the fields of psychology and sociology are still searching for fundamental paradigms, so it shouldn't be surprising how difficult it is to make strong, specific claims of this sort.
I would argue that there is very little correlation between a programmer's perceived skill level and their actual skill level.
I know some programmers who used to be considered rock stars because they created a lot of popular libraries and modules at an opportune moment in history but years layer it turns out that their
code was full of security vulnerabilities.
Also some programmers are highly optimized for certain things to the point that they're terrible at everything else - I know programmers who are really great when it comes to writing performant code, but they are unwilling to make compromises to make that code more readable.
It is interesting how this article assumes programmer skill has little overall business impact, whereas PG famously argued the opposite. Does the conclusion hold without this assumption?
Using the article's definition of "programmer cred," might the the issue be that the recognition of programmer skill does not extend beyond a very small social radius, regardless of actual business impact?
is this "the best is the enemy of the good enough" and "I don't want it perfect, I want it by Thursday" (J Pierpoint Morgan for the latter, I have no idea for the former)
Feels like it is. If you aren't obviously slacking, and aren't so good you're in the wrong place you score evens from your peers. And, cohesively, you get there, for some value of there, which may be below optimum but sometimes, the local optimum is what you want.
More specifically, in another post [1] he's admitted outright that his "opportunists, idealists and pragmatists" are just a more polite renaming of the Gervais Principle's dark triad.
from my experience it isn't "the role we don't hire into" - it is "the role we typically don't hire into" :) I.e. the former is just a hi-tech version of the dealers' "we don't sell cars below MSRP".
100% of your salary in a satellite office is about visibility from the main office. You should be giving talks to groups of people in the main office, partnering with top people in the main office to share best known practices, and having strategic catch ups with top management in the main office.
In most large corporations (with some notable exceptions) the way pay rises are determined is that your boss will have a budget for his team (possibly $$$ but possibly just 'ratings' that fit a distribution). Then their boss will review all the teams under him to make sure the distribution and budget for their organisation is satisfied and this goes up and up until you reach departmental level.
So you don't just need a good rating from your boss, you need everyone in each of those hierarchical discussions to know who you are and back your value. Because if not, it's very easy for them to cut 10% off the pay rise of drone 7b to give to Johnny star performer.
As well as that there's another dynamic. If the people in those conversations think you are good, then your boss is under pressure to say you're good in order to demonstrate (s)he is a good manager who can identify talent and take the hard decisions necessary to keep the best people.
Basically, you have to demonstrate value rather than provide value.
yeah highlighting "Uncle" Bob as a "10" with respect to programmer cred was a weak point of the essay. He is basically a one trick (TDD) evangelist pony and I doubt he has any serious developer cred outside the agile methodologies circlejerk groups. Not like he is Linus or Carmack or Jeff Dean.
That said, the actual phenomenon that the author was trying to highlight with example is pretty valid imo.
"Companies like this don’t hire 10s because a single 10 will single-handedly raise their margin or even land them clients. They do it to grease the skids of recruitment. That hire is neither about clients nor about work product — it’s about recruiting."
