Lessons from Rework

by Neville Samuell

 I've been doing a fair bit of business travel lately which has inadvertently led to me doing more reading. One of the books I picked up was Rework by Jason Fried and David Heinemeier Hansson. As a long time Ruby on Rails enthusiast and frequent listener of This Week In Startups, I've followed DHH for some time and have always enjoyed his particular take on things.

The book itself is poignant, unique, and a little bit arrogant (of course). It's a collection of essays on a variety of topics and is fairly short; I flew through it over the course of a couple short-haul flights.  I'm not usually one to re-read books, but I've been going back to it more and more lately to review some of my favourite essays.

 

Workaholism

Our culture celebrates the idea of the workaholic. We hear about people burning the midnight oil. They pull all-nighters and sleep at the office. It's considered a badge of honor to kill yourself over a project. No amount of work is too much work.
Not only is this workaholism unnecessary, it's stupid. Working more doesn't mean you care more or get more done. It just means you work more.

This one stood out to me because I think I've always been guilty of this. I've been known to spend hours at the office working on projects, long after the lights have been turned off and the cleaning crew have come around. At the time, I probably felt like I was doing everyone a favour, but looking back now I think Rework is right. I may have helped the project get back on schedule, but by brute forcing the problem I likely created less than optimal solutions. It's something to think about the next time you're throwing fistfuls of late night hours at a project: are you working like this because it's the right thing to do, or because you are trying to be a hero? In some of these cases, I still think it's absolutely justified and the right decision, but I think it has to be something that everyone decides to do; at that point, it's no longer one workaholic blazing ahead, it's a full team sprint to the finish line. In any case, this is something you have to be conscious of and keep under control.

 

Build half a product, not a half-assed product

You can turn a bunch of great ideas into a crappy product real fast by trying to do them all at once... So sacrifice some of your darlings for the greater good. Cut your ambition in half. You're better off with a kick-ass half than a half-assed whole.

This essay is interesting because it doesn't try to validate itself much, the authors expect you to just accept this as fact. I think everyone generally agrees with this advice, but history shows us that people still seem to prefer to "ship more" instead of "polish less". I think it's something you really need to constantly remind yourself of, maybe by framing it on the wall or wearing it on a shirt. I particularly like the wording here, which I will shamelessly quote for years to come to (try and) win arguments about cutting features.

 

Meetings are Toxic

  "Meetings are toxic". Yeah, the illustrations are pretty great, too.

 "Meetings are toxic". Yeah, the illustrations are pretty great, too.

There's some uniquely painful about meetings, isn't there. People experience an certain brand of cognitive dissonance when it comes to meetings: usually, everyone enjoys complains about them ("If I could just get out of all these meetings I could get some work done..."), but at the same time continue calling them at every opportunity ("We should update the team on this, can you go ahead and book a meeting?"). What is that about?

Rework does a good job at highlighting the structural problems with meetings and the underestimated cost they have on productivity. I think that part of the problem comes from a cultural belief that meeting are the only way to "officially" accomplish something, like a decision, an update, etc. But that should mean there's also an opportunity to challenge "meeting culture" by offering a less intrusive alternative and building a culture to support it. Something like a "decision room" on your company chat server could potentially scratch some of the same itches.

 

Reasons to quit

It's easy to put your head down and just work on what you think  needs to be done. It's a lot harder to pull your head up and ask why...
Why are you doing this?  What problem are you solving? Is this actually useful? Are you adding value? Will this change behavior? Is there an easier way? What could you be doing instead? Is it really worth it?

This one plays back into the workaholic idea. There always seems to be lots of reasons to keep going, like "I've already finished most of it", or "This should be really cool when it's finished", but it's important to remember these reasons to quit. There's nothing wrong with throwing out a day's worth of code when you realize that the feature won't end up adding value, so don't keep chasing after something that really wasn't worth doing in the first place. Poker players know how to calculate pot odds to prevent over-investing in a marginal hand; businesses can do the same thing.

 

These are just a few of my favourites. I don't think there's anything completely mind-blowing in there, but the authors do such an excellent job of enumerating a hit-list of topics to focus on that I know I'll be picking it up over and over again.

Building Tech Communities

by Neville Samuell

In his recent article HackerNest builds tech communities, one beer at a time, Anthony Reinhart mentioned that HackerNest events "...enable the kind of messy, spontaneous relationship-building that underpins great startup communities". I couldn't agree more; informal meetups play an important role in building a supportive tech community, but it's hard to describe exactly why. So, what makes events like HackerNest successful? How are supportive tech communities really put together "at ground level"? I've been helping organize events for about a year now and there's a couple things we've found out along the way. 

 HackerNestKW November Tech Social at Vidyard

HackerNestKW November Tech Social at Vidyard

Strangers are Awesome

