In those situations biz > user by definition and the developers end up having to cater to the needs of the middle managment of their customers rather than the needs of the actual users. The price of not doing this is failing to win the contract. Users then get locked in to whatever crap you have time to provide for them while you're really busy implementing new features that middle managment like.

You essentially only need a nice looking login screen and some sort of reporting and the rest.....doesn't matter much.

I am being a bit cynical but it does pay as an engineer to know if that's fundamentally the kind of company you're in.

An online retailer, for example, is hypersensitive to its users and I know of at least one that has different versions of its website for different countries because they know that Germans like X and Americans like Y - small changes make a huge difference to sales.

Other companies have no sensitivity to the usability of their products because the people who buy their products are never the users.

We needed to win contracts, so we needed to tick their checkboxes, but we also cared for the user experience (good UX was almost never a strict requirement from our customer).

Our competitors' software was very painful to use, so we wanted to differentiate in this regard.

This made our own lives easier as the training was easier, the users we interacted with (that usually had no say in whether our solution was bought to them or our competitors') were happier and recommended to their managers (where they could) buying more stuff from us.

In the end this was 80% driven by pride (our software doesn't suck) and empathy (I couldn't stand using the software if it was as bad as our competitors') but to some extent this was also in our interest (especially in the long term, where your brand is built).

And then the happy users switch to another company and start recommending your stuff to their new managers. It's an extra source of leads and sales :-)

Unfortunately that works until some brilliant mba shows up with a plan to sell 100x more consulting and more training by making the product intentionally much more difficult to use.

It was a doomed approach. We needed salespeople to get inside the heads of the purchasers, learn how to explain the benefit to them, and coach the users on explaining the benefits to other people in their organization. We needed salespeople to bridge the chasm between the users and the purchasers.

I remember being in site meetings where people who used it every day would tell us to our face how terrible it was. Without fail, that site renewed with some promises to fix a couple specific bugs and a minimal price increase.

this is why all enterprise software sucks

Can you speak any more to this? Do you or anyone else have any examples? I would be very interested to see.

This is why I use Windows and Visual Studio at work. I don't like either of them, but it's not my call.

SAP absolutely delights its users to the tune of a $200 billion market cap.

Take one look at EMRs and realize that its sold / marketed to .01% of the hospital, despite 80% of the health system using it.

Again, you can exclusively cater to management, but you don’t have to. Look at Datadog. It’s a great product, but still ultimately purchased by management.

From my observations, it's usually not that devs are lazy or lack a sense of craft, it's that their employers are not willing to spend money building something that isn't actually a requirement.

or worse think they are good at it. Then guard that GUI like it is their first born.

Your uses of "every" and "big" here seem idiosyncratic.

Slack in particular had to take a just-OK buyout from Salesforce and the product has seriously stagnated.

> To conclude, the ≹ symbol plays a crucial role in providing a middle ground between the traditional relational operators.

As a PhD student in math, I have never seen it before. I do not believe that it plays any crucial role.

This symbol for it may be useful, but it's the concept that matters.

I really love that video.

The space of possible abstractions for any given phenomenon is vast, yet we almost always just assume that real numbers will do the trick and then begrudgingly allow complex ones when that doesn't work. If we're not lucky we end up with the wrong tool for the job, and we haven't equipped people to continue the exploration. It's a bias with some pretty serious consequences (thanks... Newton?).

I don't think I've seen the inadequacy of number-systems-you've-heard-of demonstrated so clearly as it is done here.

Well, don't leave us hanging! What are some of your favorite hot games on top of switches?

"Example 1: Numerical Context

Let's consider two real numbers, a and b. If a is neither greater than nor less than b, but they aren't explicitly equal, the relationship is ≹"

How can that be possible?

But the numerical context can still be correct: (edit: ~~imaginary~~) complex numbers for example don’t have such a property.

Note that Games do _not_ form a field: there is no general multiplication operation between arbitrary games.

Or more generally, vectors. They don't have a total order, because as we define "less than"/"greater than" in terms of magnitude (length), this means for any vector V (other than 0), there's an infinitely many vectors that are not equal to V, but whose length is equal to length of V.

Is this is what ≹ is talking about?

Imagine you have 2 irrational numbers, and for some a priori reason you know they cannot be equal. You write a computer program to calculate them to arbitrary precision, but no matter how many digits you generate they are identical to that approximation. You know that there must be some point at which they diverge, with one being larger than the other, but you cannot determine when or by how much.

https://en.wikipedia.org/wiki/0.999...

The 1/3 * 3 argument, I found the most intuitive.

Thats what's counter intuitive to people, it's not an issue with 1/3. That has just one way to write it as decimals, 0.333...

All the decimals that recur are fractions with a denominator of 9.

E.g. 0.1111.... is 1/9

0.7777.... is 7/9

It therefore stands to reason that 0.99999.... is 9/9, which is 1

Let x = 0.99...

Then 10*x = 9.99...

And if we subtract x from both sides, we get:

10x - x = 9.99... - x

And since we already defined x=0.99... when we subtract it from 9.99..., we get

9x = 9

So we can finally divide both sides by 9:

x = 1

The geometric series proof is less fun but more straightforward.

As a fun side note, the geometric series proof will also tell you that the sum of every nonnegative power of 2 works out to -1, and this is in fact how we represent -1 in computers.

Isn't the sum of any infinite series of positive numbers infinity?

You can 'represent' the process of summing an infinite number of positive powers of x as a formula. That formula corresponds 1:1 to the process only for -1

https://en.wikipedia.org/wiki/P-adic_number

\2 is "not always" ..

Consider SumOf 1 + 1/2 + 1/4 + 1/8 + 1/16 + 1/32 ...

an infinite sequence of continuously decreasing numbers, the more you add the smaller the quantity added becomes.

It appears to approach but never reach some finite limit.

Unless, of course, by "Number" you mean "whole integer" | counting number, etc.

It's important to nail down those definitions.

The same argument I mentioned above, that subtracting 0.99999... from 1 will give you a number that is equal to zero, will also tell you that binary ...11111 or decimal ...999999 is equal to negative one. If you add one to the value, you will get a number that is equal to zero.

You might object that there is an infinite carry bit, but in that case you should also object that there is an infinitesimal residual when you subtract 0.9999... from 1.

It works for everything, not just -1. The infinite bit pattern ...(01)010101 is, according to the geometric series formula, equal to -1/3 [1 + 4 + 16 + 64 + ... = 1 / (1-4)]. What happens if you multiply it by 3?

        ...0101010101
      x            11
    -------------------
        ...0101010101
     + ...01010101010
    -------------------
       ...11111111111

There is some weird appeal to the Zeta function which implies this result and apparently even has some use in String Theory, but I cannot say I was ever convinced. I then dropped the class. (Not the only thing that I couldn't wrap my head around, though.)

Do that multiplication and you'll find the result is (1 - 2x + 3x² - 4x⁴ + ...). So the sum of the sequence of coefficients {1, -2, 3, -4, ...} is taken to be the square of the sum of the sequence {1, -1, 1, -1, ...} (because the polynomial associated with the first sequence is the square of the polynomial associated with the second sequence), and the sum of the all-positive sequence {1, 2, 3, 4, ...} is calculated by a simpler algebraic relationship to the half-negative sequence {1, -2, 3, -4, ...}.

The zeta function is just a piece of evidence that the derivation of the value is correct in a sense - at the point where the zeta function would be defined by the infinite sum 1 + 2 + 3 + ..., to the extent that it is possible to assign a value to the zeta function at that point, the value must be -1/12.

https://www.youtube.com/watch?v=jcKRGpMiVTw is a youtube video (Mathologer) which goes over this material fairly carefully.

Edit: Not in many programming languages. In IEEE-754 inf == inf. In SymPy too oo == oo, although it's a bit controversial. Feels sketchy.

Now if you really think about, a number of a given magnitude on x axis also isn't exactly "equal" to a name of same magnitude on y axis or vice versa. Other wise, -5 and 5 should be equal, because they're the same magnitude from 0.

I've never really seen this notation used, but it could have some use in partially-ordered sets.

Edit: oh, I see what you mean. 1 is not larger or smaller than i, but it also doesn't equal i.

Contrived, but only thing I could think of.

You could imagine two fuzzy numbers with the same 'crisp' number having different membership profiles, and thus not being "equal", while at the same time being definitely not less and not greater at the same time.

Having said that, this all depends on appropriate definitions for all those concepts. You could argue that having the same 'crisp' representation would make them 'equal' but not 'equivalent', if that was the definition you chose. So a lot of this comes down to how you define equality / comparisons in whichever domain you're dealing with.

  (a+b)^2 != a^2 + b^2

Strictly you should write something like

  ¬[∀ a,b  (a+b)^2 != a^2 + b^2]

\inf and $\inf + 1$ comes to mind but I don't think it really counts

That just depends on the numeric structure you're working with. In the extended reals, +inf is equal to +inf + 1.

In a structure with more infinite values than that, it would generally be less. But they wouldn't be incomparable; nothing says "comparable values" quite like the pair "x" and "x + 1".

So you can end up with a sequence "d > b > a" and "d > c > a", but "c ≹ b".

Defining how tie-breaking for those cases are deterministically performed is a big part of the problem that CRDTs solve.

https://en.wikipedia.org/wiki/Partially_ordered_set

The author of the original article uses it correctly - think about it more in regards to importance for their example.

The business is no more or less important than the developer, but they are NOT equal.

It doesn't have to mean importance though, just the method by which you are comparing things.

Monday ≹ Wednesday

Come to think of it, it should be called the 'No better than' operator.

Not in a partial order.

For example in this simple lattice structure, where lines mark that their top end in greater than their bottom end:

      11
     /  \
    01  10
     \  /
      00

That’s only true for a total order; there are many interesting orders that do not have this property.

It holds for the usual ordering on N, Z, Q and R, but it doesn’t hold for more general partially ordered sets.

In general one has to prove that an order is total, and this is frequently non-trivial: Cantor-Schröder-Bernstein can be seen as a proof that the cardinal numbers have a total order.

For example, set inclusion. Two different sets can be neither greater than not smaller than each other. Sets ordered by inclusion form a partially ordered lattice.

It really is an interesting thing. In fact, as human beings who by nature think in terms of abstract, non-concrete units (as opposed to mathematically precise units like a computer program), we tend to compare two related things. They might belong to the same category of things, but they might not be eligible for direct comparison at all.

Once you internalize partial ordering, our brain gets a little more comfortable handling similar, yet incomparable analogies.

Hell, I could spend $200 for a month of server time on AWS and run a lot of my (web API) code 100 billion times.

Optimizing for human readers is always better until you're working on something that proves itself to be too slow to be economical anymore.

    user > ops > dev
    biz > ops > dev
    biz ≹ user

Or they picked a title that would let you rapidly spot who didn't even skim the article.

(And most of your users don't have developer's salary, or developer's quality of life, so it hurts them that many times more.)

--

[0] - Yes, wasting someone's time reduces QALY.

> that by making the code better for the user,

Did you mean the dev?

Abstractions MIGHT make your code slower. But there's a reason we're not using assembly: Because the minor efficiency hit on the software doesn't match up with the bugs, the salary towards the experts, the compilation errors, etc.

A VM is a pretty good tradeoff for users, not just devs.

> When I say “run” I don’t just mean executing a program; I mean operating it in production, with all that it entails: deploying, upgrading, observing, auditing, monitoring, fixing, decommissioning, etc

the inference process in article is interesting, but title tempt us to debate about a less related topic.

thanks for your comments let me finish reading.

If you don't fit in the budget for the specific task, your product features don't matter much.

Like I said, it works until it doesn't, and then you do have to optimize for performance to some extent.

Some LLVM-based language would fit the bill better, like Rust, C (also true of the intel compiler and gcc), C++, etc.

This sort of calculations you preach are inherently untrue, as they completely ignore that 1second times million. After all, nobody bothers economically evaluate just a single second. But it does account to much, when multiplied by the ammount of users. And when we multiply again, by the times a single user uses your software, and then again, by the time a users uses different software from other developers who also thought "it's only 1 second, nobody cares", we end up living in world where software usability gets lower and lower despite hardware getting faster and faster.

We end up living in a world where literally weeks are wasted everyday, waiting for slow windows file explorer. If you'd want to evaluate that honestly, you would probably come to conclusion that microsoft should have a dedicated team, working for decade on nothing but explorer startup optimization, and it would still pay for it self.

But they don't. Because at the end of the day, this whole "lets evaluate developers time working on given improvement" is just a cope and justification of being us lazy, that only pretends to be an objective argument so we can make ourself feels better

Another way of stating the relationship could be something like: You have fewer brain-cycles to apply to optimization than the combined sum of everyone who will ever read your code, if your code matters. But that is a mouthful and kind of negative.

    1. Language designers & standard lib developers.
    2. Shared module or library developers.
    3. Ordinary developers.
    4. End-users.

The point is that the tiniest bit of laziness at the first or second tiers has a dramatic multiplicative effect downstream. A dirty hack to save a minute made by someone "for their own convenience" at step #1 can waste literally millions of hours of other people's precious lives. Either because they're waiting for slow software, or frustrated by a crash, or waiting for a feature that took too long to develop at steps #2 or #3.

It takes an incredible level of self-discipline and personal ethics to maintain the required level of quality in the first two steps. Conversely, it deeply saddens me every time I hear someone defending an unjustifiable position to do with core language or standard library design.

"You just have to know the full history of why this thing has sharp edges, and then you'll be fine! Just be eternally vigilant, and then it's not a problem. As long as you don't misuse it, it's not unsafe/insecure/slow/problematic." is the type of thing I hear regularly when discussing something that I just know will be tripping up developers for decades, slowing down software for millions or billions.

There's plenty of ossified code people are scared to touch because they don't understand it, but stake their business on it :)

Sometimes when you don't change anything, it just keeps working.

So I guess that makes it a very boring:

   code that can't be read won't be changed and will not be relevant for long, but not always

Non-coders are weird.

I had found some operations to tweak the scoring, except that some were multiplications by one, so I removed them. But I got told to not touch them because they wouldn't know if I had broken it until some customer complained.

The CTO told me off for my completely irresponsible behaviour.

I'm sure it has happened more than once.

I'd say it's more 'code that can't be read won't be modifiable for long'.

Usual reminder that many people in our industry are not native speakers and don't live in an English speaking country, and yet they make the effort to write in English, which may explain the "tortured turn of phrase".

> just rechewing of popular truisms

And yet these "popular truisms" are particularly well put together in a coherent way, which makes this post a useful reference.

  theory > /dev/null

    blog 

Everything is new to someone, and even if this was just confirming my own biases I found it an interesting take.

Firstly, in this framing, the "dev" is not one person but it is a collective for lots of people with varied expertise and seniority levels in different orgs – product, engineering and design orgs.

Then, "ops" is again not one thing and not just engineering ops. It could be bizops, customer support etc. too.

Then, "biz" isn't one thing either. There's branding/marketing/sales/legal etc. and execteam/board/regulators/lenders/investors etc.

All of these people affect what code is written and how it is written and how and when it is shipped to users. Everyone should be solving the same "problem".

A lot of the times, a lot of people within the org are just there to make sure that everyone understands/sees the same "problem" and is working towards the same goals.

But that understanding is continuously evolving. And there is lag in propagation of it throughout the org. And hence, there is lag in everyone working towards the same goal – while goal itself is being evolved.

Finally, "user" is not one thing either nor any one cohort of users are static. There are many different cohorts of users and these cohorts don't necessarily have long-term stable behaviors.

So, it helps to understand and acknowledge how all the variables are changing around you and make sense of the imperfect broken world around you with that context. Otherwise it is very easy to say everyone else sucks and everything is broken and you want to restart building everything from scratch and fall into that and other well-known pitfalls.

Business isn’t more important than anything. There are multiple users, sometimes with competing interests; you can’t be everywhere and everything, so you have to prioritize. Going after more profitable users or users that align with some long-term strategy could be seen as “good for the business,” but really the goal is to serve the users (it might just take a couple extra steps).

When the internal politics get confused to the point that people are making decisions just to further the interests of the business without figuring out how it leads to user happiness, the organization has become poisonous. It shouldn’t exist anymore. It might lurch on in a zombie state for quite some time. But it is on the decline, and all the good people will leave.

Businesses exist in as much as they are the primary determinant of most people's lives. They shape our cities, our media, laws, politics, foreign policy and have a huge impact in just about everything else that matters. Real or not, it has _real_ impacts all around us.

Outside of OSS, I think it's pretty clear that the entity that's footing the bill gets to make the call on how things get made. Even if that's: bad for said entity, bad for the user, bad for the public generally, the environment, etc. (of course, there's industry and governmental regulations, but by and large the company calls the shots).

Business, unfortunately, exist to serve their owners. In most cases (I'm talking primarily about larger companies, not

Employees won't leave, because the company will make sure they're happy enough. It's surprisingly easy to keep people working for evil and/or faceless organisations if you pay them well, make them feel like part of a "community", etc. (see any FAANG office for an in-depth catalogue of these HR tricks)

I agree that this is "poisonous" and that such a company "shouldn't exist anymore", but this is how companies work in practice. This is not a sign of any kind of decline, but of a mature and healthy business that can keep going for decades. Execs change, products change, even owners change, but the business remains.

Yet, importance is subjective. If you're working on your own pet code for your own pleasure, business has no importance. If you want to transform that into your main revenue source, business is the most important thing, because no amount of user love will transform into practical revenue if your software serves no-one.

It's group of people A, who are conducting a [series of] transaction(s) with group of people B. It so happens that the wares being exchanged are currency vs. software but that's really besides the point.

Group of people A ≹ Group of people B

IMO the reason the article had bring up this obscure !>

Which one to pick isn’t as linear as the article portrays and it changes over time. You can’t religiously plant yourself in one corner of the triangle forever.

Low quality will loose users and eventually also profit. Rushed development inevitably degrades quality over time, even if initially a high AWS bill hides this fact. No income and eventually you run out of cash to do any of the other 2.

> There’s a mismatch between what we thought doing a good job was and what a significant part of the industry considers profitable, and I think that explains the increasing discomfort of many software professionals.

"Discomfort" is quite the understatement. This leaves so much unsaid.

I will add some questions:

- What happens when your users are not your customers (the ones that pay)?

- Does your business have any ethical obligation to your users -- all of them -- even the ones that do not pay?

- What happens when your paying customers seek to use your business in ways that have negative downstream effects for your users?

For example, what if:

- Your platform makes fraud easier than the existing alternatives?

- Your platform makes it easier to misinform people in comparison to the alternatives?

- Your platform makes it easier to shape user opinions in ways that are attractive (habit-forming) but destructive in the long-term?

All of these have proven to be successful business models, over some time scales!

Given the reality of the dynamic, should a business pursue such an exploitative model? If so, can it do so more or less responsibly? Can a more ethical version of the business mitigate the worst tendencies of competitors? Or will it tend to become part of the problem?

A key take-away is clear: some classes of problems are bigger and more important than the business model. There are classes of problems that can be framed as: what are the norms and rules we need _such that_ businesses operate in some realm of sensibility?

Finally, I want to make this point crystal clear: a business inherently conveys a set of values: this is unavoidable. There is no escaping it. Even if a business merely takes the stance of 'popularity wins', that is in itself a choice that has deep implications on values. Political scientists and historians have known for years about the problems called 'tyranny of the majority'. Food for thought, no matter what your political philosophy.

I don't know 'the best' set of ethics, but I know that some are better than others. And I hope/expect that we'll continue to refine our ethics rather than leave them unexamined.

[Updates/edit complete as of 8:03 AM eastern time]

Hardly. I'll quote the last paragraph and the three inequalities:

> There’s a mismatch between what we thought doing a good job was and what a significant part of the industry considers profitable, and I think that explains the increasing discomfort of many software professionals. And while we can’t just go back to ignoring the economic realities of our discipline, perhaps we should take a stronger ethical stand not to harm users. Acknowledging that the user may not always come before the business, but that the business shouldn’t unconditionally come first, either:

    user > ops > dev
    biz > ops > dev
    biz ≹ user

Second, "the user may not always come before the business, but that the business shouldn’t unconditionally come first". This is very much aligned with my question "what are the norms and rules we need _such that_ businesses operate in some realm of sensibility?"

...

Ok, putting aside debates around the author's intent or 'valid scope' of this discussion (which by the way, is a rather organic thing, computed lazily by the participants, rather than by fiat), I'd like to add some additional thoughts...

In much of the software world there is a mentality of "We'll figure out Problem X (such as a particular problem of scaling) if we get to that point." I'll make this claim: naively deferring any such problems that pertain to ethics are fraught. Of course there are practical considerations and people are not angels! For precisely these reasons, ethics must be something we study and put into practice before other constraints start to lock in a suboptimal path.

I often look at ethics from a consequentialist point of view that includes probabilities of system behavior. This could be thought of as computing an 'expected future value' for a particular present decision.

If one applies such an ethical model, I think the impacts of choices become clearer. And it becomes harder to use false-choice reasoning to demonize others and exonerate ourselves. For example, if a particular business model has a significant probability of harming people, one cannot claim ignorance much less complete innocence when those harms happen. They were no surprise, at least to people who pay attention and follow the probabilities.

Ascribing blame is quite difficult. I like to think of blame as being a question largely of statistical inference. [1] But even if we all agreed to a set of ethical standards, the statistical inference problem (multicollinearity for example) would remain. There is plenty of blame to go around, so to speak. But certain actions (very highly influenced by mental models and circumstances) contribute more than others. [2]

To what degree is ignorance an ethical defense? This is a tough one. Not all people nor entities have the same computational horsepower nor awareness. I don't have the answers, but I have not yet found a well-known ethicist in the public eye that speaks in these terms to a broad audience. To me, the lack of such a voice means I need to find more people like that and/or contribute my voice to the conversation. The current language around ethics feels incredibly naive to my ears.

[1] I agree that for most people, ethical rules of thumb get us 'most of the way there'. But these heuristics are imperfect.

[2] To be clear, I see blame as often overused. I care relatively less about blaming a person for mistakes. I care much more about what a person's character tells us about how they will behave in the future. That said, a corporate entity is not a person deserving of such generosity. Corporate entities are not first-class entities deserving human-rights level protection. A legal entity is a derivative entity; one created in the context of laws which should rightly function to better the society in which it is formed. A corporate entity can rightly be judged / evaluated in terms of its behaviors and internal structure and what this entails for its future likely behavior. We don't expect corporate entities to be charities, for sure, but we also didn't consciously design the legal environment so that corporate entities can actively undermine the conditions for a thriving society with impunity.

Don’t follow it blindly of course, there are exceptions where dev > biz (see OpenAI debacle) and where dev > ops (early stage startup, move fast, in particular dev > ops because biz)

How would it work if it wouldn't? He explains what he means by that. If you spend time and resources on all things the users require and your run out of money and go out of business, everybody loses.

Of course you can take any of the "rules" and take them to an extreme where they become wrong. But I think if you don't push them to their breaking point they are good rules of thumb :)

I think there is also a bit of a conflation of values vs ability. The formulas in the article represent values. Real life adds constraints based on what's possible.

Consider his formula for dev vs user: "user > dev". You could argue that, just as a business is constrained by time and money, so is the developer constrained by time and skills. And yet, the author is happy with turning the greater than sign towards the user in this formula. Why?

It's a priority ranking, not a zero-sum game.

Or, we could ditch the "biz" part. It just so happens that software not written to serve business interests tends to also respect users.

All that said, I was actually referring to individuals (who aren't necessarily developers) choosing which software to use. Over the last 20 years, we've all taken free downloads and sign-ups for granted, ignorant to that whole "if you're not paying, you're the product" thing, and a lot of us now have a $500+ supercomputer in our pockets which is to some extent owned by a tech giant and not its nominal owner. It's apparent that such centralised platforms have some intrinsic problems with regards to users' freedom. That's what I'm cautioning against—not the idea of selling your programming labour to a business, which is fine.

[1]: https://en.wikipedia.org/wiki/Australian_property_bubble#For... (This article is outdated. From a quick web search, it seems foreign real estate investment fell during the pandemic but has now picked up again.)

[2]: https://www.abc.net.au/news/2022-09-02/housing-property-aust... (1M unoccupied houses in a country of 26M, ~120k of whom don't have secure housing...)

[3]: https://stackoverflow.blog/2021/01/07/open-source-has-a-fund...

[4]: https://blog.opencollective.com/funds-for-open-source/

[5]: https://docs.opencollective.com/help/financial-contributors/...

[6]: https://docs.github.com/en/sponsors/sponsoring-open-source-c...

The biz sits there rubbing its hands, watching us making the means of production more and more complex and expensive to use, so that it has a complete monopoly on creating software.

Devs are so used to relatively big paychecks from the biz that unconsciously tend to ignore these issues.

It’s not implementing dark patterns and cookie popups that makes you on the biz > * side. Tolerating the complexity of software development is. “Biz > complexity > *”. Push the complexity to the right as much as possible to ditch the biz.

Due to developer deformation it should be explicitly stated what the complexity is:

- Pointless “constant evolution” (version.major++ in less than 5-7 years, previous versions abandoned),

- Embracing epoch-breaking changes (2/3, ESM)

- Low-level as the norm (scaffold, config, listen, route, ddl, connect, hash, jwt, css, setstate, useeffect, fetch, … in place of business logic)

Also, I don't understand your last point. Are they all React builtins or something? If you're suggesting that the "shape" of an app's navigation, or of network or system calls, etc. should be how business logic is made concrete, I'd have to disagree. That sounds like microservices but with worse intrinsic documentation (the purest documentation there is).

I will add that-knowing- all this is helpful, but implementing it when you are early in your career is hard.

For example, it's good that Business is the big priority, but when you gave no experience of what is good, or bad, in business, it can be hard to understand the ramifications of decisions made now.

Equally, business priorities should win, but your goals and the business goals may not be aligned. An individual may need to resume-pad (learn that new framework) while the business may want homogeneity (everything built on one framework.)

Finally, of course, this refers to commercial software. Open Source software is the exact opposite flow, dev > maintainer > user > business. Which ultimately explains why it's so hard to get funding for OSS.

(dev = ops = user) ≹ (biz).

That's a pretty sad assumption.

"dev > user" is why a lot of projects have very poor usability.

it should be improved upon by responses from the users who use your implementation, but what you're saying suggests that efforts like architecting your software in ways that improve/maintain development standards or packaging your software in a dependency manager before delivering any level of user facing feature is a sad assumption to you. I don't think the concern of usability here takes the entire picture of a project into context.

    learning > biz > user > ops > maintainer > author

    dev > *

    learning > *

For example maybe you've spent 10 years building the same CRUD front-ends over and over. You're probably really good at that. And the companies that you worked for needed that skill. However, you'd be a lot more marketable if you had other skills that you could put to use at future jobs.

One of the worst examples was Amazon. They gave no indication ahead of time, but I was presented with a coding test with only a small subset of languages. My chosen language was F# because that's what I was most comfortable with but of course it was unsupported in their online tool. I solved a problem using discriminated unions, pattern matching, and pipelines. The interviewers were very confused, a bit antagonistic that I'd choose anything other than Java (even though no one told me ahead of time that there was a limited selection), and proceeded to show their lack of knowledge. For example, the interviewer kept bringing up a violation of the open-closed principle in my code. However, as I explained to them, that principle is only really applicable to object-oriented code. Since I was using a union data structure and pattern matching, that principle is not really applicable, as the functional approach is a transpose of sorts from the OOP approach. But I just got blank stares and an automatic deflation in the room of the interviewers communicating that they were ready for the interview to end. What was mind-blowing about it is that my resume lists nothing but functional oriented programming languages, with not a single example of Java, and I have plenty of code examples posted. But yet, I get asked some dumb question about reading a file using some terrible online coding platform.

During my career I've had to study:

  - electrical engineering (phase angles, current transformers etc)
  - finance (payroll and accounting)
  - building management (maintenance schedules etc)
  - mining (terminology, how explosives are set in underground and open mines)

> When I say “run” I don’t just mean executing a program; I mean operating it in production, with all that it entails: deploying, upgrading, observing, auditing, monitoring, fixing, decommissioning, etc. As Dan McKinley puts it: "It is basically always the case that the long-term costs of keeping a system working reliably vastly exceed any inconveniences you encounter while building it."

One of the things separating a great developer from a good one, IMO, is the ability to treat the documented API boundary of an open-source library as something that isn't sacrosanct and impenetrable.

How comfortable are you with command-clicking into, or outright cloning and reading, a library's source to understand the nuance that the documentation may not convey (or situation where the documentation is outright wrong)? Depending on your language's support for it, have you monkey-patched issues, or forked a library (and ideally submitted patches upstream) to add extension points you might need? Are you used to setting breakpoints inside of libraries, not just your own code, so you can understand how data is represented internally when debugging?

And when you're evaluating whether to use a library in the first place, do you just look at the API and examples, or do you read the source to understand whether the underlying code prioritized maintainability, extensibility, and test coverage? Do you read changelogs and think about whether the library maintainers prioritize your ability to upgrade without breaking even your patched/forked code?

The brilliance of open source is that we can do this. We're not just fitting gears together - we're able to fabricate iterations on those gears as we need to.

This one sounds like there is only the HN reality of dev : startups, VC, growth hacking, free until is not, client=product, burn every $ to reach monopoly,...

But, there is another one with small businesses, craftsmanship, get what you pay, client=client...

This is why software engineering needs licensure. Not to check if people understand design patterns, or whether people know the fad library of the day, but to set clear ethical standards and hold people to those standards by disbarring them if they violate those standards.

Or more to the point:

  society > biz > user > ops > dev

Likewise code should be optimized for reading, which is to say for maintenance first, and for other things only if/when needed.

In that version of capitalism, if your OS spends too much time putting spam in the Start Menu and not enough on fixing bugs, you can just switch to that other OS with full support from hardware vendors, that runs all your closed-source legacy software. If your favorite bird-themed social media site starts doing boneheaded stuff, you can just switch to that other site that has all your friends and data and lots of posts from experts and celebrities. If your search results are full of spam, you can switch to that other search engine with 10,000 highly paid engineers and 20 years of experience in Web search and integration with all your devices.

And all the businesses you moved away from would have to clean up their act or go out of business. If only those cows were perfectly spherical.