Impressions of WeAreDevelopers 2018 - Day III
This is the last post in a three part series about We Are Developers. This one is about day three. Check out the previous posts to learn more about what happened on day one and two.
The last day was full of talks that I was especially looking forward to. Not only was I excited about seeing Joel Spolsky talk again but there also were a lot of talks addressing testing. Which is, as they say, right up my alley. So, one could say friday was about testing, testing, testing. With some other topics here and there.
Coding and Creativity in Education with Thomas Bachem, Kathleen Mullaney, Micael Holmström and Marwa El Houasli
Moderated by Robert Axelsen this panel discussion focused on coding and education. Before getting to the meat of it, the participants briefly talked about their background. What was noticeable was that all of them lacked background in traditional education in regard to coding. For example, Kathleen started as a biologist (if I remember right) but soon noticed that she would have to learn coding in order to grow her career. The other participants told similar stories.
The deficits of traditional education were a recurring theme. Thomas noted that many universities and colleges fail to teach creativity and interdisciplinary thinking and instead focus on theory. Kathleen noted that this often leads to people finishing their education but not being able to land jobs because the stuff they were told is outdated or irrelevant.
One topic that also repeatedly popped up was diversity in tech education. Micael said something that I really liked: It is not only that focusing on diversity is the right thing to do from a humanistic perspective, but also the logical thing. The industry has a severe lack of programmers so it is clear that we must give as many people as possible the opportunity to learn to code.
Micael also noted that in general diverse teams perform better, and that diversity means not only diversity of gender, but also of experience. One example to highlight why this diversity is relevant was that of a truck driver. A truck driver that taught herself coding might not be the best coder, but she will have experiences that will make her invaluable when developing, for example, logistic applications. Kathleen noted that people that did not start their career in tech and are self-taught usually have high grit, which means they stick with their self-chosen profession for a long time, so that is also something we should be aware of when considering traditional education vs. self-taught.
Marwai added that providing opportunities is often a matter of providing information. Many women and girls are immensely talented but have no opportunity to do what they are good at because they have no way of knowing how. This is one of the reasons why Marwa founded Inspire Her, a non-profit that aims “to #inform and #guide girls to choose the right education and #inspire them to pick a big career in tech”.
When asked who they would pick when they had to hire somebody, a self-taught coder or someone with a degree, all panel members answered that the optimum is having both. Good to know :)
End to End Testing in the Future by Gleb Bahmutov
Gleb started his talk by explaining some basics of testing, for example the testing pyramid. He noted that the testing pyramid usually looks like it does because it is heard to do E2E tests.
He then focused on problems with existing E2E testing solutions, specifically pointing out Selenium, headless solutions and Chrome Puppeteer. According to Gleb the solution to some problems of those tools is provided by Cypress. Cypress is a E2E testing tool that comes with many interesting features, which Gleb showed off. What made it interesting for me is that its free for all public projects, so I’ll be sure to check it out.
The talk concluded with some new features of Cypress that we can look forward to, as well as some features that will probably take a while to be developed. I want to specifically point out smart snapshots, which would be records of previous test executions that would make it much easier to pinpoint why the current test failed. Sounds truly awesome.
Unfortunately Gleb did not talk about any trends within the industry at large. This talk could have also been called “Cypress in the Future”, but I digress. All in all, I had a good time learning about Cypress. Gleb is a pretty good speaker, and although I usually detest talks that double as sales presentations I quite enjoyed this one.
Testing in an Artifical World by Angie Jones
Another talk that I was really looking forward to on Friday. Good thing I got to watch it, because it was awesome. I told a lot of people about this one already because it left such a lasting impression. You can check out Angie’s Keynote with the same title here.
Anyways, what was this talk all about? Angie recounted a story of how she tested a recommendation system. Think the netflix start page: You get some suggestions of what to watch based on what you previously watched. How do you verify if the suggestions are correct? A very interesting question indeed.
The specific ML component Angie centered her talk around was one that provides customers with product suggestions based on what they previously bought. Angie noted that the main problem when trying to test this component is the lack of a clearly specified input/output pair. Traditional tests have a clearly specified input and a clearly specified output. Otherwise, they are not tests, or at least not any good ones. Here, there is no clear input or output. The recommendations that a user gets depend on many factors, and will be different every time.
Angie resorted to what she called the POCS method: Plain Old Common Sense.
In reality this means: Let the ML component learn from many users (which are simulated) and then test it by throwing another huge pile of users at it. See if the suggestions it provides make sense. In Angie’s case this approach promptly revealed a bug, which lead her to the question of how to compose a bug report. Because the test itself was extremely complicated the bug report was pretty lengthy and it was hard to convince people that there was something wrong with the system.
After recounting this story, Angie focused on some problems that arise when we don’t test our AIs. Those are the same problems that occur when you don’t test “normal” software: It breaks. While this may be fine if you get bad recommendations (although, your business will lose money), it’s certainly not fine if we think about self driving cars.
This led Angie to recount the trolley problem and generally talk a bit about computer ethics. She concluded her talk by noting that “as our technology evolves so must our testing approaches”. Some words to live by.
What Makes a Good Engineering Culture by Natalie Korotaeva
This was a very short talk in which Natalie discussed what engineering culture really means and why it is important.
According to her culture is “what people do when no one is looking” or “how things get done around here” (not to be confused with “how we do things around here”!). Natalie then briefly outlined the 6 values of good engineering culture and how to figure out if your culture is broken.
Finally, she talked about what to do once you do figure out that it is broken: Start with yourself, then your team, build success, recruit others and grow bottom up. I was pretty sad that the talk was over so quickly, could have listened for a lot longer.
Architects in a Modern Team by Pat Kua
Pat started by stating that being an Architect is a role that you might not be ready for, but can always grow into. He described what Architecture is, namely the art of understanding how hard it is to change certain parts of your application. An architect then is someone that is responsible for architecture (duh). Amongst the qualities that a good architect should possess are the ability to lead and being a developer as well as being system focused. It also helps to be a strong communicator.
There is no single right way to be a good architect, according to Pat. The best way to improve in that area is to first do a self rating in regard to desirable qualities, pick 2-3 areas which you want to improve in and then focus on those.
There was a lot more content, which I forgot to take notes of, so be sure to check out the recording of this talk when it comes out, its really worth it.
Visual Regression Testing by Viv Richards
Viv took gave us an in depth explanation of UI testing and its caveats. We all know that UI testing requires quite a bit of investment, which is why it sits cosily on top of the testing pyramid. Despite that, people often tend to overuse it, forgoing integration tests. That usually transforms the testing pyramid into a testing hourglass. This of course is an anti-pattern, as Viv explained. Too many UI tests make your test suite fragile, and nobody likes a fragile test suite.
Of course UI tests, and specifically visual regression tests, are necessary. Sometimes you simply need to know if the things you built look right, and visual regression tests check just that. Viv gave us some examples where visual tests would fail if important UI elements were missing or not rendered properly.
The effort of executing visual regression tests can be minimized using automation, but automation itself is quite the time investment. As Viv pointed out, this is a bit of a catch 22. You don’t have time because you don’t automate. And you don’t automate because you have no time.
Continuing along those lines, Viv explained how you may use certain tools, for example Selenium, to do visual regression tests. He also mentioned: You must not forget that doing UI tests is no silver bullet; You will always need lower level tests such as unit tests as well.
I found it interesting that Viv’s talk took quite an opposite position to the one given by Gleb Bahmutov earlier that day. That in itself was interesting, and I learned some new things listening to Viv.
Joel on Software by Joel Spolsky
I discussed going to this talk with one of my friends earlier that day, and they asked me who Joel Spolsky is. To be fair, I probably wouldn’t have known if I hadn’t already seen him the year before. I explained that, well, he’s the founder of this thing called Stackoverflow, which you probably heard of, but I might just as well have told them that Joel is a world-class comedian. Because this talk was as much about Stackoverflow as it was cabaret.
Joel entered the stage with some cards which he had prepared in advance, containing some jokes to lighten the mood (which worked nicely). He told a hilarious story about Steve Wozniak, who supposedly keeps some stickers with him when he goes on a flight. Those stickers say “Do not flush over cities” and he likes to put them on toilets. Supposedly. I would love to get the chance to ask him about that some day.
There was a bit of time spent talking about Stackoverflow, and how contributing questions and answers will have a lot of impact on other people. Joel talked a bit about the platforms most prolific contributor, John Skeet. He told some more jokes (“John Skeet can divide by Zero”), and recounted some anecdotes. For example: If you take into account the number of developers on Stackoverflow, and the amount of time that each answer to a question saves each of them, you can calculate that John Skeet single handedly saved the entire world 5 hours. Which basically means he moved the world 5 hours into the future. Good stuff.
Joel finally got a bit more serious when talking about Stackoverflow Teams, their new product, and Stackoverflow Documentation, their discontinued attempt to leverage the Stackoverflow network to create documentation. Like many other speakers he addressed the importance of diversity in the industry, and how imperative it is to not scare people away when answering questions on Stackoverflow. Although he did not put it this way: We should try to help each other and not be a couple of a**holes.
A truly fitting end to this conference.
I really do hope I will be able to join WeAreDevelopers in 2019, because meeting so many people and hearing so many great talks was truly inspirational. I had a great time reflecting on those three days while summing everything up for these posts. Finally, here is the link to the WeAreDevelopers Youtube just so can also check out some talks I wrote about.