Day 2 of WeAreDevelopers: from AI to being an efficient developer

The second day of the conference started for me with Eileen Uchitelle’s (GitHub) inspirational talk on contributing to open source, even if this makes you vulnerable. And by vulnerability she meant that any line of code that you commit to an open source repository will invariably get broken down into pieces and analyzed by other coders, who might have different ideas on doing the same thing and who will write this out in the open, challenging your work. Which you probably did weekends instead of watching TV series or hanging out with your friends anyways. Good point, I say. Eileen gave mane examples from her experience on the Rails project (look for @eileencodes). Main points:

• any open source project out there has Users, Contributors and Maintainers. Users are the highest percentage in the project related people, contributors are users turned into contributors (many times because while using the code they find a problem and solve it), and maintainers are the least, but so important for the long term success
• in order to be successful, such a project should be able to provide help (by means of mentoring, pairing, etc.), should provide a clear guideline (like predefined bug reports, scripts automating stuff), should use a general healthy tone of conversation (if one rejects somebody’s pull request one should write the reasons as well, etc.)
• one must learn to accept rejection
• and ideally no pull requests should ever be analyzed before coffee :)

My next choice had my entire focus due to the presentation name: “Security by obscurity”, by professor Sebastian Schrittwieser. And it delivered a great combination of fun and “did they really do that?!” moments. It gave precise examples of past security issues from well known apps like WhatsApp, Tinder and others, with the mention that they are all fixed by now. For some years already, so no worries.

• one could exploit WhatsApp to change status messages of other people simply by sending the right GET parameters, or register any phone number due to how the registration code was being generated (on the phone, then sent to the server and then sent back using SMS)
• Tinder was sending precise latitude and longitude data of other connections from the server to the mobile apps, so that these could calculate the distance between you and your connection. Later they changed to sending this distance directly from the server … but with fifteen decimal places. Cool, right? With some triangulation one could find the exact latitude and longitude again. There was a nice slide there and the professor said something like “Oh, I see you are all checking your phones right now”

I especially liked Tereza Iofciu’s (Mytaxi) talk on Data science. Mytaxi runs AI algorithms to determine demand at certain times in certain places. The speaker gave us the message that machine learning is not the biggest deal: you find it in libraries, you apply it, but what matters more is how you prepare your data before training and how you adjust the algorithms based on the results and error rate.

• she presented concepts like data splitting, bias error, variance, accuracy etc. by means of the Random forest example
• she gave a funny example with Hamburg at 3 am (heat map) … where you can easily predict you’ll find douzins of drunk people looking for a ride home
• she recommended the book Weapons of Math Destruction, which she said is “for normal beings”. I’ll have to grab it myself, the name is just too good

Mars Julian (Netflix) talked about “hustling” one’s codebase and she used clear steps alongside a very nice example: playing pool. And as I play pool, I was totally buying it. The key points were that you have to first choose your lineup, then walk around the table (understand the context, see different perspectives), then find your way out (choose an optimal solution), then take the shot (implement). And when you miss … it’s refactoring time! She insisted on always:

• analyzing the context, having a good overview before taking action, and
• breaking actions into smaller steps which are easier to plan and manage

The talk called “Habits of efficient developers”, by Daniel Lebrero (Avko), created such interest that not only was the main room full, but also the first alternative room for live streaming … meaning a second room for live streaming had to be set up on the fly. This surely shows that the conference was either full of devs (doh), or that self-learning is in highest demand. Since I really enjoyed this talk and I find it so useful, I’ll clone the presenter’s structure briefly below.

1. Focus. No interruptions

- disable all notifications — you should choose when to check the mail etc., not the other way around; wear your headphones when you don’t want distractions; or even have a dedicated team lead ready to swipe away any unrequested incoming contact
- do pair programming — that will enforce focus for both coders
- do one thing at a time (multitasking = screwing up several things at once)

2. Master you IDE

- functionality
- shortcuts
- again, when doing pair programming you will notice how others are using the IDE to work efficiently

3. No menial work

- automate tasks, even personal ones
- with BASH — which is like the one technological constant since 18 years :)
- GUI’s may help at first but they don’t allow automation — avoid them where possible
- automate testing
- have a repeatable developer environment

4. Fast feedback

- test driven development: test > code > refactor; again
- use REPL (Read–Eval–Print Loop) to quickly test pieces of code in a browser or somewhere
- code reviews both check code and share knowledge

You’ll find my article on the whole event here.