Software Craftsmanship Saturday vol.84 โ Atlassian Blow-Up, Web Scraping and Recruitment
Today's main treat is the Atlassian crash, but also interesting legal findings from across the big water. And we end the whole thing with a little recruitment guide ๐
1. The great (two-week ๐คฏ) failure of Atlassian - landscape after the battle
We will start with the "favorite" application of all developers, Jira. There is probably no other piece of software, which would be so much hated and so widely used at the same time - at one time some Microsoft solutions would probably compete with it, but over the years the creators of Windows managed to convince the users... Atlassian on average.
That's why right before Easter, the software community (or at least the one that loves a good "drama") pulled out the Popcorn and watched poor Atlassian languish in one of the most embarrassing outages in recent years. For almost two weeks, over 400 Jira customers couldn't access their data or even log in, and Atlassian... took water with their mouths and it took them a week to admit that any outage had happened at all - while the first reports came in as early as April 4, the first official announcement to the affected users didn't come until April 12, and even that doesn't really explain what happened and most of the message is the standard "our primary goal is to get customers operational again".ย
Despite such beautifully placed priorities, the whole thing dragged on until April 18, when the problem was finally supposedly resolved... although I'm still waiting for some meaningful post-mortem because I have a feeling we'll be able to learn a lot from it.
An interesting side effect of all this confusion is the appearance in the technology blogosphere (anyone else using this term besides me in 2022?) of a text from a rare genre... journalistic investigation. Well, the widely known Gergely Orosz from The Pragmatic Engineer blog took it upon himself to publicize the issue and follow it day by day even before Atlassian admitted that it has a problem, thanks to which the whole thing got a lot of attention from the industry.
Of course, failures happen to absolutely everyone, but Atlassian is one of those companies that have their own "psychophiles" who collect all the flaws in their software with apothecary precision. Just a glance at the linked list shows that there are many reasons to dislike Jira, but certainly one of the most prominent reasons is its excessive complexity and poor performance. An indirect reason for both is that the Atlassian software is just incredibly customizable, which of course is not for free - every abstraction costs money. Therefore, in order to get to know the "enemy" better, I recommend you to read a brand new case study on what the process of "linking" requests looks like from the architectural side. You will learn from it how extremely flexible Jiro's model is and you might be able to preview some interesting solutions for yourself - if only to avoid falling into the same traps.
Sources
2. Scraping public data deemed legal
... at least in the United States. Itโs not the first time, but it's such a controversial case that I note the value in bringing up this recent court ruling.ย
The case in question is a couple of years old now and was brought by LinkedIn against Hiq Labs, a company that uses public data to analyze employee churn. LinkedIn didn't like it and, citing the fact that the bulk download of LinkedIn user profiles was in violation of its terms of service, constituted... hacking. Yes, it sounds truly bizarre, but that's exactly what the original allegations were.
LinkedIn first lost its case against Hiq in 2019. That's when the court ruled that the CFAA (Computer Fraud and Abuse Act), the U.S. law that defines crimes related to the illegal acquisition of electronic data, does not prohibit anyone from acquiring data that is publicly available. LinkedIn appealed, of course, the court again upheld its original statement, and so you have the opportunity to read about it in our edition today. Despite the unfavorable verdict, LinkedIn says it will not give up, as it must take care of the candidates' data that has been entrusted to them in trust.ย
To sum up the topic, I decided to take a look at the legal situation in the European Union. The topic was heavily debated when Copilot appeared - a post by Julia Reda from the European Pirate Party, a licensing specialist, appeared then. In the post, Julia Reda, a licensing specialist from the European Pirate Party, argues that under European law, Copilot did not actually violate the law or license provisions. So in general web scraping of public data seems to be cool... unless it concerns personal data (which is a bit like it was in the case of LinkedIn) because then the GDPR comes in with all its blessings and the matter gets very complicated.
3. Should we have job candidates read the code instead of writing it?
What are your techniques when it comes to finding those true "pearls" you want to work with?ย
There are many recruiting methods and everyone has their favorites, but today I'm going to share the text How to Freaking Find Great Developers By Having Them Read Code, which gained a lot of popularity on Reddit last week.ย
It suggests that, in fact, instead of making people write code, we should give them code to... read actively (in the sense - in an IDE). According to the authors, this has many advantages. For example, it is much faster - almost immediately as a recruiter we can start a dialogue with a potential candidate, which will allow us to learn about his preferences. It also turns out that it eliminates a lot of stress from the whole process - a lot of people feel uncomfortable when someone looks at their hands. From my perspective, however, the most important thing is that such a process allows us to check from the very beginning how the person handles more advanced abstractions - the tasks in which the candidate has to write something have to be simplified. Interestingly, this coincides quite well with research recently analyzed by It Never Works at Theory (a website looking at the academic papers on how software is produced), so I encourage you to read it all the more.
Well, as we have talked about how to discover good candidates, I will also have something if you are sitting on the other side of the recruiting table. Today's marketplace makes recruiting a two-way "beauty contest" - and it's really just as much the company recruiting the candidate as the candidate recruiting the company. That's why I recommend you take a look at the short guide 3 Interview Questions to Spot "Fake Agile" Software Engineering Teams. The questions proposed in it are very specific and are kind of traps that are really hard for a recruiter to escape from in a convincing way.
And we started with Orosz, so we will end with him as well. Last week, on his extremely popular blog, a great checklist of what should (or should not) be included in a job advertisement tempting programmers appeared. As in the previous texts from this section, you won't find there any Holy Grail, which will make you not be able to chase away candidates, but it's certainly a list that should be followed when designing ads.
And just to wrap up this section (and editions in general), two more of my beloved classics from The Pragmatic Engineer - Reverse Interviewing Your Future Manager and Team and Preparing for the Systems Design and Coding Interview. I hope you will find them useful the next time you are looking for a job. And I absolutely don't encourage you to change your job or anything - I don't want to get blacklisted by the corporate firewalls (it's enough that I've already given HR a hard time with this edition).
Loved the suggestion about having candidates read the code as opposed to writing it. Thanks for sharing!!