You might want to be working but sometimes it’s not possible.\nLet’s think about why it might be and what to do about it.\nI have a feeling that this post could also be titled “Avoid single point of failure”.<\/p>\n\n\n\n
People get ill. It’s going to happen sometimes. This is obviously a problem on some level for the person involved. Hopefully they get better soon. Does their work need to get done in the meantime? As a software engineer things aren’t normally time critical, a day or two often isn’t going to make much of a difference. That’s going to slow things down slightly but shouldn’t be too bad. If it’s longer, a week or more, then it might start to impact schedules.<\/p>\n\n\n\n
What’s more serious is when the work does<\/em> still need to be done.\nMaybe you’re managing a team and the next sprint hasn’t been planned.\nMaybe you have the passwords for the server that someone really needs to access.\nIf you’re a bit snuffly it might not be too<\/em> bad to check your messages and\ndo a bit of scheduling.\nIf you’re coughing up blood then you really shouldn’t have to bother with that.\nIn either case it’s better if the the team is able to cope with someone being ill:<\/p>\n\n\n\n All of the above also applies to holidays.\nThey’re going to happen and it shouldn’t stop normal activity from happening.\nPeople deserve to be able to take a break and\nshouldn’t have to keep an eye on the office while they’re away.\nThink of it as practice for them being ill.<\/p>\n\n\n\n When I started working this wasn’t so much of a problem.\nYou had computer in front of you and that’s all you really<\/em> needed.\nNo so any more.\nOn a given day I’m using source control to access and change code,\npackage management systems to build libraries,\nsearch engines to look up documentation and advice,\nproject management systems for tasks and\nyour end product could be running in the cloud.\nIf any one of these goes down you might be able to limp on for a bit,\nyou might not.<\/p>\n\n\n\n Some of these are pretty hard to deal with.\nI’ll have a copy of the code locally.\nI might not be able to check in any commits to the server but I can still prepare them.\nAll the rest might turn into blockers for me.<\/p>\n\n\n\n If you’ve got a build system to make external libraries hopefully it’s cached a copy of the download.\nI had a situation recently where one of the host site of one dependency was down for maintenance.\nIt was cached locally on my machine but not on the build server.\nThe easiest solution was just to delay the merge until the site was back up.\nThat’s fine if you have time but terrible if you don’t.\nTry to avoid a build system that has<\/em> to connect to the internet.<\/p>\n\n\n\n Being cut off from search engines seems very punishing nowadays.\nUnless you’re dealing with a familiar topic it seems to be part of the bread and butter of development.\nI mean, you know roughly how the API work but details matter.\nHowever, if I’m looking up C++ language details then 90% of the time it’s from\ncppreference.com<\/a>.\nI could actually\ndownload the entire reference<\/a> and\nfollow the links manually.\nIt’s still a step down from typing into a search box and just getting the right page.<\/p>\n\n\n\n If your services live in the cloud and\nonly in the cloud then… you’ll have to find something else to do.<\/p>\n\n\n\n While external services are more relevant now you’ve always needed a working machine and local network.\nOver the years I’ve had hard drives fail, networks go down and machines lock up.\nWhat to do and how to prevent it very much depends on on the specifics.<\/p>\n\n\n\n Hopefully you use source control and check in regularly.\nI talked about the problem of\nsource control having multiple jobs<\/a>.\nIt’s not uncommon for me to have experimental branches living locally on my machine for a long time.\nThey’re don’t feel in the right state to share.\nHowever that’s a risk and running a separate backup system would help mitigate that.<\/p>\n\n\n\n\n
Services<\/h2>\n\n\n\n
IT issues<\/h2>\n\n\n\n