4 ms·

1. Don't take anything personally. 2. Always remain calm and patient. 3. When people make bad decisions against your strong advice don't feel the need to make

1. Don't take anything personally. 2. Always remain calm and patient. 3. When people make bad decisions against your strong advice don't feel the need to make their bad decisions a success. 4. Don't own the failure of people who don't understand software development. You'll always be doing the best you can with what you're given. 5. You'll be remembered for your grace and professionalism. 6. Never tell a lie. Never get hand wavy. 7. Never use the word "should". Normative speech has no place in software development. It will embarrass you. 8. Always protect your team from the bullshit that rolls down hill. They'll notice. Then one day when you have to ask them to do something ridiculous they'll know you fought like hell before you had to bring it to them. 9 & 10. This goes without saying but don't write checks (make commitments) you can't cash. Projects will succeed or fail no matter how easy or hard they look at the outset.

jurgenwerk 10y ago
Excelent list. Can you describe the "Never use the word should" a bit more in depth and give some examples?
- ab1243 10y ago
  Sometimes it's appropriate to use "should," such as "We should implement some kind of user authentication." Other times, you'll hear someone say that their idea is the way it "should" (when they mean "must") be done, without regard to drawbacks, benefits, long term costs, or the need to treat their coworkers with respect. "This should be done this way! Your way is just wrong." That kind of thing happens on some teams. Sometimes, they're right. The other way is just wrong. Some other times, it's jerk driven development.
- ryanmarsh 10y ago
  Normative speech (often using the word "should") means "I have reason to believe". "Reason" usually being based on some a priori[0] knowledge. "we should be able to do x with y" "y should just work" "users should be able to k" In a problem space such as software, where extreme complexity bordering on chaos is the norm, we we see little evidence supporting common claims of an expected outcome given reason from some fashion of first principles. "Rails should work just fine for this", given some principles about Rails. The problem with the above statement is that you cannot possibly take into account the entire complexity of the final implementation of the appropriate solution beyond the most trivial example. Marsh's first law of software: The complete behavior of any sufficiently useful computer program cannot be reasoned about by a human in polynomial time.[1] Should is a smell. The only should I trust is a passing test. Sorry if that's clear as mud. I've been working to come up with a good explanation for my "normative speech has no place in software" axiom and I'm not sure I've nailed it quite yet. 0: From Wikipedia: A priori knowledge is independent of experience, as with mathematics (3,000 + 2,000 = 5,000), tautologies ("All bachelors are unmarried"), and deduction from pure reason (e.g., ontological proofs). 1: Yes I'm referencing my own made up law. Prove it wrong.

jurgenwerk 10y ago

Excelent list. Can you describe the "Never use the word should" a bit more in depth and give some examples?

ab1243 10y ago
Sometimes it's appropriate to use "should," such as "We should implement some kind of user authentication." Other times, you'll hear someone say that their idea is the way it "should" (when they mean "must") be done, without regard to drawbacks, benefits, long term costs, or the need to treat their coworkers with respect. "This should be done this way! Your way is just wrong." That kind of thing happens on some teams. Sometimes, they're right. The other way is just wrong. Some other times, it's jerk driven development.
ryanmarsh 10y ago
Normative speech (often using the word "should") means "I have reason to believe". "Reason" usually being based on some a priori[0] knowledge. "we should be able to do x with y" "y should just work" "users should be able to k" In a problem space such as software, where extreme complexity bordering on chaos is the norm, we we see little evidence supporting common claims of an expected outcome given reason from some fashion of first principles. "Rails should work just fine for this", given some principles about Rails. The problem with the above statement is that you cannot possibly take into account the entire complexity of the final implementation of the appropriate solution beyond the most trivial example. Marsh's first law of software: The complete behavior of any sufficiently useful computer program cannot be reasoned about by a human in polynomial time.[1] Should is a smell. The only should I trust is a passing test. Sorry if that's clear as mud. I've been working to come up with a good explanation for my "normative speech has no place in software" axiom and I'm not sure I've nailed it quite yet. 0: From Wikipedia: A priori knowledge is independent of experience, as with mathematics (3,000 + 2,000 = 5,000), tautologies ("All bachelors are unmarried"), and deduction from pure reason (e.g., ontological proofs). 1: Yes I'm referencing my own made up law. Prove it wrong.