I used to waste a lot of time deciding between nearly indistinguishable options. But if an answer is Obviously Correct, then its correctness should be obvious.
If I've weighed all the options and the right answer doesn't stand out, both answers are probably fine. Minor differences between things aren't worth the time and energy it takes to decide. I pick an option and move on.
This applies to everything from the path I take walking my dog each day, to what I eat for lunch.
This is a bit of an extension of the above, but generally, once I've thought through a problem and made a decision based on the information I have at the time, the best course of action is to commit to that solution.
I will gladly change my mind in response to new information or another perspective (although I try to factor those into the original decision), but waffling back and forth out of fear of some unknown-unknown is not productive. Waffles are for breakfast.
This is a meta principle that applies to some other principles.
Software engineering is chaotic. Nearly all software standards, and even some programming languages, are written specifically in an attempt to reduce that complexity. And that's cool.
What isn't cool is all the other processes and patterns we apply (sometimes aggressively) that only appear to reduce complexity. They give us a false sense of security, usually at the expense of social capital and productivity.
It's important, when attempting to gain control over that chaos, that we are:
To compound this, I've noticed that people start to lean on these trappings of control even more when things are hard. When budgets are tight and deadlines are near. This is the worst time to be adding pressure as tension is already high.
Whether it's a software pattern or a team process/methodology, the team should use its own best judgement for how the particulars are applied.
That also applies to these principles. They are strong but not strict and can be molded to fit a situation.
With all the arguments developers have about this pattern and that standard, I believe that, fundamentally, software is for people. Code is not art. It is not abstract. We write software to do things for people, so our users should always be the number one focus.
Purism in engineering violates this fundamental goal. A "perfect" piece of software that doesn't solve a problem for a human is useless.
Similarly, software decisions that don't align with business goals are diversions. Even if they are, in other ways, correct. Obviously this only applies to software in a business context.
I don’t remember where I heard this one, or if I came up with it myself. Also, sorry to be a bit crass but the actual principle here is:
you do not f--- with other people's money
That is to say, there are lots of great coding philosophies that focus on speed and expansion on minute details (eg, “move fast and break things”). I generally subscribe to that philosophy. But when it comes to processing payments, calculating debts and any other concerns where you are managing other people’s money, there is no room for mistakes.
Not even a penny (lookin' at you rounding errors).
The most reliable way I have found to write simple, modular code is to write code I believe will need to be removed soon. Even if that code is never removed, easy-to-remove code is usually shorter, more self-contained and has fewer dependencies.
This not only makes my code cleaner, but it means I can write it faster. Knowing it is easy to remove assuages some of my concerns about criticism.
This mostly applies to PR reviews, but can apply more generally.
As a reviewer, it is my job to point out potential bugs, inquire about potential edge cases and enforce company coding/testing standards that can't be enforced by a linter.
Beyond that, any thoughts I have are merely suggestions.
It's naive to expect that someone who isn't me will do something exactly as I would, and it's arrogant for me to insist they try. Broadly, the responsibility of deciding how work should get done is up to the person doing the work.
While PRs can be a good place for teaching, they are often used incorrectly to establish dominance. This sows discord in the team and almost never leads to better code.
Yes, this principle is in the Management section too!
As a manager, I have to accept that any task I delegate will only be done, at most, 80% of the way I would have done it. Often less. That's the risk of delegation.
But the benefit of delegation is that it frees me up to do my own work. Even if my way is 'correct,' two people working at ~80% productivity is better than one person at 100%. And sacrificing my own productivity to 'fix' someone else's just brings that total number down.
As long as there aren't major problems with it, I welcome interpretation.
95% of the time, interpersonal problems are environmental. Conflict resolution should be a collaborative effort to address and eliminate those environmental problems, so we can all get back on the same page.
This could also be framed as "own your mistakes" but I think the apology is important.
Most projects will have hiccups and missteps. When this happens, I am quick to identify what I have done to contribute to the problem. I apologize, learn from my mistakes, and make a plan to do better in the future
Spending any time worrying about other people's mistakes is a waste; I can only change myself. Interestingly, being forthcoming about my mistakes usually creates a safe-space for others to address theirs.
It's important that I'm genuine about this apology. Apologies cannot be seen as magic words one uses to get what they want. This exercise in honesty and safety builds trust and brings teams closer together.
Honesty is almost always step one on the road to resolution (even if that resolution means parting ways). But just because being honesty can hurt, doesn't mean it should be used as a weapon.
For secure people, feedback will always be positive if it comes from a place of mutual respect.
If I blindly idolize people 'above' me, I undermine my own experience and perspective.
If I blindly dismiss them 'below' me, I deprive myself of everything they could have to teach me.
Regardless of hierarchy, I treat everyone as a person first and a position second.
This helps me form stronger bonds and more open lines of communication, and it's where I get my best work done.
Myself included. This one has a few parts that could be their own principles but the key highlights:
Generally, I just remain open to learning, and treat people with respect.
Competent people are good at what they do.
Invested people care about their work and the company.
Compliant people do what they're asked without resistance.
People are never all three.
If quality isn't important, I might get away with a Yes Man.
If I don't require emotional investment in "the cause", I'll gladly hire some talented clock-watchers.
But if I want good people who care, I need to be okay with a little friction.
The industry is awash with processes and rules about how work should be done and how software should be written.
While they all have their merits, if a process is making people unhappy and is getting in the way of them being and feeling productive, it's gotta change.
Ten people with individual strengths can make up for the others’ weaknesses.
Ten people with no strengths or weaknesses make up for nothing, and excel at nothing.
People like Superman, not Jack of all Trades.
This is a feature, not a bug. I don't always have to completely understand the solution, as long as I'm confident they completely understand the problem.
If I try to force everyone to do everything my way all the time, I become a quality filter where no work can ever be better than it would if I wrote it. And I'm far from perfect.
Communication here (like most places) is key. And, if I'm lucky, I get to learn something. So, that's fun.