Confidence

Every time I come home, I put my wallet, keys, and cellphone at a particular location.  Whenever I'm leaving the house, or otherwise need one of them, I know exactly where they are.  The number of frantic searches for keys people who don't do something like this go through is scary, considering how easy it is.

Similarly, every time I work on code, I use version control, and commit working code regularly.  Like the wallet and keys above, looking around for code that you can't find (possibly because there are many copies of the code about) is such an obvious loss that changing your behaviour seems warranted.  If you don't realise it's a loss, hopefully you'll learn when you waste your time a few times doing something else.

You can't be a good developer or systems administrator or, I imagine, a bunch of other roles if you aren't confident.  When you've got version control you can be confident you can go on a tangent and mess the whole thing up and return back to a working state easily enough.  The value of unit tests is often said to lie from the confidence you derive from knowing that mistakes you make while changing code will most often be caught by the tests.

Part of the work I'm doing at SynthaSite is building confidence around the development process.  Each developer has a virtual machine on their system that matches the exact operating system and software configuration as in live.  They use a slightly streamlined deployment process, but they can be quite confident that whatever they develop that works on that virtual machine will work on live.

Just in case, we have another virtual machine that is an almost 100% mirror of the live environment.  Instead of the streamlined process, it has a full deployment process.  The build comes from a continuous integration server with a known configuration - nothing strange depending on which developer built it on which machine.  It has a recent copy of the live environment's variable data - databases, file resources, and so forth.

And, once that's done, you're almost certain that when you deploy the sofware to live that it'll just work.

Pride comes before a fall, though.  Today it went wrong.  I broke live.

The one consolation is that it's because I wasn't following the process exactly.  I tried to be clever.  I should've realised that trying to be clever is a sure-fire sign of the imminent performance of a stupid act.  I suppose one has to be reminded of it every once in a while.

Hopefully a very long while.

Your trust in your colleagues, business partners, or friends is going to allow you to be confident too.  If you know that you've got a safety net - that you can fail and those people will help you out and stand by you - then you can try pretty astounding things.  That's probably going to take a while to rebuild fully, but it's nice that the reaction to the problem was mostly constructive.

One of the worst things you can do to someone is to hold them to a standard that is unrealistic.  People react in two ways.  Some, perhaps most, won't feel up to the task after failure, lowering their confidence in themselves.  Others will lose their confidence in, and respect for, you, since they are confident in their estimation of how big a mistake they've made.

I guess this is why it's important to keep the latter group engaged with their work.  If they're excited by something, proud of it, invested in it, then they're going to regulate themselves well.  They'll consider it a bigger mistake, and will try to avoid doing so in the future.  If they're bored with what they're doing, tired of it, or just don't feel connected to it, then they won't feel all that bad about it, and they're not going to try as hard to avoid making that mistake again.  They're not going to come down on themselves much.  And, just like before, they'll wonder why you're overreacting - except that you and those not in such a lurch will consider it entirely reasonable.

When your colleagues or friends trust and respect you, you just need to apply a subtle amount of disappointment.  If they don't, you can either build those up in the long term with little improvements initially fairly spread out or make things much worse in the medium term in exchange for a few months of not-all-that-much improved performance and reliability.