Although ethics are involved, the abstract says that the conflicting importance does not come from ethics vs KPIs, but from the fact that the ethical constraints are given as instructions, whereas the KPIs are goals.
You might, for example, say "Maximise profits. Do not commit fraud". Leaving ethics out of it, you might say "Increase the usability of the website. Do not increase the default font size".
They aren't pestering the developers; they made a comment on HN about what, to them, is an essential feature of a note-taking app. The developers may never see it.
I happen to agree with them. The single most important aspect of a note-taking app is that I must own my notes. That means that I must be able to take them elsewhere if I want. Including, in fact, especially, if the company hosting
them goes out of business or simply chooses to discontinue the app (looking at you, Google).
If I can take the plain text but lose the formatting or the cross-linking, that isn't good enough (hello Google Keep export).
But if lowercase can find enough customers who don't feel this way, all power to them.
What note-taking app are you using currently, if any?
I've been using Silverbullet [1] for a while now and love it due to it's usage of plain-text markdown files in a normal directory structure to actually store the notes. Yet, it supports many other features such as query language and to a certain extent, federation with other SilverBullet instances. The only major downside for me is that whilst it's usable on mobile, it feels cramped.
About 10 years ago I joined a new company, and I looked at their code and thought "what idiots wrote this?", which was strange, because everyone there was very bright. A little while later, some more new devs joined, looked at the code, and thought "what idiots wrote this?", and I was a bit annoyed, because some of that code was mine. They did a big rewrite. A little while after that, some more devs joined, looked at the rewrite and thought "what idiots wrote this?".
Fundamentally, no-one likes working with other people's code or solutions. They always think that they'd have done it better if they'd had the chance.
I see this attitude a lot and I now kind of categorize it within "contempt culture", which I think mostly just falls out of insecurity. I've been guilty of this myself and I try pretty hard to not do it now, but life is a journey and all that.
I do two things to dig out of this particular hole:
- Have some (relatively) objective standards by which I judge code/a project
- Have some empathy for people who were probably just doing their best, in the most multivariate sense ("I wrote this in Clojure so I didn't burn out", "I had to ship this in three days and I was just back from paternity leave", "I was onboarding a junior engineer and dumped this spaghetti in a spare 3 hours to mollify an important client"
#2 is very useful because it snaps me out of contempt and helps prevent me from spreading that culture to the engineers around me. But #1 is actionable in that when I do get time to "do things right" I have some values to aim at. Mostly they're:
- Does this code build/respect a coherent mental model of the problem space
- Is it possible to represent invalid state
- Are surprises/pitfalls noted (I'm not a big commenter in general, but this is a case where I find them useful)
- Does this code consider likely engineer workflows (e.g. is it easy to add another case to handle, is it easy to enable debugging, etc.)
Notably none of these are like, "methods are too long" or "variable names are too short" or whatever. I find orthodoxies like these just serve to create in/out groups and have no impact on code quality. Or, another way to say this is that if you're building a coherent mental model, your methods are probably the right size.
> Fundamentally, no-one likes working with other people's code or solutions.
I dislike this generalization, as it doesn't go down to the gist: Solutions that adhere to "some" well-known patterns or ways to build things are more likely to be accepted by other fellow developers.
I, personally, can happily work with other people's code or solutions. :)
> no-one likes working with other people's code or solutions
I think there's a frequent cause to this... It's difficult to know the requirements and constraints in place when that code or solution came to be. Many of us would have done something very similar, at least in spirit, under the same conditions. But those conditions constantly change and we tend to judge solutions based on current conditions. Try judging your own solutions by current conditions years after developing them and they sometimes won't look as good as you remember then being. When doing that, it's tempting to think "but x wasn't available and we didn't know y." With other people's solutions, we often lack the knowledge to be aware of those justifications. Investigating to find some of those justifications has helped me better figure out when replacing something is the right or wrong thing to do.
You might, for example, say "Maximise profits. Do not commit fraud". Leaving ethics out of it, you might say "Increase the usability of the website. Do not increase the default font size".