7 ms·
The force of competition at work. There are vanishingly few desirable opportunities in music and sport, and many potential contenders who will be selected on th
The force of competition at work. There are vanishingly few desirable opportunities in music and sport, and many potential contenders who will be selected on their individual skills and performance vying for those spots. Often to put in the hours needed to be competitive you have to also love the game; in all fields including knowledge work I’d speculate the top performers are more likely to enjoy the activity for its own sake than the median performer.
Knowledge work like programming is just much less competitive. In a graduating class of 5000 computer science majors at a good university, I’d be surprised if the majority fail to “make it” to a 100k job and be able to support themselves. Once you secure a spot in the workforce it’s pretty easy to hang onto it as an average contributor without much objective measure or comparison against your peers.
Compare to sport, at the same university maybe there are 50 spots on a sports team, and 10 good teams at the school. What percent of kids who start out playing a sport at 10 years old get to have one of those spots, and what percent of those who make the college team go on to make 100k, support their family etc playing the sport?
That competition forces rigor - if I had to compete like that to get a software job, maybe I’d be “practicing scales” on the weekend too, not just when gearing up for interviews.
" in all fields including knowledge work I’d speculate the top performers are more likely to enjoy the activity for its own sake than the median performer"--
In soccer, a sport I am very familiar with on the playing side at a reasonably high level, this is not true. The median professional enjoys training and playing far less than the median spectator and median player of lesser quality would expect.
The common refrain, "If I had that opportunity, I would train like crazy," "I cannot understand how people can make that kind of money and live the dream of being a professional player and yet..." clashes with the reality of young people, like most top soccer players, who want to party, not train as much, and live a life of equal wealth but fewer obligations.
They also tend to need objectively measured skills more than knowledge workers. We know what a good batting looks like but we still can’t say what good code is in any reasonably objective way.
Since code is primarily for communication between humans, I suppose we should look to the humanities and ask them what good writing is, but therein lay a parallel exercise to one suggested in the article.
Well written code in one language looks nothing like good code in a different family. They won't even share a similar syntax, grammar or idioms.
The only real lesson to be learned is "write for your audience" in my humble opinion.
Code is primarily for execution. It is very important that it also communicates to people, for the sake of the business that the code supports, but the main thing is the execution.
Not intended to be pedantic or contrarian, but I think this falls apart when the code is making sure a signal is sent somewhere (aka communication). If I write a module that allows IPC am I focusing on execution or communication?
I understand one can say they were “executing the communication” but at that point we ought to remove execute from the phrase if it has to preface anything you do.
To fully disprove my point, at what point do we never execute something with code so the distinction is even worth mentioning?
>> In a graduating class of 5000 computer science majors at a good university
Jézus Krisztus and people are wondering why there is a job crisis underway. I had to attend my nephew's university graduation this summer and was shocked to see some 500 computer science majors, thinking where will all these people find a job? And you're talking of 5000 as a "sure thing".
Well it ain't no sure thing anymore and graduate inflation surely don't make things better.
Doing some rough numbers:
There are ~2400 NFL players in the US, which means about 1 in 140k people.
If you figure that 10% of the people care enough about football to make an attempt, then someone who is in the 99th percentile of that group of people--someone I think many people would call undeniably good at the game, then they still have to be at least 99th percentile among those people to actually have a go of making it as a career.
You’re off by an order of magnitude.
There’s ~165 million males in the US, but many ex professional football players still alive and some kids who will eventually become football players. I doubt 10% of boys try out for high school or college football, but let’s say 10% make even some vague attempt.
Many people play professionally for a very short period, but arbitrarily suppose 1/7th of men are in the age range to play professionally. 165,000,000 / 2400 / 7 / 10 … So something like 1 out of 1,000 guys who make even a vague attempt end up in the NFL.
More realistically I doubt even 1% of boys ever approached football with serious intentions. Still horrible odds, except there’s a lot more athletic scholarships than openings in the NFL.
No, your math is cockeyed and the parent is much closer.
"Roughly speaking, there were 1,083,308 high school football players competing, and eventually 251 made it to pro. After simple calculation, we can get that the percentage of student-athletes going pro is approximately 0.023%."
https://u.osu.edu/groupbetaengr2367/junran-add-things-here-for-real/ https://u.osu.edu/groupbetaengr2367/junran-add-things-here-f...
Does a single university with a good reputation graduate 5,000 new CS majors per year? Or is that number just for the sake of example?
Totally random number, based vaguely around there being 2000 enrollments in US Berkeley CS61A per semester. Not nearly that many graduate in CS or EECS, but I couldn’t easily find a number.
UIUC awarded 500 ish CS degrees in 2023, so 10x less!
> Once you secure a spot in the workforce it’s pretty easy to hang onto it as an average contributor without much objective measure or comparison against your peers.
There's also the weird "success path" that goes from developer to manager. It's as though the end goal of learning to be a concert pianist was becoming a conductor, or perhaps a concert hall manager.
If your "success metric" is earnings, then "The force of competition at work" for knowledge work doesn't necessarily drive you to practice your Rust development "scales" every day, or to be the best Javascript dev in the team - it is probably a better use of your time to be "good enough" at your developer job, and hone your schmoozing and office politics skills to make the jump to better paid non development roles like "chief architect" of "VP in charge of {whatever}" or ultimately CTO or something.
That’s selection bias, not competitive pressure raising the top level. It’s not that professional positions being so few and far between for artists raise the bar. It’s that you are only looking at the top of the competent musicians which are actually far more numerous but keep music as a hobby because there is no job there. Take a similar sample of the "best" at anything and you will find similar traits.
Then why do we keep code after it has been compiled to a functional executable? Why do we (those of us working on teams) have rules limiting how code is written, or even in what language? Why do we study abstraction strategies like OOP and FP? Codifying and then storing a solution is not a necessity essential to a solution, it’s a necessity satisfying an external pressure. My conjecture is that that external pressure is the authors’ need to transmit solutions across time (eg to oneself when it stops running for w/e reason) and space (eg to collaborators), so the solution can be read and understood, revised and extended, in the same way we transmit other ideas in natural language prose or other symbolic systems. If we want to treat this outside of the humanities, we need to abandon high level languages like bash and C and return to manipulating registers and memory directly.
I say this often. Code is for people, and the qualities of great code parallel those of great writing: clarity, efficiency, and a sort of profound obviousness and inevitability.
The job of software architects is the role Heidegger ascribes to man when he calls us "shepherds of Being". To understand the world as it is, and find the right abstractions to describe it. To constantly evolve those abstractions toward better ones, clearer ones, to seek out ways to represent things that make solutions seem obvious and inevitable.
A mathematics professor once said to me that as time went by, the definitions in mathematics became more complex while the theorems became simpler. "Why is that?", I asked, and he replied, "It's progress!" This is the sort of progress that the software architect seeks as well: to set up the problem so excellently that the solutions are smooth and the process is enlightening.
Great writing, and great code, are first and foremost about great ideas. About brilliant ideas that change how you view the world for the better.
High school lasts 4 years. Some people play for all 4 years but if the average is 2 years you’re looking at 0.5 million people playing for the first time each year.
Most players aren’t drafted. The average NFL career lasts 3.3 years. 2400 / 3.3 = 727 new players per year.
500,000 / 727 would be 1 in 687 or 0.15%.
Goodness is fundamentally a subjective attribute. Trying to measure it objectively is attempting alchemy. You cannot make the subjective out of the objective - you will always have smuggled subjectivity in somehow.
Suppose I say that good code should have the lowest number of curly braces, or the lowest number of subroutines, or the flattest or deepest object hierarchy. A measure being objective doesn't make it good. So why is test coverage good?
In fact, every single one of the metrics proposed in the parent post is something I have seen gamed to the point of maladaptivness.
* execution performance time
- So frequently overly focused on that you can find google hits for "Premature optimization is the root of all evil." I have seen developers spend hours or days saving (sometimes imagined!) run time, where all the time they saved over the life of the product wouldn't add up to the time spent. Extreme pursuit of performance leads to code that is hard to work on - who cares about those milliseconds when critical new features take months to write, or are even impossible?
* build time -
It is very easy to diminish build time by destroying critical architecture. I have done it myself. :)
* regression frequency -
Insisting on only making very safe changes is how you wind up spending six weeks lobbying change control boards for one line of code.
*defect quantity -
In environments that actually track this, people merge issues into a single "fix what's wrong" ticket, degrading the utility of the ticket system. Defect granularity is not actually obvious!
* code size -
Obfuscated X contest entries are often very compact, and people who obsess on saving lines and characters can wind up leaning towards that style.
* dependency quantity -
Leads to attempts to homebrew encryption.
* test automation coverage -
Automated testing ossifies design and architecture, which can paralyze, e.g., an experimental prototype. Full coverage is also costly - time and energy spent maintaining pointless tests can come at the expense of mitigating more realistic risks. I realize I depart from prevailing wisdom in this, but there are times and places when automated testing is simply inappropriate.
* test automation execution duration -
Sometimes the right way to write a test is slow.
I'm not disagreeing that these are generally good things to strive for. They are! I'm saying that if you think these things define goodness, each one can lead you to a cursed place. (I hasten to add that there are times when a metric really does define goodness - sometimes you need speed or reliability or whatever, at any cost. Recognizing that circumstance and its limits - "any cost" does not generally mean any cost - is subjective.) Goodness is subjective, and while objective measures can help you assess it, such measures cannot define it - when and how you use which measures, and when you think they've gone off the rails, is itself a judgement call.
I once inherited a system that was both essential for business operations and a thorn in everyone's side. The guy I inherited it from (and the guy he inherited it from) had taken over a year to learn how to use it. I set about reorganizing, rewriting, documenting, abstracting - all those soft changes in pursuit of clarity and obviousness. They aren't objective, but they do pay off: when I handed the system off to the next guy (and three more after him!), he was off and building on it in a day. That was how I knew I had succeeded! When doing that sort of thing, you do always wonder if what you're writing is clearer for everybody or just you. But surely even the most hardheaded bean counter can see the value of training developers in a day rather than a year. That's good. :)
Goodness is contextual and subjective. I can agree that your goals are generally right, and I can point to circumstances where they're overemphasized or even outright wrong. Sometimes, when the sky is falling, a nasty little bash script that meets none of the usual criteria for "quality" is the best possible thing.
There are people who use subjectivity as a haven for vanity, and build mountains of pointless code in pursuit of some idea of goodness that serves no practical purpose or is even harmful. It is important that we retain our on ability to criticize on subjective grounds, precisely to counter that sort of activity - because you will find it in the land of the objective advocates as well, building mountains of metrics that don't serve any practical purpose either. To recognize a bad abstraction and a bad metric is the same skill, and requires the same confidence in your own good judgement.
Objectivity is no refuge from the necessity of good taste.
You are really wanting this to only be about code quality, whatever that means, and not product quality, which is something that can be measured from outside the organization by people with no understanding of your skills. I can repeat all day that it’s not about what you or other developers want but I somehow suspect you will circle back to code quality and goodness because those are important to you. That is why I claimed the prior comment misses the point. The complete inability for developers to accept, on any level, that it’s not about what they want, I believe, is why non developers stereotype developers as autistic. They aren’t wrong.
There are several things in this comment I find odd.
The comment about developers being autistic is particularly funny because I personally am autistic, and my wife (who you are responding to) is very much not. It was a major source of tension for us for many years.
Likewise, the emphasis on people "outside the organization" and the suggestion that she is somehow deficient on that front is laughable -- she's extremely highly regarded by customers/clients, and has been for decades, specifically for her ability to understand and solve their problems by getting them a great product whether or not they have any idea what her actual coding ability is.
And then the comment about "really wanting this to only be about code quality" is strange, since the subthread going back to kasey_junk's comment is about how "we still can’t say what good code is". Your initial response is entirely about measurable attributes of code (like code size and build time); Dove introduces "softer qualities" including "solving a valuable problem" (which is more about "quality product" than any of your metrics), and then you go back to a different set of metrics. She responded with an extended comment that specifically noted the importance of "complex impacts - on users, on business, on other programmers". Her comments have consistently been more about how good code impacts the functional product, while yours have been about measuring things about the code, but then your complaint is that she's too focused on the code and missing the point. Then you make comments about her own state of mind: what she is "wanting" to do and what you "suspect" she will do and her "complete inability" to accept certain things.
This very much feels like you just have a point you want to spike about measuring things (FWIW she does make it a point to measure things and to train her subordinates on making sure they're measuring things), and her comments (and my other one) are more excuses for you to repeat your point than actual ideas you're trying to interact with. Like you're not actually interested in engaging with the core idea that "Some of what code needs to accomplish - conceptualizing a problem well, communicating clearly - is inherently subjective, having to do with how it is received by another mind." It's just another opportunity for you to say that your set of objective measures are the only thing that matter, which, as I noted elsewhere, is itself a subjective position about which things to value.