A taste of Ruby and Rails

Although I've done C, Perl, PHP, and Java-based web programming in past lives, I've spent the last 8 years or so developing on ASP.Net for a living. As a result, I believed Ruby on Rails (RoR) was a toy not meant to be used for anything serious. Because it's easy to learn, people use it to build cheesy websites. But, that doesn't preclude you from building serious websites, Twitter being the standard-bearer for Rails. Here's what I can tell you: a programming language is merely a tool. And if data-driven web programming is your nail, then RoR is quite the hammer.

Here's the key difference: C developers think of a pointer as a basic building block.  C# developers think of hashtables and lists as basic building blocks.  RoR developers think of database tables as basic building blocks.  Working on SharePoint, anytime we needed to add a new database table, it was a big deal.  You had to write a bunch of CRUD operations and stored procedures.  You had to write a bunch of UI to expose the CRUD operations.  You had to write an object model.  You had to write upgraders.  You had to make sure it got backed up properly.  All of this took, on average, a month for a developer to code and unit test.  With Rails, all of this is inherent to the architecture.  You design the database schema, and all of this functionality is immediately available, freeing you from the drudgery and allowing you the time to actually design and build something useful.

You might say, well I can do all of these things with LINQ, the Entity Framework, or some third-party bolt-on solution.  And you'd be right.  But that's a bit like flying economy on a long-haul flight to Italy with a layover in London.  Oh, you'll get there, but only after much discomfort, a strained neck, and having paid extra for your checked bags.  Why bother when you can take a comfortable non-stop flight in first class -- and did I mention it was free?

Of course, it is free only in the monetary sense.  One of the main critiques of RoR is you pay a price in performance (partially because it is not a compiled language).  But if it's good enough for Twitter's billion tweets a month, I think I'll manage.  In a followup post, I will go over some of the other problems I've encountered which are not often discussed in online forums.

My love for dependencies ...

Once upon a time, we had a developer whose full-time job was debugging random issues in some particular feature.  That feature had a dependency on an external team who had no vested interest in this feature, and therefore using their library was a bit like using chopsticks (their library) to eat steak (of course our feature is the delicious steak).  Sure, you can use the chopsticks, but every time you do you question whether you'd be better off without them and just eating the steak with your hands.

Couldn't get any worse, right?

So, when a different team approached us with a product that was a perfect fork and knife that they used to eat steak every day for the last three years, we chomped at the bit to get a hold of it.  Long story short, their utensils were made of plastic and were constantly breaking, and now we have two developers whose full-time jobs are debugging random issues in this feature. 

We long for the days of having chopsticks to eat our steak.  Do not take dependencies lightly.

Managing your time wisely

I'm one of those people who strive to be “efficient”. I learned this playing games like Starcraft. To win, you have to click like a madman to control everything at once. The best players were above 200 clicks per minute. And, you better type at light speed, otherwise you will get clobbered while writing messages to your teammates. At work, this means I don't sit around for process recycle or rebuild, I always go quick-check something else while I wait. I've read that your brain thinks at around 400 wpm (words per minute), so even if you type at a zippy 150 wpm then you are wasting braincycles. When I watch people type at a very reasonable 60wpm, it takes every ounce of resistance in my body not to rip the keyboard away and type for them.

So yes, patience is not one of my virtues. As a result, I cannot believe a 3.0ghz quad-code computer makes me wait. Ever. Everytime Outlook hangs while I'm in the middle of typing my e-mail, I can't help but flip it the bird. What on earth is it doing? If not for NetBIOS name restrictions, my computer's names would be !$(^$@( and %!%^(*.

Anyways, some tips for dealing with e-mail:

• Reply to the e-mail the first time you read it. It takes a few minutes to context switch into a problem, so make sure to only do it once. Don't “save this mail for later“, because you'll either forget, waste time reading it again, or you're making the other guy wait. Even a brief initial response is often enough for the sender to figure the problem out.
• Delete the e-mail as soon as you reply.  Don't worry, it'll be in your trash for a while, and you have your "sent items" to fall back on too.  But the net result will be a clean Inbox which reads like a to-do list so you won't lose track of things. 
• If your response is going to be more than a paragraph or two, go talk in person. I could not believe how long it takes to craft a well thought-out e-mail -- try timing yourself sometime. And even then, the recipient usually just asks you to schedule a meeting and it quickly becomes clear they didn't even bother reading the mail.

