It’s not just a programming languages that matter in the everyday life of software developers. The English language can be a major source of confusion, misunderstandings and frustration in devops. In particular, there’s one word that, unknown to many a developer, that has become the greatest enemy of the IT community? Need a hint? Take a look at which word is repeated in the following sentences: Just chuck the app on the server We’ll can update that quickly. It’ll just take a minute. Could you just add a Twitter button on the right column? Alarm bells should be ringing when someone uses the word “just”. Why? There are so many problems that may seem easy from the outside, but never really are. You might forgive a marketing director or even QA expert for underestimating a shitstorm lurking behind what looks like “just” another a simple task. But any experienced programmer should know one thing: things are never as simple as they look in IT. It’s rarely a matter of “just” doing it Brad Frost recently wrote about this issue on his blog. When Frost hits a problem while programming, he asks his followers on Twitter for tips and advice. And most of the time he receives an overwhelming response. The crowdsourcing of knowledge can be quite a successful method. However, the word “just” makes a frequent appearance in the responses. “Just update your ruby gems, generate a new SSH key, and run a git rebase...“ “Just clone the dev branch, add those three grunt tasks, and recompile...” “Just use this software/platform/toolkit/methodology...” Feeling somewhat resigned, Brad admits: “Just” makes me feel like an idiot. For anyone to “just” take care of some elaborate task, you’re assuming that person has the knowledge and skills to simply take care of it with their many years of expertise in efficient problem-solving. But as many of us like to forget, this is a big ask. Software engineering is its own universe and no matter how experienced an individual, it’s rare that a person’s knowledge of programming will be general enough to be effectively applied in all cases. Every programmer brings their own cluster of knowledge – while some things are done simply and quickly, others “just” aren’t. Within software teams this can lead to serious problems. If every individual sticks to their own knowledge base, then the shared knowledge pool is too small. Specialising in certain areas is all fine and good, but programmers should really strive towards gaining a broad knowledge so that small tasks can be easily mastered by everyone. Easy, right? The problem with the word “just” is that the listener is led to believe that the problem can be solved quickly and easily. Take for example “just” trying to deploy software on a server. There’s always going to be complications that you can’t anticipate. With other issues such as a library having a wrong version of a local working system and not rescaling to the server, you’re guaranteed to have problems. Anthony Colangelo wrote that the word “just” implies you have gone through all the possibilities and ways to fix a system before reaching that particular solution. It assumes that you can anticipate all problems which may arise in the project and we all know that this is never the case. Just not a good idea So why is the word so dangerous then? It’s not like it’s he who shall not be named. It’s just a word right? Think again. It leads us to false estimates, and leads us to think that a complex problem can be solved in one hour when in reality it will take one week. And if you’re from outside the engineering department and telling a developer to “just” add an extremely complex function to a site, you’re not going to be making yourself any friends. It’s been observed that “Programmers are not lazy, they are just the worst guessers in the world.” If someone starts throwing the word “just” around, you should pull the emergency brakes. In fact, we even think it would be a good idea to install an IoT office device that makes an unpleasant screeching noise when employees use the word. Next time, take a minute to examine what exactly it is that’s being discussed and think over the implicit statements. It might just end up saving you from an unexpected can of worms in the face.