Doing everything (TLDR: you don't have to)

I am the kind of person, who wants to know everything, and I dispute that "wanting to know it all" and being a "know it all" are the same thing.

This is not a negative trait; it is good to be curious about the world, but especially about things that fascinate you and things that in your area of knowledgeable remit (e.g. your job, your hobbies, lolcatz).

Problem is that it is impossible to know everything. Even if you know it, you get to a point where it is impossible where you can do everything.

I think this is a lesson that all entrepreneurs learn:

• You can set up your servers on AWS yourself. 
• You can  write the RDBMS.
• You can  write every line of code. 
• You can  design a logo. 
• You can  set up Maven for all your projects. 
• You can  set up your own issues database. 
• You can  do anything... (if theoretically required).

You can spend all of your time doing all of the things, of course you can, you are interested and intelligent. You may have done similar things before and you think it is probably within your best interest (and cheaper :-\ ?) to do it all yourself.

Let us assume for a minute that you don't have the unlimited time or capacity as a human to run for 25/8 and you come to the realisation that just because you can doesn't mean you should.

It is at this point you start to look at  employing other people, or at least employing different techniques for deployment and this is what the smart entrepreneurs do.

With a slight alteration, I think this xkcd strip explains it much better than me:

Replace "Smart Engineer" for "Smart Entrepreneur" and in the last cel "build" to "get"

Image Credit: http://xkcd.com/670/

Yes, I am stating the obvious.

But by doing so is to illustrate that "knowing something and understanding something are very different realisations".

My interview experience with Justin.TV

WARNING: This blog post it not a typical rant about how BAD a hiring process is (cite: millions of anti-Google interview blogs).

Recently I applied to Justin.TV with zero expectations, so much so that my "covering note" was written in a very unprofessional way in which I did not attempt to sell myself in any professional capacity other than fun, in essence I was just being myself.

You can therefore imagine my pleasure when I got an email from someone at Justin.TV with an equally fun reply and saying that they thought my resume looked awesome and inviting me into the next stage.

The Challenge: there is always a programming test, to which JTV was no exception. Except they were, as their test was not a boring, repetitive, multi-choice web based test that had been copied directly from a Java programming certification book by Katherine Sierra, like so many recruitment "agents" perform. No, their test actually made me think! [insert shock here] It was an actual challenge!

I was going to explain the test in detail, but I don't think I will, in case someone applies and reads this, as I feel that the tests should remain unpublished - unless you already know the link of course ;). But suffice to say, I actually enjoyed it and the code I wrote I was proud of. I actually use the application I created almost daily as it is better than one of the software tools I have always used.

My first thought was to Google "how to do this", but I managed to stop myself in time. I realised I had a challenge that I should hit it in the face, I had become too complacent just Googling things, I never did it before Google so why now?. Secondly, at least that way I knew if I passed the test that I had done it myself and I would fully understand and be able to justify my design choices. After all, JTV won't be looking for someone who can just Google for a solution are they? (Answer: no they aren't, I'm sure).

At about 1am I submitted my application based on the given specification. I was pretty pleased with myself no matter what the outcome was.

A day or so passed and while I was coding some monotonously boring XML processing for my current job, I realised that I had missed something important. I could increase the efficiency of one of my algorithms substantially with just one line of code. Face palming, I waited until the working day was done and implemented the update, ran it though the test harness I had written, and it worked and it was even better.

Under the guise of iterative development I built v0.2 of my application and sent it off to JTV, expecting that my original solution had already failed to impress them, but I don't like to leave anything incomplete (even if I didn't know it at the time).

To my subsequent surprise, the next day I received an email saying my "problem solution looked good!" and they would like to invite me to the second stage of a phone interview.

Again, I don't want to give too much away about their process, but a couple of days later I get a call from another of their team and once again he was super friendly and really pleasant to communicate with. It was not like any interview I have ever had where the interviewer is almost suspicious of whether you can actually do what you claim.

Well this call lasted an hour and we actually had a good conversation and a couple of laughs and there was some coding involved. I suspect I probably talked too much and didn't code enough, but the guy was really friendly.

So from an application that had started as wishful thinking, I was now thinking "oh man, I really want this" and it wasn't because of the money, the perks or the prestige, it was because the guys seemed so cool.

It didn't take them long to get back to me the next day really nicely saying that they would not be moving forward with my application and this is where my only criticism can be levelled and it isn't that they didn't want me, they need to hire the right people, but it was that they didn't tell me why.

I have interviewed my share of developers and I have always told them exactly why I haven't hired them, always constructively. Perhaps I am different from other applicants but I would liked to have known what specifically wasn't right. Was it my skill set, my phone interview, something in my code or that I just wasn't the right fit for them?