Some tips for software development:

• Invest in your development environment.  Spend time learning all the shortkeys, discovering ways to customize the tools you use every day, and get the hardware that will make you most productive.  Start with a new monitor. A big one.
• Given that your typing speed is a constant, reduce the amount you have to type. I create batch files for everything -- "n" for notepad, "d" for diff, "b" to rebuild, shortkeys to take me directly to common directory paths, etc. I ditched my hardware KVM switch because of the two-second switching lag -- using software to swap desktops is instantaneous. It may not sound like much, but instantaneous is an order of magnitude better and can change the way you work.
• Automate repetitive tasks. If you find yourself doing the same thing over and over, you can save tons of time by automating it. I've written tons of tools that do repetitive, labor-intensive tasks automatically, and your peers will appreciate it too when you share it with them.

Strategies that haven’t worked out for me:

• Closing the door doesn’t prevent people from stopping by, and it shouldn’t. The fact that they invested the time to pay you a visit, means that it must be important to them. Ignoring them may only save you five minutes, but cost them an hour.
• Having separate dedicated boxes for coding and e-mailing doesn’t allow me to focus single-mindedly on programming. It just makes me switch between machines all the time.
• When I come in early in the morning, I don't get any additional work done. If I don't get sleep, I will spend the morning sipping tea and reading the news. Even more than usual.

What strategies work for you?

Communication patterns and diversity

Someone recently sent me a tool which measures whether your brain is left/right-hemisphere dominant, and auditory/visual. I am left+visual, and prefer logic and visual patterns. In a discussion I will find myself going to the whiteboard, even sometimes when it's not necessary, and highly prefer people draw their ideas out because I like having something to stare at.

Anyways, this sort of thing gets interesting when you have two people at the opposite ends of the spectrum. When they are trying to communicate, the visual guy may be drawing a diagram and asking "Why can't you see this?" to the auditory guy, who is thinking, "Why can't you hear what I'm saying?". Other communication examples are where one person wants to discuss big picture and the other wants to start with the details, or where one person prefers face-to-face and the other prefers e-mail discussions.

With a diverse group of people, the challenge is understanding everyone's points of view and having both sides alter their behaviors to accommodate each other. I've heard someone tell me that each slide in a presentation should have at most one sentence or picture, and bullet-points are the work of the devil. But I think a good presentation should appeal to both auditory and visual people, and not just one half or the other. As another example, a meeting with documents sent beforehand, provides face-to-face time via the meeting while allowing people to send questions/comments via e-mail. Small behavior changes like these make all sides feel comfortable and help everyone communicate successfully.

When to bug someone for help?

Let's imagine a hypothetical scenario where a group with whom you have a dependency on assigns a bug to you, telling you it is not their problem.  And, let's also say that you had little familiarity with this code.  Would you:

  A) Spend an hour to generally understand the code, and then try to debug what was wrong?
  B) Spend an hour to generally understand the code, and then find someone to explain the specific problem to you?
  C) Find someone to explain the specific problem to you, then spend an hour to generally understand the code?
  D) Twiddle your thumbs until someone with a more vested interest in this problem takes it over from you.

I think the answer is, it depends.  All too many of us go with Option A, simply accepting ownership of the problem.  Sure, you will learn the most by debugging everything yourself, but it will take the longest amount of time.  Often times, you don't care about learning about this code and just want to hack through to find a reasonable fix.  This approach would only be appropriate if you want to own this code long term, and the debugging time is essentially a time investment.

Researching the issue first will allow you to absorb the most when you finally do talk to the expert, since you will actually understand what he's talking about.  But talking to the expert first will save you ramp-up time, and has the additional benefit that they may realize they can fix it in less time it takes to explain it to you, and just fix it themselves.  I feel it works best for cross-group collaboration to do your own due diligence first, except in cases where time is critical.

Finally, there are times when even thumb twiddling might be appropriate.  Sometimes, the bug is sufficiently complex that you need the issues surrounding it to bake before you can tackle your own problem.  Sometimes, time is the only way for the other group to see the light.  Sometimes, time will cause the genuine priority of the bug to emerge, when it is weighed against other issues for possible postponement, and stakeholders protest.  I find the right things usually happen when they are being addressed by the people who care about it the most.