7 ms·

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

by dhd415 8y ago

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.

maxsilver 8y ago
> 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.
- sulam 8y ago
  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.
  - deleted 8y ago
    [deleted]
  - twic 8y ago
    > 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.
Alex3917 8y ago
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.
- swatcoder 8y ago
  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.
  - matwood 8y ago
    "replaced or plateaued anyway." 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.
    - Alex3917 8y ago
      > or found out there is no market and never used 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.
nickthemagicman 8y ago
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.
- lylecubed 8y ago
  Just remember: If you're taking flak, it's because you're over the target.
- nine_k 8y ago
  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!
pm90 8y ago
> 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.
- crispyambulance 8y ago
  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.
  - rusk 8y ago
    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.
- riazrizvi 8y ago
  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.
usrusr 8y ago
> 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.

by dhd415 8y ago

maxsilver 8y ago

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

sulam 8y ago
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.
- deleted 8y ago
  [deleted]
- twic 8y ago
  > 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.

Alex3917 8y ago

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.

swatcoder 8y ago
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.
- matwood 8y ago
  "replaced or plateaued anyway." 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.
  - Alex3917 8y ago
    > or found out there is no market and never used 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.

nickthemagicman 8y ago

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.

lylecubed 8y ago
Just remember: If you're taking flak, it's because you're over the target.
nine_k 8y ago
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!

pm90 8y ago

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

crispyambulance 8y ago
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.
- rusk 8y ago
  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.
riazrizvi 8y ago
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.

usrusr 8y ago

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