It doesn't have to be one sentence but try to be concise. Something you'd end a code review comment with or mention to a Jr dev that's easy to remember.
Today I realized "there's a fine line between credit and blame" but that's a little too pessimistic to be real advice.
Sometimes in the corporate life, you imagine that X would like to have Y, and you put in a lot of effort to make Y happen. And then X is not even aware that Y took effort, or worse, you misinterpreted, and X is annoyed that Y happened. Better make sure that X really wants Y and asks for it.
It has been my experience that to change anything with an organisation takes a while. First you present your proposed change or new process. No one understands or pay attention. Once you implement and showcase the new process, expect objections as it dawns on people they might have to change how they do things. Don't take offense at the objections (which should have been aired at first meeting but no one was paying attention). Just agree to note them and then a week later present same thing you presented. Now you will find most people have processed the change and might even have tried new process or read the documentation. Now the change begins. It's a process.
Meaning that you should strive to program so as to encode the structure, relationships, and qualities of the objects of your task/domain. If you do it faithfully, then your code will be logically consistent and bug-free. I think this is most directly possible in declarative programming.
Life does not always make sense, sometimes best efforts and best preparation fail. That is okay
"It is possible to commit no mistakes and still lose. That is not a weakness. That is life."
This is in some ways depressing, but its always been true for me. Individual actions that are outside the realm of someones common patterns are extremely rare. So if they act in a certain way, expect that going forwards. Be cynical.
(backups encrypted with a key no one has access to are not a backup)
Two is one. One is none.
1. Make it work, then make it work well
2. The user doesn’t give a shit how it’s made
3. If you can’t measure it you can’t improve it
4. The problem is more important than the solution
5. Write code that is easy to delete
6. Buy right buy once