On Vinaigrette and Company Culture

Nothing beats a fresh vinaigrette on mixed greens. It’s really easy to make if you follow some simple rules. The key to the making vinaigrette is to create an emulsion.

It isn’t everyday that I get to use my degree in Chemical Engineering, but the idea when you make an emulsion is that you are combining two liquids that normally wouldn’t mix, like oil and water. In the case of our vinaigrette, we might be combining lemon juice, balsamic vinegar, or some other water-based ingredient with olive oil.

The key to emulsifying is to slowly incorporate the oil into the lemon juice, while vigorously whisking. Incorporating slowly, the tiny little oil molecules are able to mix in with the water molecules and what you end up with is something wonderful, that is neither lemon juice or oil. Dump the oil in too quickly, or don’t allow the oil time to be incorporated, and you end up with an oil slick.

I’ve been thinking about this and how it relates to company culture. Smart companies hire smartly (the first rule of Tautology club is the first rule). Hiring smartly often means hiring slowly, even when you feel you need to add lots of smart people. Hiring slowly allows new team members to become part of the existing structure and values, while still being able to impart their own flavor and characteristics, just like our vinaigrette. Add too many people at once, even smart people, and suddenly you lose cohesion and you are left with a fragmented set of values, like a vinaigrette that has “broken”.

Sometimes you have no choice in the matter, particularly in this day and age of acqui-hires. Suddenly the team grows. How can you do it and maintain the values and strengths of each team? Ideally you still try and do it slowly, but sometimes that’s not an option. What can you do in those cases where you just have to throw the teams together.

Start by allowing each team or group to learn more about the other’s strengths and weaknesses. Have honest, open communication about what’s working well and areas that deserve special attention. Share lessons learned and core values through presentations, brown-bags, and pair-programming. Carefully form project teams with members from different groups that might provide an example for others to follow. And please, please, please don’t deliver your core values from on high. Nobody needs slogans.

And don’t forget to pay attention to the little things too. What is the new office environment like?

• Is the space “vibrant” or “noisy”.
• Are people from different teams interacting, going to lunch together?
• Are the “new people” getting “new equipment” or other special treatment.
• Does the “old guard” have the ear of management.

Remember, perception is reality.

On Working Remotely

I don’t know if you’ve heard, but we’ve had some historic snows here in Boston, that have had a “slight” impact on public transit and just getting around in general.

https://twitter.com/SaraMorrison/status/567467416842928128

I have always felt that being in the office is key to being effective as a software developer.  So much of what we do is about communication. How can we do that without being face-to-face with a customer or coworker?  How can we do that without being able to seamlessly share code, ideas, nuance.  Although I have worked from home from time to time due to weather or other conflicts, I always thought friends who worked primarily from home were probably stretching the truth a bit about how effective they could be working remotely.

After a couple of weeks working primarily from home, I have changed my tune.

The quality of tools available to facilitate remote work amazes me.  It seems like in just the last 2-3 years they have grown in leaps and bounds. I am a big fan of Screenhero and Slack, and am delighted that they have combined forces. What truly amazes me is the way these tools facilitate multi-user (more than 2 people) support.  Throw in the odd, Google Hangout, Goto Meeting, Join.me and there are so many ways that we can now communicate effectively from anywhere.

I still prefer working in the office.  I like my coworkers (no, really), and in my opinion there still is no substitute for a true face-to-face conversation.  I like socializing and grabbing lunch with friends.  But I can now envision a time when I can make working remotely a significant part of my typical work-week.

There are some potential drawbacks.  I notice I take fewer breaks when I am working remotely, and I think periodically stepping back is a big part of solving hard problems.  I also worry about the overall impact on work-life balance when it is so easy to always being “available”.  But these are solvable problems, like someday people being able to decide on their own what can of tomatoes to buy without calling home when the low-sodium kind aren’t available at the market.

I think the ideal situation for me would be 2-3 days/week in the office, especially if that is coordinated with other peoples remote schedules. That would seem to allow for the most effective face time, reduce time wasted on commuting, and allow for significant chunks of uninterrupted time.

Book Review – Effective Ruby by Peter J. Jones

One of the great strengths of Ruby is that it is easy to pick up and be productive right out of the gate. But Ruby is such a rich, full-featured language that there are probably a lot of things you aren’t aware of that can make you a better developer.

I recently received a copy of Effective Ruby by Peter J. Jones, and I really enjoyed it.  This book is a good addition for beginner and intermediate Ruby developers to learn more of the language features and write better, more maintainable code.  The author has geared the book towards people who have some experience with Ruby and points out some of the common pitfalls that developers new to Ruby might face.

The book has 48 items to help you improve your code and covers everything from Ruby basics to an overview of the garbage collector.  As someone who has been using Ruby for a few years, I learned a few new things about collections, Ruby’s inheritance hierarchy, exceptions, and performance tips.

I thought the section on testing was a little thin, but there are entire books dedicated to testing and it is a tough topic to address in a single chapter.  I think the author’s intention is just to make the reader aware of the testing tools and methodologies available.

