Monday, 10 November 2014

Health Hack 2014

I participated in the inaugural HealthHack in 2013 (my thoughts on that are here), and I was so impressed with the event that I signed up again this year. The format was very similar to last year's event, except that it was simultaneously held in both Melbourne and Sydney.

Friday Night

I (and many other volunteers) listened to the researchers pitch their ideas. My first impressions of the problems and their descriptions was less than stellar. I'm embarrassed to admit, I seriously considered calling it quits on Friday night and not joining a team. My views ranged from "there is no way I can add value to that team", to "what are they even trying to solve?", I was tired, and possibly a little intimidated by the amount of energy that everyone else had. But I was there, and I had been really looking forward to the event, so I went around the room listening to the researchers and asking questions that could give me a better understanding of how solving their problem would help the field of medical research, and whether or not my skills and knowledge would be useful.

In the end, I found @MVEG001's problem around the transparency of NHMRC funding to be the one that I could provide the most value on, and I placed my name on the team list and went home for the night with some links to the data sources that our team would most likely be basing our solution(s) upon.

Saturday

We had a reasonably late start on Saturday, with the team coming together a little after 10. By this time, many of the other teams were already flat out coding, or had some very detailed flow diagrams that they were having animated discussions about.

Shortly after gathering together for the first time as a team, it was announced that the midway showcase would be at 4:30pm. Considering we had only just met each other, I was a little anxious about what we would have ready by that time!

We spent all of the morning getting a handle on all the data that was available, then gathered together to dream about the data that we wish we had, and finally culled all the options back to those pieces of data that were relevant and achievable in the timeframe that we had. @IrithWilliams did a great job of keeping the group creative and focused, and also ensured that we were going to implement a solution that would solve the most important problems for @MVEG001.

It was a little after 2pm when we started on the implementation. @sritchie73 had the first cut of the data cleansing done in about an hour, which was quite impressive, and this allowed the rest of us to start plugging real data into our visualisations.

By the time the showcase came around, we had a solid understanding of the problem we were trying to solve, and how we were going to solve it. 

I ended up leaving at about 9pm, and when I got home I got a little carried away and worked on the backend processing for my visualisation until 12am. 

Sunday

We were all working hard on our visualisations for most of Sunday morning. When lunch time came around, we provided feedback on the different visualisations, and put some finishing touches on them. Somewhere in the middle of that @kiwintessential managed to expand our cleaned data set by another 9 years.

The afternoon was spent putting all our solutions together into one location, setting a licence, choosing colour palettes, and generally tidying things up. In addition, @fredmichna organised us all well enough to produce a video for our showcase. Unfortunately, we had a lot of trouble getting the iPad to play nice with the AppleTV, and we had to do our showcase the old fashioned way.

The team showcases were impressive, every team had delivered a huge amount in that short timeframe, and from what I could tell, every researcher was extremely happy with what their team had helped them deliver. 

Closing Thoughts

Once again, @sauramaia and her army of helpers put together a great weekend. I left feeling that our team had made a difference and made @MVEG001's life that little bit better. I was also pretty exhausted, but in a good way.

For those that are interested, here is our team page, and here is the list of winners for Melbourne.

Monday, 15 September 2014

The First Bad Day Without a Car

Last Friday night we had our first bad experience without a car. It wasn't that bad really, but what would have been a 30 minute trip home from my parents' house wound up taking nearly one and a half hours.

It all started with one late bus. Because it had been a big day, and the girls were tired, we decided to catch the bus the 1km to the train station to ease the load on their little legs. If the bus was on time, we would have had 5 minutes to spare at the train station until the next train rocked up. Unfortunately we missed the train by a couple of minutes, and had to wait 25 minutes for the next one.

This train left the station at just past 8pm, and we assumed that it was stopping all stations, unfortunately, we assumed wrong, and the train stopped at all stations until it arrived at Camberwell, at which point it ran express all the way to Richmond.

In the end, we ended up getting home at 9pm, after having left my parents house to wait for the bus at a little before 7:30pm.

We are not going to be put off by one bad experience, but this was one occasion where having a car would have been significantly more convenient than waiting around in the cold for public transport to link up effectively.

Thursday, 31 July 2014

Living Without a Car

If you had have asked me 10 years ago if I could live without a car, I would have looked at you as if you were crazy. I grew up on a farm nearly 2 hours from Melbourne and having a car was a necessity for a social life. I also remember loving driving, but thinking back on it, I think I loved the freedom that driving gave me, not the driving itself.

