How I Learned to Stop Worrying and Love the New Axis of Evil (Oracle)

There’s a wide sense of lament since Oracle has taken over Sun and their intellectual property, including MySQL, Java, Solaris and their hardware sales business.  I’d say the average observer of this process might use the terms “slow moving train wreck”.  I doubt they are far off on this one.

You know what?  I think Oracle taking over Sun and acting stupid is actually a GOOD THING.

No, really I do.  Let me explain.

Sun has a long history of innovation with Java.  They also have a long history of missteps (take your pick, but I personally like the layoffs that happened biannually but basically culled the best folks who took packages to get out of the toxic environment)  and flat out screw ups (Hello?  Selling off your $1B/year professional services business because you’re not a “software company”?  Wish I had those kind of problems).  I have a number of personal friends who worked there (mostly past tense, but there are still a few stragglers left) and I don’t wish their employer to crater.  No, not at all.

So why is Oracle’s behavior regarding the death of Open Solaris or suing the crap out of Google for the use of Java in Android a good thing?  Easy:  We now have an opportunity to spur the development world into action.

The Empire Formerly Known As Evil

Flashback to 1995:  Microsoft (the former and still ranking Evil Empire) was king of the developer world.  Open source was a twinkle in the eyes of a few idealists.  Developers paid handsomely to Attack of the Clippy Zombiesbuy into the Visual Studio paradigm.  Or they bought from a competitor (Borland).  C++ and C were the de rigeur choices of language at the time.  Enter Java and the entire development world was turned upside down.  No one saw Sun as the disruptive innovator at the time.

Of course, other factors played into it over the years:  the rise of the internet, the Dot Com boom and server sales tied into Java usage, the rise of open source and the overwhelming support from the community regarding Java, driving huge amounts of frameworks still in use today.  But there was always a motive:  fight the evil empire.  We fight them because the evil empire doesn’t “get it”.  Remember Microsoft’s internet strategy in the late 90s? (From a blog post regarding the missteps of Microsoft, particularly Project Blackbird)

Adobe’s Mark Anders about his time at Microsoft. Anders is well known as one of the inventors of ASP.NET, along with his colleague Scott Guthrie. However, when he joined Microsoft in the mid nineties he worked initially on the project codenamed Blackbird. This was a kind of Windows-specific internet, and was surfaced to some extent as the MSN client in Windows 95. Although the World Wide Web was already beginning to take off, Blackbird’s advocates within Microsoft considered that its superior layout capabilities would ensure its success versus HTTP-based web browsing. It was also a way to keep users hooked on Windows. Anders told me that he never believed in Blackbird and argued that Microsoft should support HTTP instead. According to him, the executives at the time did not want to listen at first, but Blackbird had severe performance problems

Darth Ellison and the EmpireStuff like this always pisses off the right people. Microsoft didn’t get it, and people got mad.  Microsoft’s stupidity in thinking they could control the internet spurred lots of innovation from other companies to make the *real* internet even more valuable.  Eventually Microsoft capitulated and followed suit with everyone else. 

And that’s precisely what I’m counting on here for the Oracle debacle. Because Oracle isn’t getting it either (at least for developers). Tim Bray’s article today has a great quote from the Empire itself:

“You don’t get it. The central relationship between Oracle and its customers is a business relationship, between an Oracle business expert and a customer business leader. The issues that come up in their conversations are business issues.

“The concerns of developers are just not material at the level of that conversation; in fact, they’re apt to be dangerous distractions. ‘Developer mindshare’… what’s that, and why would Oracle care?

Let’s Shake Things Up

Java not good enough for Android?  Fine, let’s make a new language that finally innovates on the mobile device, unlocking us from the collective disasters of Objective C, mobile Windows, and bloated Java ME.  If Java 7 is going to die at the hands of Oracle, maybe that will motivate some development group to actively fork it in a meaningful way.  Or finally develop the successor language to Java that revolutionizes the software community the way Java did in the mid-90s.

This complacency about Java, MySQL, and the state of Sun products has got to stop.  It’s time to shake things up.  And the last time that happened, exciting times were had by all.

I can’t wait.

Stop Dumbing Down The World with Bad Interview Questions

With the Holiday Dead Zone coming to an end and the global economy picking up, I’d like to talk a little about interviewing software developers since hiring season is now upon us.  Ever been to an interview where they ask some whopper like this?

“Can you ever write code in C++ where you say “delete this;“?”**

Or maybe one of these doozies from “Google’s Interview Questions to Make You Feel Stupid” (which, BTW, aren’t all from Google…but from Microsoft as well)

  • How many piano tuners are there in the world?
  • How many golf balls can fit in a school bus?
  • Why are manhole covers round?
  • How much should you charge to wash all the windows in Seattle?

I’ll be the first to admit that I went straight for this Stump-the-Chump mentality.  Along with the goofy questions above, developer interview articles abound with the kind of information you can ask about language trivia even the very authors of the language would probably be hard pressed to recall under pressure.

monkey-with-cymbals
Uh, why are manhole covers round?

