I think the parent's point (though I could be reading my own thoughts into it), is that the things you mention only matter to the user if it directly affects them. An end user couldn't care less what the maintenance costs are if they aren't passed on to them in some way. If they are, then its completely in the interests of the company to have easy to maintain software. Or if changes are time-sensitive and the company is unable to keep up which change requests. If all that's invisible to "users" (or internal stakeholders), it really doesn't matter how much the boots on the ground hate the software.
But I think also the "code doesn't matter" really means, that ideally there is no (new) code, because there is in fact an existing solution but the person asking for the solution doesn't know it. This is likely more the case with internal stakeholders that ask for something to be built that does X, not realizing that there is readily available software or libraries that does X (or something close to it). So part of our role is to know the landscape of what part of the domain really needs new (potentially bug-ridden code) to be written.
> People working remotely may have health or social issues on a greater average.
I don't know any reason that working remotely would correlate to health/social issues. Is this a known statistic from somewhere? The social thing perhaps correlates to working (remotely or not) in a software field, but I'm not sure why remote workers would be statistically any different than non-remote workers. (I happen to be a remote worker)
I would think someone disabled or with mobility issues would seek out those opportunities over local employment at a higher rate. People with visa/passport/country of origin issues would have issues traveling would be another group.
From my experience the health issues point is true.
When I used to work from office my day looked more or less like this:
a) WALKING to the car/public transport,
b) sitting at a desk, meetings, multiple small breaks for lunches, chats etc.,
c) again some moving, coming back home,
d) SITTING AT DIFFERENT CHAIR WITH DIFFERENT DESK AND DIFFERENT PERIPHERALS AT HOME.
Right now:
a) waking up,
b) no one forces me to take breaks,
c) I do not change peripherals twice a day, so before I was using two different keyboards and two different mouses and two different setups daily, now I'm using the same mouse and the same keyboard and the same everything in work and after work, this leads to RSI and after 8 years I'm facing carpal tunnel syndrome in near future, also changing chair even to a shitty one for a while is apparently much better for your body than sitting in Herman Miller ALL THE TIME (I have standing desk too BTW).
Self selection? I assume a very social person applies to more in person than remote jobs. I assume more reclusive people apply to more remote jobs than in person jobs.
Neither is a guarantee but it’s a reasonably safe bet.
Who cares what some author or poet decided to write? Who cares what some scientist found? Who cares what food tastes like? Who cares what article someone posted on Hacker News? Who cares about the bug you fixed? Who cares what software exists?
Not really comparable, art and code are generally original. Transposing competitive sports to software would be as if everybody competed year after year to see who implemented the best and fastest quicksort in C in the shortest amount of time for instance. It's not usually about expression, it's about perfecting something until you're the best at it.
I don't think there's anything wrong with that although like the parent I can't say that I find that particularly interesting myself.
Oh I don't find sports interesting at all either, though I would argue that people do in fact try those sorts of competitions in coding. My beef with parent is the notion that this stuff is objectively pointless somehow just because _we_ don't find it interesting.
I prefer not to think of unit tests as a write to reason about the code you're writing now, but to let the system confirm that your current reasoning doesn't contradict with your previous reasoning (about other parts of the code).
I thought that at first as well (about the potential confusion), but then recalled that most of the "possible" alternatives aren't real English words:
"bah" is really only a sort of exclamation and the sound of a sheep, not something you'd really have appear in an interview.
As you pointed out, "awa(h)", "ga(h)", "sla(h)" and "sta(h)" aren't English words [1] that you'd confuse in context so "away", "gay", "slay" and "stay" are the only possibility for them. The "y" really is not necessary.
I really want to learn Gregg now...
1 "gah" like "bah" ends up being an exclamation, and "slaw" as a food... but I can't think of a case where it would be confused with "slay" in context.
The 'a' sound in "Slaw" is a bit tricky. it rhymes somewhat with the 'o' sound in 'ostrich', 'ought' or 'taught', which are written with the symbol for an 'o'. Oddly though, the word "Father" is written with an 'a'. If it's really necessary to distinguish between these sounds, Gregg Shorthand does allow for diacritical marks over vowels, but they are rarely used, since the meaning is usually clear from the context (and they slow you down).
It may help to realize that John Robert Gregg was Irish - so imagine his somewhat British pronunciation of vowels.
Since Gregg shorthand is written phonetically, the words "father" and "farther" are written pretty much the same . That becomes a bit confusing to an American speaker of English.
I taught myself shorthand in high school. I love foreign languages and found it fascinating. A "Secret Language" like someone said above.
But I agree with one of the other posters, if you do not use it often, you will find it very difficult to do well.
The basics of Gregg shorthand are incredibly simple, but it is another thing entirely to master - to be able to write quickly and accurately takes practice. Still, it is not impossible and you use it quite readily only knowing the basics. Unfortunately it has become a lost art except to a very few.
It would be quite an undertaking to write OCR software for Gregg shorthand because the writer has a lot of freedom to construct abbreviations on the spot or join several small words together when convenient (rather like native Germans can come up with compound words you won't find in a dictionary). The other problem would be clarity. While Gregg Shorthand doesn't have rules like Pittman for placing certain strokes on or above a line, proportion is quite important because several letters share common shapes ("n and "m", "p and b", "t and d", "f and v" are all quite similar but vary in length or height).
So the writer would have to be consistent in their proportions and the software would need to be able to learn the writer's style.
"only possibility for them" is not "the letter 'y' is silent", which the over-downmodded OP is complaining about. That it's not necessary for shorthand is not the same as being a silent letter.
For example, the vietnamese "chicken noodle soup" is spelled phở gà. It's pronounced something like fur gah. Every native English speaker I've heard (including me) that has seen that term written tries it out first as foe gah. If what the article was saying is true and the letter 'y' was irrelevant in such words, that first attempt would at least sometimes be foe gay - and I've never heard it that way at all.
Regarding 'sla', it's probably not going to be mistaken in context, but 'sla' is also a three-letter acronym that is moderately common - Service Level Agreement.
Jeez the amount of time I spent on E2 in high school and college was stunning. So many open tabs as I followed those links. Even wrote an app to find the "shortest distance" between two randomly selected ideas.
But I think also the "code doesn't matter" really means, that ideally there is no (new) code, because there is in fact an existing solution but the person asking for the solution doesn't know it. This is likely more the case with internal stakeholders that ask for something to be built that does X, not realizing that there is readily available software or libraries that does X (or something close to it). So part of our role is to know the landscape of what part of the domain really needs new (potentially bug-ridden code) to be written.