Fast forward to today, and I live Hawthorn (in the inner suburbs of Melbourne), work in the CBD, am surrounded by excellent public transport, and using a car is more often than not slower than walking to my destination (as an example it once took me 40 minutes to drive 2km, and that particular stretch regularly takes 20 minutes to drive).

We (my wife, 2 young daughters aged 3 and 5, and I) primarily use our car for visiting people, but over the last year we have been replacing car trips with public transport in a lot of these cases. It might take a bit longer sometimes, but it means that we are more active as we need to walk a little more, and it affords us a much greater amount of quality time together.

When we are on public transport together we are able to observe the world around us, have conversations, and play games, all without "the driver" missing out. Given the driver was almost always me, I now have a little more time with my daughters than I did before, and that is a win I'm happy to have (hopefully my daughters see it that way too :-P).

It has been 4 weeks since we have used the car, and I don't miss it. The real test will be once it is sold (soon hopefully) and we no longer have that safety net. We won't totally deny ourselves the use of a car, we will rent a car when we need/want one (weekends away, mountain biking trips, etc.).

Although it isn't the primary reason for making the change, we do expect it to save us money given the estimated cost of owning a car is around $200 a week according to the RACV. We intend on tracking the costs associated with hiring cars and taking public transport we wouldn't otherwise utilise in an effort to measure the truth of this.

Our initial goal is to last 6 months without a car. But I'm quietly confident that we can go at least a couple of years without one. I'm looking forward to seeing how it all pans out.


Tuesday, 29 July 2014

Why We Started With Chef

I like to think that we are reasonably mature with our release processes at TAL, we release to production regularly (every 2 - 4 weeks depending on the application), our code is built once and deployed many times, and it has been a while since we have had to roll back a production release.

All that said, it is still more painful than it should be, more could be automated, our outage windows could be reduced further, and our management of configuration items (web.config etc) isn't great. We are continually improving most of these, and I have no doubt that with the introduction of Octopus Deploy (coming soon) we'll get a nice jump ahead on these issues.

One thing that isn't done well though, and we haven't had an answer to for quite a while, is server configuration management. For base server config, patches, service packs etc. our services team do an excellent job at keeping things up to date and consistent across the fleet. But for things like enabling MSMQ, web roles, applying permissions, and changing system default configurations, we apply them manually to each VM we spin up and use.

This means that when we need a QA, Dev, or other environment, we spend at least a day setting up the VM and installing/configuration, attempting to run our app, realising something was missed, installing/configuring, repeat.

It also means that we don't have an inventory of what customisations are required for our servers before they are fit for our apps to run successfully on them. We have a wiki page which is manually updated (when people find issues AND remember to update it), but anything manual like that inevitably ends up out of sync eventually.

We did some proof of concept work a little while ago with both Chef and Puppet, and for us Chef came out in front. Our latest work has got us to the stage where we can get a workable VM set for one of our apps up and running in well under an hour. That is an awesome development, and we are super excited.

We do still have a few things to sort out. For starters we are guilty of most of these anti-patterns. We are trying to move away from these and follow The Berkshelf Way, utilising Test Kitchen, ChefSpec, etc. This has led to a long list of things to learn and try out including Vagrant and Packer. There is also a whole lot of frustration around getting all of this working with Windows as most of the doco is very Linux focused.

We are confident that we'll find the process that suits our team soon, and even if it isn't perfect, we are still way ahead of where we were, and incremental improvement is much better than no improvement, some people may even argue that incremental improvement is the best kind.


Sunday, 27 July 2014

My NodeBots Melbourne Experience

I'd been looking forward to NodeBots all week, and although I wasn't quite at the not being able to sleep stage, there was absolutely no chance that I'd wake up late on Saturday. The day was definitely not a disappointment!

Myself and a bunch of other people waited patiently outside the The Village @ NAB (an awesome space by the way) until the friendly security staff would let us in the doors a little before 10am. The checkin process was easy, and before we new it @dtbolger and I had our Robo Hacker Kits and were checking out all the wires, plastic pieces, and electronics (including an arduino nano) we had. I don't know about everyone else, but I had absolutely no idea to where to start.

Luckily, by the time I got to that point @ajfisher gave a very nice intro to the day, and then Hadi gave a great presentation on getting started with electronics which I found very useful.

