There are many opinions, here are mine.

opinions.md

Here are my opinions.

Ethics and conduct

1. Developers should adopt a code of ethics. The ACM has a nice example, if you need one.
2. Be kind, always.
3. Bigotry and intolerance of others is not ever OK.
4. In code, people, everything, seek to understand before judging.
5. It's OK to judge, provided you're also kind.
6. It's hard to create good software. Be respectful.
7. It's easy to criticise and tear down. Don't be an arse.
8. There are always smarter people. Don't get a big head.
9. I'm an introvert, but I appreciate the value of networking with peers.
10. Think of writing software for friends and family the same way you think of loaning money. Its OK, but tread carefully.
11. Every programmer should volunteer their expertise to help a good cause at least once in their life.

Tools

1. Visual Studio is the best IDE (though I'm trying out JetBrains Rider, and it's looking pretty good)
2. Visual Studio Code is the second-best IDE and general purpose text editor.
3. Vim for everything else. I've never tried emacs.
4. Always use source control, even for small solo projects.

Languages and code syntax

1. Perl 5 is the coolest language ever.
2. C# is not far behind.
3. JavaScript is OK, at least the best bits are.
4. I tried Java. Didn't like it.
5. Every programmer should know at least basic RegEx syntax.
6. You should never try to parse email addresses or HTML with RegEx.
7. Tabs or spaces are both fine. It's a pointless debate.
8. Don't leave large chunks of commented-out code lying about. It's untidy and needless if you're using source control.
9. Code comments that state the obvious can be deleted. Don't write them in the first place.
10. Code comments that explain why something is so are super useful. Write more of these.

Databases

1. SQL Server is amazing, and keeps getting better every release.
2. Normalisation is widely misunderstood and unfairly demonised. You should normalise your models.
3. For 99% of use-cases, a bog standard relational database is the only correct solution.
4. Yes, even at scale. Tuned indexes are the key.
5. NoSQL has its place, but most places don't need it.

The web

1. Advertising and greed ruins the web.
2. There's so much junk on the web. Don't add more.
3. Everyone should have a personal black list of domains (including both web and email).

Architecture

1. Above all else, think of the maintenance programmer.
2. For production code, limit your choices to mature and well-understood technologies.
3. Don't let your team follow every trend going.
4. With sufficient throughput, improbable things will happen. Always code an ELSE clause.
5. If you don't test the security of your app, the bad people will do it for you.

Economics of software development

1. Technology obsolescence is one good reason for a big re-write. In fact, its almost the only good reason.
2. Successful software will exist 90% of its life in maintenance mode. Consider the burden of maintenance above other concerns.
3. Don't reinvent the wheel. It's usually cheaper to buy software components than to build them yourself.
4. The only exception is when you can and will do it better. But you probably won't.

Teams and team management

1. Diversity is strength. This doesn't mean you have to like everyone.
2. The team is more important than any one individual, unless you're happy to have just that one person as your whole team.
3. The team leader doesn't get things done; the team does. The team leader is there to remove obstacles and set the tone.
4. The team lead's primary job is to facilitate a safe environment so that people can develop their skills without fear.
5. Good communication between team members is probably the most important thing to get right. Don't put obstacles in the way, such as blocking messaging apps or frowning at chatter.
6. The job of a software developer will always involve learning something new. This is both the challenge and the fun of coding.
7. Witch hunts and knee jerk reactions will destroy a team. The team lead should be a buffer for this kind of nonsense.
8. A good team manager will eventually face harsh criticism from those who don't understand software. This might not be something you ever want to face, which is fine, it just means you should refuse to take on a leadership role if offered.
9. Don't agree to do things you know to be wrong. Don't agree to have others do it either.
10. If you're ever forced into a no-win situation, the best advice I can give is to find and talk with a trusted advisor.
11. If you can, don't put up with persistent negative attitudes from anyone.
12. If you're naturally an optimist, don't confuse realism for pessimism.

Estimates

1. A software team will always be asked "how long will this take?" and apart from tiny jobs there is no single best way to answer this, it depends on the environment and the reason for the question being asked.
2. The accuracy of an estimate is a function of many things, and some of these things will always be outside your control. Therefore you should never offer an unqualified promise to deliver at X date or in Y time or effort. This is especially important if you're speaking on behalf of a team.
3. A good estimate takes into account not just requirements but other constraints that may be social, political, and sometimes even emotional.
4. A good estimate is never just a single number representing effort or duration. A good estimate includes an assessment of risk, a degree of certainty, and a list of assumptions.
5. It doesn't matter how many caveats and qualifications you attach to an estimate. Inevitably, someone will ignore those details and try to use your numbers, stripped of all nuance, as a blunt weapon. Prepare for this eventuality.
6. If a manager comes at you wanting to play a game of "I'm thinking of a number" you should excuse yourself at the earliest opportunity and then later put down some thoughts in writing.
7. If you're confronted, yet feeling confident, a good tactic is to say "tell me how long we've got, and I'll tell you what we can do in that time"