Tuesday, February 23, 2016

How (not) to hire - notes on hack.summit()’s session

Pluralsight’s virtual hack.summit() event started yesterday, and I managed to follow most of the sessions. The last session was by Hampton Catlin (“Created Sass, Haml, m.wikipedia.org, and book author") on the topic of “How (not) to Hire”. The session is partially a reflection on the success of past hires, but also the sharing of alternative and (lots of) interesting ideas on how to hire people/developers.

One of ideas I thought was most relevant was that you WILL do bad hires, and that you should face the idea of letting people go as naturally as possible: “It’s your job as a manager”. I’ve had to do it in the past, and it’s not easy, but he’s right. “What are you afraid of when hiring someone? that he’ll bring down the company?” These questions frame the process in a “lighter way”: you don’t have to get it right at first, and should accept that you'll make mistakes. I guess most of us are so cautious when hiring because of the effort/time associated, but also because of the failure itself and being associated with it. I’ve both done bad hires in the past, and also seen the “stigma” associated with it in a colleague, so accepting that mistakes will inevitably happen should be in our minds to avoid this - no mistakes, no learning.

Another relevant insight from the session was the difference between Positive and Negative hiring. In Negative hiring, you try to find problems, reasons NOT to hire. In Positive hiring, you try to find out how awesome someone can be, what are his strong points, how he can make a difference. I bet most of us that hire follow the first approach (me included). He says that he used to follow the “Veto Rule”, whereby if anyone on the team wasn’t convinced the interviewee was awesome, they wouldn’t hire. This is exactly what I did for most of my career, on the footsteps of “Peopleware”’s recommendation to involve the team in the hiring process. An alternative approach, he mentions, is the “Believer Rule”, whereby if anyone on the team is really convinced someone would be awesome, he should be hired. The truth is probably somewhere in the middle, but this a great idea.

Catlin also advocates that you should hire mostly depending on someone's ability to work as a team/collaborate, and not only technical skills – “It’s easier to teach code than it is to teach empathy”. This is true, but I’d say there must also be a technical baseline.

Another idea, and this was to me the most interesting one, was the suggestion that candidates themselves should design their own hiring process, giving them a chance to show off and see their best side. What the candidate chooses is obviously a clue into what his strong and weak points are. I find this idea brilliant, and will keep this in mind for the future.

Another suggestion that he gives is that just discussing technology with candidates is a very effective way of assessing the person, and his/her passion, interest and skill in technology. Asking about some specific project, what they think of Azure vs AWS, or of C# vs Python, etc.

Finally, during the Q&A there was another interesting insight, or framing of the hiring process overall. Some companies (I think I’ve read about Google doing this) try to hire people that are better than the average of the company, constantly “raising the bar”. The insight is this: if you keep doing this, at some moment in time you yourself should NOT be employed at the company! :)

Anyway, lots of good ideas in the session, to keep in mind for the future.

Thursday, February 11, 2016

SIGFOX Makers tour Lisbon

I just spent the afternoon at SIGFOX’s event in Lisbon, learning about the company offering and doing some hands-on demos with an Arduino Uno and SIGFOX’s network.
What is SIGFOX? To be honest, I didn’t exactly know, when I got the Meetup email from Productized about the event. SIGFOX is an telecom operator, exploring a range of radio frequencies and a kind of modulation (UNB – Ultra-Narrow Band) that makes it especially interesting for the IoT world.

Up until today, my only experience with IoT was with the Raspberry Pi, and the code to handle the wifi connectivity in case of failures has given me several headaches. It seems bluetooth, which is more widely used with Arduinos, is also not a simple process, due to the need to pair, for example. SIGFOX’s network promises several advantages in this area: simplicity in sending (and receving messages) from the network is a question of doing a send call – no need to pair, connect, authenticate, etc. There are base stations (much like in GSM) that get the message, de-duplicate it, make it reach SIGFOX’s infrastructure, and either process it there or route it to our own application server via an HTTP call. Another major selling point is the low power usage: the protocol used is designed to maximize energy efficiency and use energy only when needed - essentially, it uses 20-35mA when sending messages, and the chip is supposed to be in standby most of the time, when not communicating – the communications pattern assumes the device polls for incoming commands when required/regularly. A solution using this approach is supposed to have up to have several years of autonomy, supposedly.

This simplicity and low power consumption, clearly major selling points, are offset by some limitations in the range of applications: messages have a payload of 12 bytes (xml and json are out, as are applications regarding media transmission) – this means you’ll be optimizing messages on the bit level; additionally, to comply with european regulations in the usage of the spectrum, you can only send up to 140 messages per day (about one message every 10 minutes), and finally the transmission rate is pretty low: 100 bits/sec – so it pays to keep messages as small as possible. Even with these limitations, it’s pretty clear there is a wide range of applications for this approach – my Raspberry Pi temperature setup uses Wifi and is constantly plugged in, a SIGFOX+Arduino solution would probably just require batteries.

Interestingly, there is already network coverage in Portugal (an in the Netherlands, France and Spain – as well as several other major cities worldwide), and prices are supposed to be very affordable (2€ to 25€/year, if I understood correctly), depending on factors such as usage. In one of the demos, a message sent by the board was picked up by 4 base stations – the workshop was in the city’s downtown.
Snootlab_Akero_ArduinoUno
The platform has mechanisms (callbacks) that can handle requests from the devices, either semi-automatically by parametrizing preset responses (ex: return the current time), or by making HTTP calls to a configured application server on our end. Interestingly, Azure Event Hubs (which I also use in the Raspberry Pi tests) are also natively supported, with the network automatically posting incoming messages from devices into a configured event hub – and the Azure IoT Suite will also be supported.

I thoroughly enjoyed the afternoon in the workshop, and was surprised at how easy it was to use the network and the Arduino. I’d seen demos of Arduino before, and to be honest was not looking forward to be back in coding C, but it was easier than it thought (I still have this book around, from when I learned the language in high school).

As to doubts and issues: IoT security seems to be in the news every day, so this is obviously a concern. I don’t know much on the topic, but device authentication, server authorization, and server authentication in the device seem obvious concerns. The trainer, Nicolas (great job!), didn’t have much time so he didn’t expand on the topic (and I still don’t have the slides with me), but it is a concern I’ll have to explore.

The SIGFOX demos done in the workshop are available on GitHub. The board provided can read the temperature (with a degree resolution), so I might do the exercise of converting my C# code from the Raspberry to run on the Arduino.

PS: I have very basic electricity/electronics know-how, and somehow see myself with a couple of Raspberry’s, now an Arduino, and several sensors, cables and breadboards on the way from AliExpress. What is happening to me? :-)