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.

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.

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

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.

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.

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.