I then went back to my laptop and cloned the simplebot repository locally and quickly realised I had no idea how to perform the "Flashing my arduino" step. One of the experienced mentors helped us out by pointing us at the Arduino app (which we already had installed). The steps that were required were:
  1. Open Arduino
  2. Menu -> File -> Open
  3. Browse to the simplebot repo that you cloned earlier and select the file SimpleBotFirmata/SimpleBotFirmata.ino
  4. Click Open
  5. Menu -> Tools -> Board -> Arduino Nano (I had 2 options and had to select the w/ ATmega328)
  6. Plug the Arduino into your USB port if you haven't already
  7. Menu -> Tools -> Serial Port -> /dev/tty.usbserial.XXXX
  8. Click the Tick button in your SimpleBotFirmata Arduino window
  9. Click the Right Arrow button right beside the Tick button once the compile is completed
In order to test that it all worked, I plugged in all the wires according to the example located within the simplebot repo at ./examples/wiring/basic_wiring_bb.png, and then opened a terminal window to ./examples and ran "npm install" followed by "node simplebot.js".

The first thing I noticed that one of my servos worked and the other didn't. After a bit of head scratching, I found that I had plugged the servos into the pins d8 and d9, yet in the simplebot.js file I was referring to pins d9 and d10:
var left_wheel = new five.Servo({ pin: 9, type: 'continuous' }).to(LSTOPVAL);
var right_wheel = new five.Servo({ pin: 10, type: 'continuous' }).to(RSTOPVAL);
So I moved the wiring on the breadboard so I was connected to pins 9 and 10 and everything worked perfectly! Needless to say, I was pretty excited at this point, now I just had to strap the simplebot together and get it running all over the floor.

The next thing that confused me was how to hook the wheels up to the servo. What was needed was to cut 4 lengths (15-20cm) from the wire included in your kit, and thread them around another bit of plastic and the wheel (similar to threading a button), until it looks something like:
I set up the rest of the board until it looked like so:
I plugged in the battery pack, attached the wheels, and I was off and racing. One thing I'd recommend, is that you attach the nub/dome thing at the front (underneath the base at the bottom end of previous picture) before sticking the breadboard to the base. I didn't, and my breadboard was partially covering the hole I needed to use to screw the nub/dome to the base board.

I extended my bot slightly by using the ultrasonic sensor to stop the simplebot if it got closer than 20cm to an object. I also added an emergency retreat that would cause the bot to back away if it was closer than 5cm to anything. This was a bit of fun, but meant that my simplebot was terrible at soccer as it kept running away from the ball :-D


Wednesday, 23 July 2014

Continuous Improvement and the Rule of 2

If you are a member of my team I expect you to make our work a better place as a part of your job. I expect you to leave all code cleaner than you found it, to fix issues when they are spotted, etc. Most people like working in an environment like that, but it seems to be a very big hurdle to go from "ahh this code sucks!" to "ahh this code sucks! Let's fix it" for new people who join our organisation. So many have been indoctrinated through previous experience into the state of mind that "There is no way that management will pay for this".

A guide that I've been using to help people come to terms with how they can make these improvements happen is using the Rule of 2.

2 Hours

Will the improvement take less than 2 hours to implement? 

If yes, then why are you asking for permission? Just go and do it, once it's up and running then run me through it, particularly if it results in a good benefit.

The first thing I get asked when I tell someone about this is "What if it doesn't work? Haven't you just wasted 2 hours?"