Instrumental to the core of HackerNest is bringing strangers together over common ground. Having a group of friends or peers to discuss your ideas with is great, but feedback from strangers is incredibly powerful, and shouldn't be overlooked. At HackerNest, we create a friendly, welcoming environment so you can meet some strangers and start hatching schemes. Or just discuss the last movie you saw. Great tech communities are more than just a network of closely connected friends, it's an environment of co-operation where everyone is helping each other, strangers or not.

 HackerNestKW May Tech Social at Communitech

HackerNestKW May Tech Social at Communitech

Free Beer is a Great Excuse

It sounds silly, but a lot of people I know in the tech industry - and probably most industries, to be honest - feel socially discouraged from attending "social" events within their industry. There's somewhat of a stigma among developers that prevents a lot of us from feeling comfortable telling our colleagues we're going to the local Chamber of Commerce networking night, or attending a seminar on C++ Best Practices. HackerNest subverts this by providing the ultimate excuse to explain yourself to that pesky coworker: "I'm just here for the free beer".

Sure, our members typically average around a beer each, which means that's not really what's happening, but your coworker doesn't need to know that, do they?

 HackerNestKW September Tech Social at Treehaus

HackerNestKW September Tech Social at Treehaus

Tech Communities are Everywhere

The truth is, there are fantastic tech companies in pretty much the every urban area worldwide - HackerNest itself is in 12 cities worldwide already. The growing power of remote work means telecommuting tech professionals are probably already living in your neighbourhood, and will only become more common going forward. I often say that today's technology is tomorrow's literacy, which means that more and more of the population will be participating in so-called "knowledge economy". Socials, hack nights, developer meetups, tech talks, dinner series... events like these simply give these existing communities a place to get together, share their experiences, and support each other. We are constantly getting requests to start HackerNest groups in cities around the world, so we're working on ways to enable that. Want to become a local organizer? Email us, and let's get something going. 

Angelhack Toronto

by Neville Samuell

Back in December, I attended Angelhack Toronto along with a couple friends of mine from the University of Waterloo. Together, we built PictureThis, a simple web application designed to let users create silly MadLibs-style stories featuring randomly selected photos of themselves and two of their Facebook friends. I'd never built a complete Rails site before; in fact, the last time I used Rails was probably in my second year of University when I built a semi-functional ranking site for our in-house NHL 08 matches. Needless to say, I was amazed when PictureThis managed to grab an honourable mention from the judges amidst all the incredible entries submitted by the other four hundred or so attendees. I'm looking forward to what the winners (AirPost.io and Raffi) put together for Global Demo Day next week... But I'm getting ahead of myself. What was the event like for a first time hackathoner like mef?

 Angelhack was run by the awesome guys at Hackernest who put on great monthly socials in Toronto

Angelhack was run by the awesome guys at Hackernest who put on great monthly socials in Toronto

The event itself was a blast. For my first hackathon experience, I thought the entire weekend was run exceptionally well even with the enormous turnout. I'd heard a lot of great things about hackathons from friends and colleagues coming into the event, but had always come up with some weak excuse not to attend. This time, however, I had the benefit of an excellent team, a fun idea to run with, and a renewed enthusiasm in picking up Rails, so when I arrived Saturday morning  I was eager to get started.

The first thing I should mention is the location. Angelhack Toronto was held in the Burroughes Building in Queen West, home of the Extreme Startups accelerator. It's a pretty gorgeous open space when it's not full of a bunch of overworked, pungent hackers; there's lots of natural light, exposed beams, etc. It's also in a great area downtown since there's lots of good food & drink nearby (Banh Mi Boys and 416 Snack Bar, for starters). However, that doesn't really help during the event, does it? Thankfully the catering for the event was surprisingly good and there was plenty of free beer.

 This is early on in the competition, but Emma J Logue was running around all night with her camera

This is early on in the competition, but Emma J Logue was running around all night with her camera

With over four hundred attendees split over three different floors, it was clear that not everything was going to work perfectly. The WiFi service ended up being pretty spotty, which made Github pulls a bit slower than normal and caused problems for some of the presentations. I'd made sure to download everything I needed ahead of time (namely Rails and the gems I used for our site) so the slow WiFi didn't end up affecting us much, it was just something we had to plan around, During the final presentation, we had offline backups ready if our connection ended up being too poor to do a live demo, which ended up being the case. When we noticed how long it took just to sign into Facebook during our presentation, we quickly transitioned to our offline pages and carried on (I wonder if anyone even noticed). Other than the spotty WiFi though, I was surprised by how smoothly everything went. I'd like to thank the organizers and volunteers once again for doing a fantastic job controlling the chaos over the weekend.

 The PictureThis landing page

The PictureThis landing page

In terms of development, I was pleased with how the code turned out (you can browse it all on the Github repo), but it certainly didn't happen by accident. I went into the event with a rough design document that described the work flow, data model, and pages ranked by importance. Once the coding started, we divided up the work and within a couple hours had something functional, albeit hideous and a bit clunky. By midnight, we had built out the key pages (landing, story creation, and story view) and everything worked, which meant we had the remaining time to polish the experience and clean up the design. I tend to believe that for every "unit of time" spent on a project, you should be able to finish 90% of the remaining "volume" of work. I call this my 90% Rule, and it has two practical results:

  1. You should always assume that the first 90% takes just as long to finish as the next 9%, so plan accordingly
  2. No matter how long you spend on a project, you can never be 100% finished