All in all, I thought this was a good read.  I’ll keep it handy and look forward to applying and experimenting with some of the ideas.

SOLID Design Principles at Launch Academy

I had an awesome day speaking to the students at Launch Academy in Boston.  I have a lot of respect for what Dan Pickett and Evan Charles are doing over there, and I hope it brings a lot of new, great developers into the community.

I had initially planned on doing a talk on the SOLID design principles, but as the group is just starting out learning good practices, I didn’t want to throw too much at them at once, so we focused on Single Responsibility Principle, Dependency Inversion Principle, and an Agile design practice called Incremental Design.

It was a ton of fun.  They are such an energetic and engaged group.  They had very good questions about technical debt, what constitutes a good test suite, and resources for further learning on TDD.

The talk is available below, although due to some technical difficulties at the talk I had to re-record it, so I didn’t get their questions or the wild applause at the end 😉

Thank you Launchers for hosting me, and I look forward to seeing more of you in the Boston developer community.

The example code used in the talk is available here

Here are the references from my talk

Bob Martin (Uncle Bob) on SOLID
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Sandi Metz – SOLID Talk at GORUCO
http://www.confreaks.com/videos/240-goruco2009-solid-object-oriented-design

Derick Bailey – Los Techies
http://lostechies.com/derickbailey/2011/09/22/dependency-injection-is-not-the-same-as-the-dependency-inversion-principle/

James Shore – Art of Agile
http://www.jamesshore.com/Agile-Book/incremental_design.html

And lastly, here are the slides

Design Principles – Michael Denomy at Launch Academy from Michael Denomy

I Have a Secret

I have a secret.  A horrible, terrible secret.

I can’t type to save my life.  I’ve been writing software for over 20 years and have managed to get by with hunting and pecking with 3-4 fingers.  And that worked fine, working alone in my little cubicle…until pair programming came into my existence.

I love pairing.  The back-and-forth flow of ideas, the continuous discovery and refactoring, the changing roles between driver and navigator. I think it is one of the greatest improvements in how software engineers work that I’ve seen over my career.  But it sure helps to be able to type.

So I am going to do something about it.  Inspired by an old Corey Haines post I am declaring my own personal Learn to Type week.  Corey’s post has some good links to help you improve your typing skills.  This post had a few more.

So for 30 minutes a day for the next week I am going to try and bring my typing skills up to a respectable, pairing-worthy level.  I’ll keep you posted.

 

Update: After a week, I have to say it is slow going.  I have been doing exercises from this post, and although I like the lessons a lot I am struggling to complete the lessons in 60 seconds.  At times I fly, error-free, then I think about how well I am doing, then I start to think about what keys are where, and then everything goes hay-wire.

This will take more than a week to learn, but I am committed to seeing it through.  Right now I am still much faster with my 3-fingered typing, but if I stick with it I think it will pay off in the end.

Just Because You Can, Doesn’t Mean You Should

I got a new car recently.  For the last 10 years, I have been driving a Jeep Cherokee with roll-down windows, manual door locks, and no modern conveniences other than air-bags.  Now I am getting used to all kinds of conveniences like lights that shut off on their own when I turn off the car, ABS, stability control, and even power windows and locks.  Basically all the good things that the rest of you have enjoyed for a while.

It took a bit for me to come to grips with the fact that a car with ABS can stop the car better on snow than I can by gently pumping the brakes.   And I am pretty sure that I’ll never get a dead battery because I left my lights on.  So what does all this have to do with software you ask.  Well I’ll tell you.

I love all these new features.  But there are a few things that my car does that I think may have been “cool” to the guy that designed it, but maybe not such a great idea in the long run.  My favorite example is the stability control system.  The stability control feature will do wonderful things like help keep me pointed in the right direction if I start to lose traction in snow.  What’s wrong with that….nothing, I love it.

What drives me crazy is that when the stability control automatically activates, an alarm sounds telling me that it has kicked in.  Now I have one job in all this and that is to drive the car, but when I hear an alarm my first reaction is to look at the dashboard and find out what is wrong.  Whoever designed this “feature” probably thought it was a cool thing to do, and we might as well use the buzzer in the dash for something, but is an unintended consequence of getting a driver to take his eyes off the road while losing traction a good thing?   I don’t think so.

We’ve all been in situations when we have wanted to do something because it would be fun to implement or maybe would use a technology that we’ve always wanted to try.  That isn’t a good enough reason to do put something into a product.  It needs to add value to your product and be the right approach.  If you want to try out a new technology, put it in a spike solution where you are free to experiment and where it stands alone and is easier to be reviewed. Prove that it works and show it to your peers.  Determine how it can make your product better and convince the product owners.

Being agile means responsing to changing requirements and technology, but product decisions need to be made in the light of day.

By the way, this has not been a problem on the teams I have worked on.  It’s just that we’ve been getting a lot of snow lately and that stability control alarm keeps going off.