techno.blog("Dion")

Aaron gave a humane look at how to hire a programmer. It was less about programmers than it was about hiring, and how to judge people. Some have jumped on how this doesn’t scale to BigCorps, and others don’t think it tests the programming side of things at all.

First, the scaling. If you take a look at how big companies recruit their often have legions of sourcers scouring linkedin and the Web, and recruiters on top of them. The law of averages has them weeding out people based on some kind of “bar” which is inperfect but they feel like they need something. Of course, the main problem is that there is a huge amount of nuance in judging someone from their resume. If you can get past the fact that a resume can only tell some part of the tale, you also know that you, the seasoned programmer, can instantly make some kind of judgement on one. “Erm, this guy lists XHTML, HTML, SGML wtf?” Many sourcers will not be able to tell the crap from the truffle. Once you get these people through there are phone screens and the like, and then in person interviews, and suddenly engineers are spending a lot of time in the process. Rather than having them ask how many eggs fit in a mini, maybe there is something more productive.

This directly relates to school exams. We all know the kid that always did well in tests. And we all know the kid that was incredibly bright but never seemed to do as well as he should. Exams and tests are pretty crap depending on what you are going to Be When You Grow Up. If you are a flight traffic control chap, then the fast on the spot thinking will help. If you are an artist? Maybe not.

I am far more interested in seeing a portfolio of education than an exam grade. When Sam and Josh are older I want to talk to them about what they learned, and what they have produced…. not their score out of 10.

I think the same goes for programming. Show me what you have done and let’s talk about it. It is important to understand the scope of that persons role on the project, who they worked with, how long it took, and many other factors, but this can come across with conversation.

Another part of showing me what you have done is doing it with you. The best interviews I have done have been where you get some code out and you hack on it together. This is after all how things will be like in the team, so let’s practice what you will actually be doing. It isn’t about getting every line of code right, or getting the correct big O notation answer to a question.

Ideally of course you would be able to do much more than a quick hack session before you pull the trigger on a hire, and vice versa. So wait, aren’t we just doing this entirely wrong!

Doesn’t it feel like we are jumping into bed before we have rounded the other bases? What I really hope for is that we change the way employment happens. Imagine a world like this:

• A company has need for someone to come hack on a project
• A person has the interest and potentially has the skills
• Person and company come together and start working on the project
• Over time if things are going well, the person and company do more projects together
• Much later, if the companies want to make a joint commitment to each other, the person weds the company

If only we had the tools to do this. Oh wait, we do! We can contract/consult right now. There is no rush to bed at all. The only issues seem to be social and perception.

People often want to jump into bed with a company as they want security (which includes items like healthcare in the US which is INSANELY tied to companies, but that is another matter) and upside (e.g. “get me in now so I can get stock and kick off vesting!”).

Companies often want to jump into bed with a person as they want to “lock them in”. There are many legitimate reasons here such as investing in people, getting domain knowledge (including secret knowledge!), and the like.

Some companies and cultures have the notion of “probation”, but that seems rare and feels much different: “company: Just in case you suck I have an easy way out!” vs. “let’s both check each other out and see how this progresses”.

I have some consultants on my team now who are great. I hope it progresses. I wish that culturally it becomes more common to go this route. It is socially acceptable for permanent bed hoppers (consultants) even if they often have a stigma.

Oh, and with Employment 2.0 we will have micro-employment too. Oh wait, we already do.

Insert Google Anecdote

People love to talk about Google hiring. This is one of my favourite anecdotes. It is hard to get into Google (rightly so!) and you get rated out of 4. When you go through “perf” (the review cycle) you also get rated. I remember being in a meeting where someone ran the numbers to see how the hiring ranking matches the end of first year (and beyond) ranking. There was no correlation at all. The higher the hiring rating didn’t mean anything for 1 year performance.

Insert Hiring Anecdote

We are hiring at Palm. My team is looking for developer advocates and the like, and the company is looking for a whole slew of great people, especially engineers!

• Think the native apps on webOS are cool? They are just HTML/JS/CSS. Help us make more!
• Think that a Web based device platform could be better? Help us on the framework or beyond!
• Low level Linux hacker? Got spots there too. Bring it on!

I love your work and respect you, @ppk, but you just wrote a very naïve post. Guessing @dalmaer slipped you a mickey, so I’ll forgive you.

I did see PPK with a drink, but I didn’t drop anything in it, I promise! :)

What are we talking about here? PPK has written a post commenting on the interesting “Apple’s mistake” essay by Paul Graham.

I love PPK and he is doing great work, but I have to respectfully point out a few things here, especially as some folks thought I put him up to it. For those who are jumping on him in entirety, here does have some things right too! Don’t just get mad at the fact that he called developers arrogant and stupid ;)

There are fantastic web applications on the iPhone. I use Gmail and Google Reader as a Web app, for example. The browser is good, but I have written many times (before being a Palm employee! These are my thoughts… blah blah) about how I wished that Apple let me go the extra mile and access more from the Web side of things.

Although you can do great apps like Gmail, the user experience available to Web developers isn’t anywhere as close to that of the iPhone SDK.