This theory has never been published or peer-reviewed so I can't say with confidence that it is universally true, but it's served me pretty well thus far. For this project, it meant we could spend the first half getting 90% of the site built (all the core functionality), and the second half cleaning around the edges and buttering up the design. I feel like controlling scope is something that a lot of the hacks had trouble with, leading to unfinished and unpolished results. For us, when Sunday afternoon rolled around we had polished the product to a point where it worked and looked pretty good (for a first time effort), so we were ready to demo.

 The PictureThis story page. Of course, the picture of the three of us at Angelhack has nothing to do with the story, but that's part of the fun

The PictureThis story page. Of course, the picture of the three of us at Angelhack has nothing to do with the story, but that's part of the fun

Presenting our project in front of a crowd of approximately six hundred people (including ten local industry judges) was a bit nerve wracking. I don't think I've ever presented in front of a crowd that large before. With only two minutes to present, we had to be very economical with our time, so we cobbled together a rough plan:

  • Only use two speakers, to simplify the flow
  • Pick a good opening line to set the tone for the presentation (in our case, it needed to be silly like the product)
  • Spend less than thirty seconds pitching the idea before starting the demo
  • Quickly walk through the three main pages, with offline backups of each page ready in case there are technical problems
  • End the presentation by explaining where the project could grow from here

I'd like to think we nailed all of these things, but truthfully I kind of bungled the finale by trying to sneak in another technical detail (which was completely unnecessary). However, we still delivered on everything else well enough to win the judges over and get an honourable mention along with six or seven other winners.

All in all, Angelhack Toronto was an awesome weekend. If you're thinking about entering a hackathon, I'd highly encourage you to attend the next one that pops up in your area. Just make sure you set realistic goals, come prepared, and enjoy the ride.

Arduino + Android (Part I)

by Neville Samuell

One thing that really bugs me about my Android phone (Nexus S) is the lack of a notification light. Anyone who has worked with me on hardware projects knows I love making LEDs flash... after all, my final university project was basically a giant flashing LED (portable traffic light). So one afternoon I decided to dig out my Arduino and "build what's missing". The plan was to create a simple Arduino program that accepts Bluetooth commands from my Android device to control an LED. Basic stuff, but a good way to dig into some new material, since I've never really touched the Android SDK. With that in mind, I dug out my electronics bag from the closet.

 It's nice to have a bag of random parts lying around

It's nice to have a bag of random parts lying around

For this project, I only need a handful of parts:

  1. Arduino (in this case I'm using my old NG, but new users should try the Uno)
  2. Bluetooth module (I use the RN-41)
  3. LD1117 3.3V linear voltage regulator
  4. Some LEDs, of course
  5. Breadboard, resistors, capacitors, etc.

The Bluetooth module is pretty easy to interface to. Basically, it just needs a 3.3V rail, some logic connections (reset, status), and a serial interface (RX/TX). However, the Arduino works on 5V logic. Therefore, the only trick is generating the 3.3V power and signals. There's a bunch of ways to interface between different voltages, but here are a couple of the best:

  1. Voltage regulators (like the LD1117). These provide a stable voltage even when you add load.
  2. Switches (transistors, relays, etc.). Best option when you need to signal high current loads or use a low-voltage logic signal to drive a high voltage loads.
  3. Resistors. Sometimes you can get away with with just using a simple voltage divider circuit when you need to step down a signal (e.g. from 5V to 3.3V).

Linear voltage regulator powering the Bluetooth module
Linear voltage regulator powering the Bluetooth module

I used a voltage regulator to generate the 3.3V rail for the Bluetooth module, and a resistive voltage divider to step down the Arduino's serial output. The other inputs from the Bluetooth module don't need any conversion, since a 3.3V input will still drive a 5V input (sneaky). After that, we just run a couple LEDs connected to both the Arduino as well as the Bluetooth module's status pin (for debugging), and we're ready to go.

Multimeters are great for debugging electronics, but LEDs can be very useful as well. For example, the RN-41 Bluetooth module has several status pins that indicate things like connectivity, state, etc. I tend to hook everything up when I'm bringing up a new part and once it's working, take away everything but the essentials. This can save a lot of headaches when you miss a pull-up somewhere...

 The finished circuit, with a couple of LEDs ready to go

The finished circuit, with a couple of LEDs ready to go

With everything in place, the only thing left to do (for now) is to power up the board and write a quick Arduino sketch to test the LEDs and make sure we can communicate with our Bluetooth module. Since the RN-41 is controlled with simple commands sent over the serial interface, it's easy to send a couple commands over to check that we connected everything correctly. For the RN-41, we send "$$$" to put the module into configuration mode; if the status LED starts blinking, you know you're in business.

Next time, we'll write the Arduino code that receives commands via Bluetooth to control our notification LED and build a simple Android app to run it.