Not everything is awesome

I have a tendancy to use the word "awesome" too much. It's something which I think I need to try and control, but I don't have it as bad as recruiters in the tech industry.

To a recruiter or hiring manager, everyone they're looking for should be awesome. Or a rock-star, or ninja. The Financial Times has been looking at the way they recruit and in particular to the diversity of applicants that they see applying. What they found out isn't really a surprise.

It was pointed out that people who perhaps are nervous of their capabilities or their potential, might find it off-putting that we were potentially a boiler-house of pressure to constantly excel, which we’re not. As the first line of a page trying to sell jobs at the FT, it seems to prioritise performance above all else.

In fact, someone might be the very best engineer in the world, but I wouldn’t want to hire them if they have a lousy attitude to collaboration, a superiority complex or no interest in the product.

It's great that they've taken the feedback onboard and updated their job listings. It also looks like it's having the desired effect.

Why Working at Google Is Not My Dream Job (Anymore)

The problem is not the fault of the excellent people that Google employs, but rather the creaking, rambling structure of their hiring process. Why is the whole process so obfuscated?

A first hand account of an applicant explaining why getting your hiring process right is so critical. With so much competition for tech jobs, it's important that from the minute an applicant contacts you, you better get it right.

I Liked Everything I Saw on Facebook for Two Days. Here’s What It Did to Me

Messing with Facebook's algorithms produces some interesting results. In particular, the fact that the algorithms at Facebook decide that it's more "important" to show you marketing and link bait on mobile than updates from real people.

My News Feed took on an entirely new character in a surprisingly short amount of time. After checking in and liking a bunch of stuff over the course of an hour, there were no human beings in my feed anymore. It became about brands and messaging, rather than humans with messages.

Java Developers

An interesting insight into what it's like to develop software using Java.

A lot of people say Java is a terrible language. I disagree. Java has its faults, but I think when you look at what it is in particular that ticks many people off it’s not the Java language per se, but the way it’s used.

The biggest problem I’ve encountered over the years looking at Java code is that it always seems to be the product of someone who fancies themselves as an architect.

I've seen code that backs up this argument, with abstractions on top of abstractions. Sure it's hard to follow, but after some time there are usually logical reasons why these abstractions have been applied. Where there aren't is down to code being developed by bad developers.

Let’s be frank - much of the Java code that you might see in the wild is the product of very low quality developers.

With the enhancements in Java 8, I'm really interested to see how the landscape changes and whether the situation improves.

Dear Foursquare

But now, now you’ve failed at everything you were once good at. You didn’t stay true to your roots. You doubted yourself in your middle age. You added cruft and extra dialogs and eventually took that to a whole new extreme, forcing me to install a whole new app just to check in. That would be fine if Swarm had been brilliantly conceived, svelte in aesthetic and incredibly robust.

Sometime ago I stopped using Foursquare, and I've never really felt compelled to go back. It doesn't sound like their multi-app strategy is working for them, and I wonder how they're going to develop over the next year or so. I already see them slipping from relevance and I think that we'll continue to see this trend.

It's disappointing, but I think it's inevitable.

McDonald’s Theory

It’s as if we’ve broken the ice with the worst possible idea, and now that the discussion has started, people suddenly get very creative. I call it the McDonald’s Theory: people are inspired to come up with good ideas to ward off bad ones.

Sometimes you just need a starting point, and a bad idea is as good as any other when you need to get started.

Scrum Master 2.0: A Scrum Master is Not

A Scrum Master should be:

A constant role that is temporarily held by a person (weekly or even daily basis)

Fulfilled by all members of the team, in turn, in cycles, so that they learn to deal with outside interference and grow their skills of working within an organization

The person that does all the "dirty day to day minutia" that keeps the team from doing their stuff (paperwork, meetings etc)

Roy Osherove gets it absolutely right. We use a scrum master 'hat' at eBay and although the current wearer has had it on their head for a while now, rotation is encouraged. One difference we do have is that our scrum master also plays the role of an agile coach for the team, identifying potential improvements to the way we're working.

Technical Debt Quadrant

A couple of nice articles about Technical debt.

In "Technical Debt Quandrant" Martin Fowler describes a model under which aims to classify the technical debt that is created during development. I'd like to think that the technical debt I create will mainly live in the top right Prudent-Deliberate box. I know that this has not always been the case though!

