My guiding principles after 20 years of programming (2020)

But what about hooks? These essentially break this point completely. Functions that literally have (side) 'effect' in the name! (useEffect)

Over the past few years, at least on the frontend, I've found in every case what is a class could be expressed in a function or variety of functions. So yeah, still unsure about this point, maybe it was more for other software domains (backend, embedded, etc)

Funny too about what you say about 'grouping functions in some way'... I just made a post about how it makes a lot of sense to put a single function per file... with my organizing, a named folder is the only thing that 'groups' my functions together... so far this style of organization is working well for us.

https://chrisfrewin.medium.com/advanced-code-organization-pa...

Listing Performance as the lowest value bugs me. I understand that most software isn't performance-critical, you can probably afford to use a garbage collected language for most use-cases. But putting performance last contradicts the high priority of Usability in the list, because Usability strongly depends on performance.

Your product might still work if it has a second of lag after every operation, but I won't want to use it. And if there aren't any decent alternatives, I am going to experience irritation and sadness on a continuous basis.

Jonathan Blow said[0] (5 minute interview) that software authors have an ethical responsibility towards their users. How many people use YouTube, or Windows? The time wasted might be small on an individual scale, say a minute a day, but multiply it by a billion people (eg. YouTube or Windows) and that's 16 million man-hours per year.

I'd argue the same responsibility exists just as strongly even if you have one user! Do you want to frustrate her, constantly waste her time? Of course not! She is not going to be very happy with you if you do that :)

[0] Jonathan Blow on Success and Ethics in Software Development https://youtube.com/watch?v=k8gIJOy0c2g

> E.g.: maybe don't output results reliant on a HashSet order - sort them.

I would much prefer shuffling them in that case. Less expensive and reduces the size of the public API. (Returning items in a specific order, whichever it is, still is a sort of promise.)

> And in some parts of the tech world, people actually deride the usage of an IDE! "If you're not using vim you're a newb," kinda deal.

I share the sentiment, but for completely other reasons.

Human mind is very limited - it can only hold so much complexity at once before it starts making mistakes and oversights. IDE's raise that bar of tolerable complexity, making it easier for people to build enterprise-level Rube Goldberg's machines just to keep the software working.

Using Vim (or any other non-IDE editor) forces me to keep the software simple, because otherwise I can't understand it. And in my experience, keeping software simple (long term) is much more important than keeping software working (short term).

Of course, sometimes we have no choice but to meet the deadline. That's where all those bells and whistles really come in handy.

Few problems with this:

> Don’t attach your identity to your code

Others in your team will. Example here is a craftsman taking pride in their work. Think about that the next time you are reviewing someone elses work.

> Security > Reliability > Usability (Accessibility & UX) > Maintainability > Simplicity (Developer experience/DX) > Brevity (code length) > Finance > Performance

Performance is last ? Code length is more important than performance? That's wrong. Also correctness is not mentioned at all surely that has to be in that list.

> Don’t use dependencies unless the cost of importing, maintaining, dealing with their edge cases/bugs and refactoring when they don’t satisfy the needs is significantly less than the code that you own.

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

It's impossible to determine the cost of using a lib using these metrics. I bet this person has had a problem with a dep a few years ago that caused a lot of emotional damage and the response is to never use 3rd party deps where possible. That's not a professional response to what happened it that's the case I'd hope most Staff Engineers don't have this attitude.

> Good code doesn’t need documentation

This is impractical at the end of the day you'll need to have something for the user to lookup for reference.

> Never start coding (making a solution) unless you fully understand the problem

Most devs don't get to decide this they will be told to do X by someone in a large org and given a brief description of why. Refusing to do your work until you fully understand a problem will lead to dismissal.

Some good stuff in there but also some problems.