Max Kanat-Alexander

It is tempting to treat technical discussions as fights, but everybody in that room is on the same side as you. They are part of the same group. Your co-workers deserve your respect, kindness, and admiration. And if you grant those, you’ll have more successful discussions anyway.

And: 3. The danger of assigning a software engineer to fix a problem is that they will write software to solve it. (This one is less a law and more a reliable observation that you need to take into account, because more software means more maintenance, etc.)

Facts sometimes missed: 1. Software problems are solved by assigning software engineers to fix them. 2. Software will need maintainers—actual, specific people who actually work on the software—assigned to own it for the duration of its lifetime.

Convenience, not quality, is the driver of technology adoption. Engineers are often baffled why their “better” product fails in the marketplace. It’s because users will always pick the choice that is _most convenient_ for them, not the one that is “best.”

If you don’t feel confident about the design of your solution, it’s probably because you don’t know enough about the problem.

I was somewhat involved in this and it is definitely worth reading.https://twitter.com/TitusWinters/status/1189975357778251776 …

Happy to announce that I am moving to @LinkedIn! Excited about the opportunity to help with developer productivity efforts for the whole company.

Google's internal code review guidelines are now open source! https://google.github.io/eng-practices/ 

Yes, it’s true, “don’t solve problems unless you know they exist.” But you do have to be able to know they exist! There are many ways to do it: tests, monitoring, user research, etc. it does need to be done, though.

Most common things that end up in my talks or Q&A answers: 1. Always refactor in service of a feature. 2. Coverage is a fraught metric. 3. Most complexity is caused by time compression; most time compression comes from a developer’s own mind and not their management.

Successful visionaries look at data (or the real world) to see what is needed and/or wanted and imagine a great solution. Unsuccessful visionaries look _only_ at their own imagination.

In software design, you have to keep in mind that any time you let other developers make a decision about how to use your code, they might make the wrong decision. It is usually best to eliminate places where people have to decide how to use something.

Good developer tools usually remove decisions that developers have to make. Most developers want to focus on making decisions in their domain, not infinite unimportant decisions outside of it.