Technical Debt should be reserved for cases when people have made a considered decision to adopt a design strategy that isn't sustainable in the longer term, but yields a short term benefit, such as making a release. The point is that the debt yields value sooner, but needs to be paid off as soon as possible.

This lead me to an older article "A mess is not technical debt", by Uncle Bob, which describes what technical debt is, and more importantly what it isn't.

A mess is not a technical debt. A mess is just a mess. Technical debt decisions are made based on real project constraints. They are risky, but they can be beneficial. The decision to make a mess is never rational, is always based on laziness and unprofessionalism, and has no chance of paying of in the future. A mess is always a loss.

The 10 Algorithms That Dominate Our World

The importance of algorithms in our lives today cannot be overstated. They are used virtually everywhere, from financial institutions to dating sites. But some algorithms shape and control our world more than others — and these ten are the most significant.

A nice list, but in reality they're not what I really understand as algorithms. Instead, it's more like 10 features of websites and apps that are very popular.

So what are the 10 algorithms that dominate our world? Well Marcos Otero describes what he thinks are the most important in his medium post, "The real 10 algorithms that dominate our world"

Now if you have studied algorithms the first thing that could come to your mind while reading the (io9) article is “Does the author know what an algorithm is?” or maybe “Facebook news feed is an algorithm?” because if Facebook news feed is an algorithm then you could eventually classify almost everything as an algorithm. So I’m going to try to explain in this post what an algorithm is and which are the real 10 (or maybe more ) algorithms that rule our world.

How a password changed my life

Seeing how these positive affirmations and reminders helped me to materialize my monthly goals kept me motivated and exited. I’ll admit this: It is difficult to come up with your next goal. Sometimes it’s hard to identify what we need to change, or where we need to walk towards to.

In its simplest form, a password enables you to get somewhere, in your digital world. Say, to copy a file, to unlock a computer, to email somebody. This feeling of micro achievements, this thought of ‘my mantra helps me to get things done’ can build up a momentum that motivates you to stay focused on achieving your monthly goals. It’s a tiny habit that transformed me.

An interesting idea. Using a password, something you enter many, many times a day, to re-affirm a habit. Habit tracking is something I've started researching recently on the back of an Android App I'm building to learn the platform. I'm not sure whether this method would work for me, but it's something I'm willing to try.

The Cornish beaches where Lego keeps washing up

"These days the holy grail is an octopus or a dragon. I only know of three octopuses being found, and one was by me, in a cave in Challaborough, Devon. It's quite competitive. If you heard that your neighbour had found a green dragon, you'd want to go out and find one yourself."

Lego is being washed up around the Cornish coast from a ship-wreck that happened in 1997. Ironically, a lot of the lego is pirate themed.

[DEX] Sky’s the limit? No, 65K methods is

It happens in the blink of an eye. Before, you are an happy Android developer, head down on your (or your company’s) application, adding the coolest libraries to provide more functionalities and to write simpler code. Afterwards, you stare at the dreaded output that states:

Unable to execute dex: method ID not in [0, 0xffff]: 65536 Conversion to Dalvik format failed: Unable to execute dex: method ID not in [0, 0xffff]: 65536

And you are stuck, unable to create the DEX file for the APK. You have no idea of its meaning, nor the slightest clue about how to get around it. All you can do is going all in for the most logic option: panic.

It seems surprising that this isn't going to be fixed in ART (the new Android runtime). It's also surprising that Google isn't helping here by doing the unbundling of the Play Services dependencies to allow users to pick and chose the parts they want to use in their applications.

Why pair programing is as much about business continuity as it is about code quality

The common negative response to pair programing from management is “I can’t afford to use two people to do one persons job” . As developers our common reaction to this is to explain how pairing can be faster, result in less bugs etc. This is understandable as these are the benefits most obvious to developer. But I would argue that it is business continuity that could be the killer argument for pairing.

Quality isn't the only reason for pairing, as Dave Hownslow points out at Think Foo. Building software as a team is important, and will generate better results if done properly. Being the "Lone Wolf" developer is no longer a real option if you're working as part of an agile team.

Bits, Clumps, and Just Right

One of the most common "moves" as a software designer is to take what was one element and divide into two or more connected elements... Some separations are helpful and others are not. Here is a framework for evaluating partition decisions.

Kent Beck reasons about dividing up software and the impact of making these decisions.