I would have really liked to have known because I could have used whatever it was to improve my interview technique or my code, so I emailed them back, thanking them for their time and asking if they could tell me why so I could benefit from the experience.

I know they are busy, but it wouldn't have taken long just to provide a quick constructive feedback, but I didn't get a reply. I did think about emailing them again, but who wants to be a nag :\

So that is my good experience, and if you are thinking of applying to JTV my advice is to go for it and just be yourself, they are clearly cutting edge and clearly have fun at the same time. Just a shame I couldn't join them (I am in San Francisco later this year, so maybe I will pop in just for a gaming session with them) and I just hope all start ups are this cool and friendly if only for an interview :)

The problem with MVC [introducing Triple D]

Here is the problem with MVC; it is not fit for the purpose to which it is often misused.

I have had endless arguments with developers over what is the Model and what is the View and what is the Controller and where the line is. The problem is that line is obfuscated.

What is a "view" or a "model" or a "controller"? It should be pretty easy to define, but it simply is not. A database instance is a de facto example of a model (assuming your application has a database). But a database can also contain a view. Your GUI is a view, but it also has a model, but it isn't the model from MVC, it is simply the model of the GUI, and so on.

MVC is fine at a high level. We can say Apache Struts is MVC. An Architect can say here is the "Model" and this is the "View" and this is the "Controller". But at a granular level this becomes more complex to discuss in an MVC context.

At the lower Object Oriented level developers require a common language that help them identify specific classes and their purpose. Enter Triple D.

Triple D = Doing Data Display (DDD)

This is a way for developers to discuss and purpose lower level objects without getting confused with MVC terms.

There is much more to discuss on DDD, but the premise is simple: Every object in a system has a purpose. It is much easier to identify that purpose if you can quickly categorise that object.

Each level of either M, V or C can contain all three types of Dobject and by categorising the object in Triple D and documenting it as such, following developers can know instantly what additional things they should or shouldn't add to that object.

Objects can be one or two Ds, but never all 3. If you have objects with all three Ds then you have failed every aspect of Object Oriented Analysis/Design/Programming.

Example: An object provides a GUI button for display. By this we know that it has to be a Display object. We also know that it needs to display some kind of text which can be set to it, so it is also a Data object. Therefore, it should not be a Doing object as well.

Looking at existing GUI frameworks we know this to be true. When we create a button we pass it a listener (Doing) object that will perform some business logic when the button is pressed.

By sticking to the Triple D principle developers can easily communicate during any stage of development what  type the object is and isn't, without trying to apply MVC to low level objects.

Why Facebook is the next Yahoo!

I am not sure that I actually need to point this out because there is no chance I am alone in thinking that Facebook is quickly becoming the next Yahoo! for better or worse.

Let's examine the evidence:

• Fast growing.
• People are still suprised over it's success and speed thereof.
• Appears to act like it's the centre of the internet.
• Appears to be dominant.
• Appears to be extremely profitable in a short space of time.
• Appears to be at the forefront of web development.
• Appears to believe things will always be this way.

Everything listed above is exactly what was almost ubiquitously believed about Yahoo! back in 1998.

Yahoo! used to be the place to be, it was everything to everyone, had it all on one page and then index the "entire" web. Sure there were other competitors, but at the end of the day Yahoo! was king, and at the time very few people could have predicted it's fall.

Think about it, who would actually take on Yahoo! for web dominance? Even Mr Page and Mr Brin probably thought their little venture would end up selling to Yahoo! I can imagine the conversation:

L: Hey, we should do that idea for a search engine algorithm.
S: Yeah, but what's the point? No one will beat Yahoo! they are dominant.
L: Yeah but that doesn't mean we shouldn't try.
S: True, it could be huge and if not we could use it to get jobs at Yahoo!

Yes, believe it or not the founders of Google probably once dreamed of working at Yahoo! in the same way many now dream of working at Google.

Yahoo! probable seemed unbeatable and forever dominant, they had cornered the search and homepage market of the internet and I'll bet many executives and investors thought that too.

What were the odds that one of the biggest selling features of their destructor would come from the simplicity of Google?  Those of you who were there will remember the revelation on discovering Google for searching was that one of it's major appeals was speed. Speed it took to load the home page and speed it took to search. Google themselves were so proud of the speed that they announced it on every results page.

Facebook are looking at the same problem that Yahoo! did. The same problem which Yahoo! never recovered from. When you are the king, there is always a successor.

Speed on the internet isn't such a problem any more, unless you live in my house. But simplicity is. Credit to Facebook they have changed their layout several times and they persevered with change even in the face of user complaints. But it only takes one person to have an idea based on simplicity that Facebook will overlook for it to come crashing down to the floor.

I don't know what that idea will be, but history tells me that it will come as Facebook continue to become  Yahoo!. It is not so much a "maybe" as a "when". It is an inevitability.