Let's reflect on what happens when we don't allow our team members this freedom. How much time does it take for them to bring up the courage to approach me with the issue? How much efficiency is lost by not fixing/improving the issue there and then? How much time does it take for me to then take the 2 hour idea to my boss and ask for approval? (You might laugh, but I've seen 2 hour requests make it through 3 or more layers of management) How much motivation is lost because you feel that you "just have to live with it"?

When I do that equation, not allowing you the 2 hours is costing us significantly more than the 2 hour investment that you are asking for.

The worst that will happen is that we have spent 2 hours of time and haven't received any measurable benefit. But that doesn't mean that there isn't value to be gained by going through the process. Why didn't our improvement actually improve things? What didn't we foresee? This is a chance for me to help you understand what we could do better next time.

On the positive side, you might have a win, and the more comfortable the team is with this approach, the higher the strike rate is going to get.

2 Days

Will the improvement take more than 2 hours, but less than 2 days to implement?

If so, come and have a chat and convince me that it is worth doing. I don't want you to fill out 10 pages of documentation, I just want you to be able to articulate clearly what the problem is, what the solution is, and what the benefit will be as a result of that. If you've thought it through to that level, and we can't see any major risks, then we'll find some time for you to get it done, usually within the next week or two.

At 2 days effort, I'll be a bit more of a stickler for finding a benefit, but I'm happy for it to be a bit fluffy or nebulous. I'll never discount the positive impact removing frustration from a process can provide, even if it doesn't save time, it does remove negativity.

2 Weeks

Will the improvement take more than 2 days, but less than 2 weeks to implement?

If so, we'll have to do a bit more homework to provide sound reasoning behind the projected benefit of the change. I'll sit down with you and together we'll define what the benefits will be, how we can measure them, and what impacts the change will have (such as training costs, or flow on effects to down stream systems and processes). If the benefit is of minimal impact, then I'll probably point out a few similar sized items of work that are in the backlog somewhere and ask you to convince me why this improvement is worth doing before the other item on the backlog.

If we decide that the work is worth doing, then I'll take the idea to my manager, and we'll probably get approval for it. When we get to it will be dependent on current project commitments, and we'll probably schedule it into the next project gap, which is often within 4-8 weeks.

More than 2 weeks

Will the improvement take more than 2 weeks to implement?

If so, we are going to have to go through the same process as everyone else, we'll walk through the idea to flesh out the problem, solution, and benefits, I'll walk you through other work on the backlog to identify where we think it sits. If it stacks up, then I'll work with you to contact the right stakeholder to get it going (which could be my manager in some cases) and we will have a red hot go at getting it into the pipeline.

Conclusion

One of the keys to making this successful, is to make sure that whoever raises the idea is responsible for making it happen. You need to be the one to do the planning, the implementation, organising the testing, and finding a release for it to go in. If the idea isn't worth doing, I need you to make that call, I'll coach you into that place where you understand that your solution, although valuable, is not high enough in value to be anywhere near the top of the backlog. 

I say the Rule of 2 is really a guide, because if the idea is going to take 2.5 hours then we can probably let it fall into the 2 hour rule, and if it is 2.5 days, then the 2 day rule will be fine.


Monday, 21 July 2014

What I Look for When Hiring

Every hiring person has a different set of things that they look for and value throughout the interview process. The key things I look for are:

Honesty

If you are honest in your representation (resume, answers to questions) then I have a lot more trust in you, and have greater confidence that when you do join our team you will let me know when things are bad, good, or otherwise, and together we can help make it better. I also have greater trust that when you say you can do something, that you will be able to, and that I can confidently guide work in your direction without micro managing you (I'm not interested in doing that at all).

If you put a skill on your resume either in the summary, or the last 4 or 5 years of experience, I expect you to be able to talk about it. I want to be able to get answers about:
  • How was it used?
  • What problem did it solve?
  • Would you use it again? If so, in what kind of context?
What I don't want to hear is:
  • "It was created by <insert author>"
  • A regurgitated version of the github/codeplex project summary
  • "Ahh, I didn't really have much to do with it, my code was just called by it"
    • The exception here is if the tech you listed is a description of the overall architecture and not something that you claim to know about.
  • Any made up answer that attempts to cover up your knowledge

Learning

I can guarantee that no matter how many "required skills" I put on the job advertisement, you will have to learn a new skill at some point after joining us. Therefore, I want to know that you know how to learn, and that you care about learning. I want to get to know the kinds of things you choose to learn about and how you decide which ones are worth an investment of your time.

Once you join our team, we will continue to invest in your learning, but I still expect some learning to happen outside work hours in addition to the time that we allocate you.

Interpersonal Skills

This is a given in most roles today. I want to know that you can communicate effectively, and approach people in a constructive manner.

Confidence

I want to know that when you know your stuff, you will ensure others get to know as well. I will probably pose questions that I know are incorrect in order to see whether you will agree with me because I am your boss, or whether you have the confidence to call me out when I am wrong. Just because I am your manager does not make me right all the time, and I need to know when I am wrong so that I can learn too.

Technical Skills

Time and again I see people hiring for the exact skillset that they need today. While it is quite handy if you can get that, this is nowhere near as important as all the previous items listed. I want to know that you know how to program, that you have taken the time to learn a little about the tech you are using (not just blindly implemented something inside the framework), and that your skills will be transferrable and useful to our team. In fact, having skills that are not related to any project we are currently working on, and that no one else in the current team has, is a big plus, as it brings new experience and perspective to the team.

What I don't look for

Generally speaking, I don't care about how senior/junior you are. I look for great people, and it doesn't matter if they happen to be 18 months out of uni, or have 20 years of programming experience. Great people will help the team and myself continue to grow and excel, and that is exactly what I want.

Sunday, 20 July 2014

The Coding Exercise

When I first got involved in interviewing people way back in 2006-07 I started out like most others, asking textbook questions and hoping for text book answers. e.g.

  • Can you describe the ASP.Net page/control lifecycle for me?
  • What objects and methods would you use to retrieve data from a SQL Server DB?
I am also guilty of having asked some very specific questions related to some corner of the API that I felt a developer should have memorised. Don't get me started on the modern day "have you memorised the security API and remember which parameter goes where" that some recruitment processes force you to go through today :-(.

It became apparent quite early that this wasn't doing a great job of filtering the poorly skilled out and keeping the excellent people in.  

Someone smarter than me suggested that we include a coding exercise within the interview, we'd limit it to 30 minutes, and we'd sit with them so that they could talk through what they were doing as they were doing it. This was an awesome way to filter applicants, and it significantly increased the correlation between how well we thought someone would do day to day, and how well they actually performed on the job.

But there were still problems. Some people were so stressed with having people sit with them, and having a short deadline, that they had the shakes/sweats/etc. Some of these people actually seemed like they knew their stuff, but we were placing too much pressure on them. In addition, we felt that 30 minutes wasn't enough time for the interviewee to properly demonstrate their skills and professionalism.

Our next evolution was to let them take their time at home, we opened up the time a little by providing a guide of 1-4 hours depending on the particular exercise we sent them. This has been a life changer. It gives the candidate the time and lower stress environment in which to demonstrate their skills and style, and it has enabled us to filter people much more efficiently.

We have a few different exercises that we send out, and we try to find one that matches the persons skills and experience somewhat. 

All that said, it isn't perfect yet, and every time we go recruiting we tweak it a little and try something new. Hopefully we are making the experience better for everyone as we do so.

Our Current Job Application Process

I work at TAL in Melbourne, Australia, and our application process has changed many times over the years that I have been here. We have tried some things that worked well, and we have tried some others that didn't. Currently our process goes more or less like this:

1. Find people and get them to apply

We do the usual direct advertising (seek, corporate website, etc), engaging recruiters (some are better than others), as well as actively seeking people that our people already know (aka internal referrals). Depending on the market at the time we will progress somewhere between 30%-60% to the next step. The others have applied using an outdated resume, serious spelling and/or grammatical mistakes, or have experience that is not a match to what we are looking for (e.g. an Oracle DBA that is applying for a web UI developer role and hasn't taken the time to learn any of the skills required).

We don't do this step perfectly, and I should put a lot more effort into the job description that we publish so that we:
a) avoid people wasting their time, and
b) attract the kind of people who would do well in that particular role.

2. Phone interview

The phone interview usually goes for 15-30 minutes, and the point of it is for me to:

  • Verify the persons integrity:
    • Can the person back up what they put on their resume?
    • Is their definition of "expert" having read a book on it once? 
    • Are they overly modest, and are an expert but haven't said so?
  • Evaluate their communication skills:
    • We have offices in multiple locations, and we will need the person to talk effectively on the phone.
  • Give the person some information on our work environment and approach so that they know whether or not we are the right fit for them. 

3. Coding exercise

Providing the phone interview is not too bad, we'll ask you to do a coding exercise. We hope that you'll spend somewhere between 1 and 4 hours on it. We don't expect it to be completely finished and polished, however, we do want to see where you are heading with your solution, and get a feel for your coding style, and the kind of problems you are anticipating. We use it as a talking point in the first face to face interview.

4. In person technical interview

We'll get you in for between 1-1.5 hours where you will meet and be interrogated interviewed by your prospective manager and a member of the development team. The line of questioning we follow is highly dependent on the person we are interviewing, and could be mostly about the coding exercise, or mostly about your experience, skills, and approach.

5. In person final interview

If we are happy with what has gone before, we'll invite you in to meet the head of the department, the QA manager, and probably someone from HR to make sure as a management team we are all happy with you joining us.

By far the biggest improvement we made was the introduction of a coding exercise into the process, and that has evolved a bit over the last few years, but I think I'll save that post for next time.