• APIs: You are unable to access the rich APIs on the device. Sure you can get local storage and appcache, but you can’t get to the compass and the [insert tons of APIs here]. Your app may not need it, but they may be able to greatly benefit from them… let alone the enhanced graphics and performance.
• Discoverability: There are two worlds. The Web and the App Store. How does a user find out about your Web app? Sure they could use the power of Google etc…. but if they are trained not to do that anymore? Fortunately we have PhoneGap and Titanium and … stepping up here

So, the feeling of “come on iPhone devs, don’t be stupid and just develop a web app!” is going a tad too far. There are very valid reasons to use native. With PhoneGap et al, there are growing reasons to cover various bases.

At Palm I am excited to push the Web stack further by having it as the SDK, not as an option in the browser. I believe that the Web can be the unifying platform across the multitudes of devices that users will have in the future. This world is going to cause a large number of changes to how we develop experiences, and I am excited by the challenge and working with the Web community (companies and individuals) to meet the challenge.

There is so much to be done on both the technology side (html5 on devices, apis, services, gpu, etc) and on the delivery side (future of app stores, richer discoverability, etc). You can also create fantastic applications for many platforms using Web technology TODAY!

Update

Faruk Ateş has written a detailed post on this topic too that discusses similar issues to my post above, but also goes beyond with more details on $, and the SDK experience.

“Just what the world needs—another sucky JavaScript library,” he said. When I asked him what made it ‘sucky’, he elaborated. “It’s a JavaScript library written by Java developers who clearly don’t get JavaScript.”

This quote is by Kevin Yank, talking to Dmitry Baranovskiy, author of the fantastic Raphaël graphics abstraction library. He writes up more on the issues they see with Closure. This is the few of one side of the community towards the open source release of Google Closure and its tools.

It was bound to happen. When I started at Google I quickly wanted to learn about how Gmail, Google Maps, and all the revolutionary front ends that helped make Ajax happen. Closure was the heart of it, and I quickly wanted to see a way to get the knowledge out there. This was years ago now, but the same reasons permeate through. Even at the time there were a ton of great JavaScript libraries. It wasn’t that I wanted Google to come down the mountain like Moses and bless the world “thou shalt use Closure!” However, some smart people had worked for some time refining their use of the browser runtime and Closure was the art and science of that ongoing experiment. Having the world able to at least see the experiment would be a good thing. Other libraries could learn from it.

No one from Google has said that you should, or must use Closure!

I realize that we live in a world of heros or zeroes. There isn’t room for much in between. You are either going to be a X killer, or you are killed by X. There is no time to tell the longer arching tale. Closure came to us late in the game, where folks are often perceived to be in their camps. I love JavaScript because it allows a diverse group of libraries to do what they do best. Developers and designers can find what suits both their personalities and their particular project.

If someone asks me (and they often do) “Which Ajax library should I use?” there isn’t a simple answer. It is nuanced. It is complicated. It is frustrating! How many of you have even changed libraries in a project? It is embarrassing to go back in time and see what happened with Bespin. At various times we had MooTools, Prototype, Dojo, and SproutCore. Is that productive? Obviously no.

You build many things on the Web. A web site isn’t a web application, and then blend together so you often can’t tell when you go from one to the other (and it doesn’t of course matter at all). jQuery has made a living starting out as a fantastic DSL for sprinkling behaviour onto web sites and going from there. SproutCore and Cappuccino are the other extreme, and Dojo was the kitchen sink of JS development a long time ago. Speaking of Dojo, I really wish that Dojo and Closure had collided a long time ago. I think that it would have benefitted both sides, even though I know that it would have added some overhead for both too. When you are on an internal framework it is built for your needs. If you take a look at the Closure components they feel very Googley out of the box. At the end of the day though, Dojo and Closure are so similar in many ways, that having them joint at the hip a few years back would have been really exciting. C’est la vie.

One tricky thing about Closure is that you can’t look at all of the widgets and packages equally (same for most libraries to be fair). Some are battled hardened to the hilt as they are on important production systems acting as core functionality. The keyboard handling and localization support is top draw. Others may be cool but placed in via an interesting 20% project that isn’t as mission critical and hence battle hardened. Not all code is equal. In fact, I find the line by line code criticism tiring. It is so easy to take someones code and find fault with it (at least perceived fault). I am sure there is bad code in Closure. That is true for all code. It is much harder to be a creator though. Don’t get me wrong, it is good to point out potential issues, but there is a big difference between:

“I noticed that code X does Y. I think there is a bug there that would affect ….”

and

“Code X SUCKS. Mwhahahahahah. SUCKS!”

My new years resolution for 2010: “Say *sucks* less”.

The criticism that made me laugh hardest was the assertion that the Closure engineers were Java folks who wanted JS to be Java. They are far from it. They are old school JS engineers who have done amazing things on the Web and have just learned a few things along the way as they build huge scale JS systems.