If you’ve never been subjected to such a grueling event, I commend you.  You must know some really awesome people to get past those kind of interviews.  But most developers know what I mean.  The kind of interview where someone just throws out obscure or impossible questions one at a time until the candidate softly whimpers for mercy, turns into a puddle of tears, and runs screaming out of the door.  Preferably with brown stains in their pants.

I started out as that kind of manager and interviewer.  My favorite question was the Microsoft classic of the Four People, a flashlight and a Bridge question, except I used a variant where the four Beatles were stuck at Red Rocks Amphitheater here in Colorado.  Inevitably, I asked that question to everyone I interviewed…project managers, developers, QA–I may have even tossed it out to a marketing guy once.  My reputation at that company was “bastard interviewer” (a direct quote from my friends, and not altogether undeserved).  Anyone who survived the ordeal always had a great collective story with a lot of the other employees to share at happy hour.  My interview tactics actually influenced other managers at the company to ask easier questions because they felt sorry for the candidates having been through “my interview”.

Years later, I realize not only how mean that was, it was also useless. Of the mix of people I interviewed back then, we hired great developers, mediocre developers and a couple bad apples.  These questions are supposed to be some sort of impeccable bozo filter–yet they all passed it.  Our team was not filled with little Bill Gateses and Linus Torvaldses.  While we were productive, we also didn’t launch our product either, so what went wrong?

When you attack someone’s encyclopedia of knowledge, these kind of questions barely touch on the darkest corners of experience if you’re lucky.  It’s somewhat like the SAT admission test here in the US for college admission.  But like the SAT fails to capture real knowledge and performance potential at a university level, the interview questions we use today are equally inept.

What you really want to know apriori is how this person will work on your team–do they share credit, steal it, or hide until the project ends?  You’d like to know what kind of code they write–is it atrocious, beautiful, disorganized, or anal-retentive?  You’d like to know how the interact with people–are they sociopaths, leeches, primadonnas or Mother Teresa?  You want to know if they’re Smart and Get Things Done, to quote Joel Spolsky.  Checking whether they know esoterica about C++ isn’t helpful when they’ll spend 90% of their time on Java.  Or hammering someone about parameters and exceptions to methods for a particular framework (Seriously, I saw this on several blogs asking people detailed questions about methods in Spring or Hibernate) when the answer is one Google search away.  All of this kind of interviewing is useless.

Now that we’re at the end of the first decade of the 21st century, I’d like to boldly propose that we do away with Stump-the-Chump interviewing.  Instead, why don’t we try this, adapted from this post about entrepreneurs where a VC has specific criteria for successful entrepreneurs:

  • Tenacity:  Is this the kind of developer who has really been through the ringer of a hard problem and crawled out of the sewer pipe with the answer raised in his or her hand, triumphant?  Or do they sit back and wait for others to answer questions for them?
  • Street Smarts:  No, I don’t mean do they know how to make a shiv out of the plastic pepper shaker in the break rooms.  I mean, do they know the rules and when to break them?  Are they creative in their solutions, or more conventional and straight forward?
  • Ability to Pivot:  Is this person going to whine or moan when the project suddenly needs to change direction and rewrite in Ruby?  Or do they take things in stride, take your instructions and start grabbing links for the entire team to bone up on the finer points of Rails, Grails and JRuby too?
  • Resiliency:  When the project reaches a point of just grinding out some mindless junk, are they the kind that complains about it or someone that finds ways to get past that with scripts they share or tricks from another job?  If things head south on the design meeting, do they bash the marketing team for the changes, or just take a deep breath and sink their teeth into getting past this setback?
  • Inspiration:  Does this developer constantly strive for new information?  Do they like to share blogs or resources that get them excited about their job?  Are they the kind of person who finds a new way to write a framework and creates a proof of concept just to show how interesting it might be for the next revision?

I’m not going to tell you which questions to ask, because really, that’s no different than another stump-the-chump session using my blog as the source.  Use their resume, ask leading, open-ended questions that get the person to tell you about their previous projects.  Listen to what they have to say, probe deeper into it, get a feeling for their experience.  Get past the bullshit, because we all know there’s a whole lot of training that we go through to “pass the interview”.  Call their references and get references from their references, because those people will actually give you honest answers about this person.  Find someone you know that worked with them.  Ask them if they’d work on the same team with them again.  Really, that’s the one question you need to ask.

And those are the kind of answers we’re looking for anyhow.

* UPDATE:  A great site popped up that allows you to perform remote coding interviews to help weed out the wheat from the chaff:  Try See[Mike]Code. They write, you watch. Live. Get some feedback before you even start the interviewing process.

* UPDATE (part 2):  An article from Monster.com about Google’s ineffective hiring practices.

**Incidentally, for those uninterested or unwilling to look it up, the answer is yes, you can.  And there are some valid reasons to do so, but the question definitely shows just how much or how little you understand the underlying memory model and code execution of C++.  But I still think it sucks as an interview question for C++ developers.

*** Nothing new under the sun:  If you liked this post, try this gem from 2007 that mentions many of the same points but in a different way.  I found it AFTER I wrote this.  🙂