Google is of course a big place with engineers with opinions :) When you have the creators of various languages and platforms under one roof that is always going to be the case (From Python to C++ to Java to Go, and then Closure, GWT, etc on the JS side… even jQuery ;). Many of the frontend engineers aren’t fans of Closure (as in: doesn’t fit them) but they do understand where some of the strengths are. Some of the engineers have even weighed in:

NOTE: The following quotes were taken from a Facebook comment stream. There is context missing (for example, Joel talks below about how he didn’t use the term ‘natives’ for example

Joel Webber, GWT guru: “I’m unfortunately not too surprised to see self-appointed “Javascript natives” pissing all over Closure, because it tells them something they don’t want to hear — namely, that you can’t get enough optimization leverage on large applications without some constraints on your code’s structure. The kind of stuff that you see in many Javascript libraries (e.g. lots of dynamic tests to figure out what to do in a function) pretty much guarantees that you’ll have an unoptimizeable mess.”

Gavin Doughtie, Dojo and Google Photos: “As one of the Javascript natives, I must say after three years of using Closure that it gives you a nice split between development-time dynamism and deployment-time optimization. I have found few Javscript idioms unavailable to me when coding, yet still benefit from static checking and optimizations once I’m ready to ship.”

I am more of a JavaScript native than anything else. I am not going to be rushing to use Closure on a project any time soon. It doesn’t fit many of the projects I work on to be honest, and it doesn’t fit me as well as some of the other libraries.

That being said, I am thankful to Google for putting this code in the commons (and the fantastic tools around it!) so we can all check it out (and some of us use it). I hope that the hard part of open sourcing a project kicks in and we see a community form around it, including taking in contributions. I still also harbor the hope that Dojo and Closure joined forces, but that is hard to do (a lot of people using both code bases!)

When it comes to getting closure, I hope that you don’t jump to the extreme and ignore and abuse it, and I also hope that you also don’t think that you SHOULD use it without checking it out and understanding the tradeoffs.

For example, this is crazy:

“I hate to admit but I “might” have switched from jQuery to Closure strictly because of the Google brand.”

Roundup on Closure

• Erik Arvidsson, founder of Closure, awesome JS hackers, on the history
• Alex Russell, founder of Dojo and Chrome Frame
• Dimitry presentation on JavaScript libraries
• Google Closure: how not to write JavaScript
• Learning Closure with goog.net
• Inheritance Patterns in JavaScript

When you think of a Web application, you think of going to an HTML page that then loads scripts and resources to display functionality. Applications in general do not always fit that model. If you launch an “application” like Growl on the Mac, a window doesn’t launch. It merrily kicks off a service in the background.

The same is possible in the world of webOS and browser extension systems. One of the user experiences that I enjoy on webOS is the notification system. Non-modal, and any application can tie into it. There are various levels of notifications:

• Banners: Thin bottom line one liner that appears quickly
• Icons: Notifications are grouped together in time
• Dashboards: Larger areas. A DOM window so you can put controls in there. For example, the media dashboard lets you play, pause, etc.
• Popups: Even richer larger actionable areas

More on these notifications in another post. If you have an application that wants to tie into the notification system you can do so even if a window isn’t open.

I wanted to find out how to do this, and luckily Mitch Allen has a simple example of this in his RSS News application that he builds in his book on Palm webOS.

I hope to offer a simpler API specialized for this, but it is quite trivial to do thanks to the Power service. The timeout service is located via palm://com.palm.power/timeout and there are various properties that you can pass in to do the real work when you are woken up. What application should be opened? What task should be run when opened? That is all tied in via the application manager service (e.g. see the palm://com.palm.applicationManager/open service below).

The wakeup code in the news application is defined in the setWakeup method in the main application assistant (NOTE: assistants help with the controller part of MVC in Mojo):

// setWakeup - called to setup the wakeup alarm for background feed updates
//   if preferences are not set for a manual update (value of "00:00:00")
AppAssistant.prototype.setWakeup = function() {    
    if (News.feedUpdateInterval !== "00:00:00") {
        this.wakeupRequest = new Mojo.Service.Request("palm://com.palm.power/timeout", {
            method: "set",
            parameters: {
                "key": "com.palm.app.news.update",
                "in": News.feedUpdateInterval,
                "wakeup": News.feedUpdateBackgroundEnable,
                "uri": "palm://com.palm.applicationManager/open",
                "params": {
                    "id": "com.palm.app.news",
                    "params": {"action": "feedUpdate"}
                }
            },
            onSuccess: function(response) {
                Mojo.Log.info("Alarm Set Success", response.returnValue);
                News.wakeupTaskId = Object.toJSON(response.taskId);
            },
            onFailure: function(response) {
                Mojo.Log.info("Alarm Set Failure",
                    response.returnValue, response.errorText);
            }
        });
        Mojo.Log.info("Set Update Timeout");
    }
};

Mojo applications have a certain lifecycle and your application will get callbacks for setting up, shutting down, activation (when you come back to a scene), deactivation, etc.

Thus, you will see that setWakeup is called in the main AppAssistant.prototype.setup and when the application is launched AppAssistant.prototype.handleLaunch.

Anyway, suffice to say, having a lot of fun digging into webOS.