Month: October 2017

Walking into an interview, you are almost always self-absorbed. You imagine the people on the other side of the table have all the power and somehow are looking at you to see if they can grant you some kind of favour.

This is never true, speaking from the other side of the table, its tough. You are not running this interview because you had nothing else to do with your time. Chances are you need someone to work on your project yesterday.

Furthermore, it’s fairly easy to gauge if the company will be a good fit for you, services like Glassdoor offer a window into the company culture. From a hiring perspective, most of the time a CV and linked in profile is all you have to go with.

In this situations, recruiters tend to substitute the hard problem of determining if a candidate is a fit with other easier to answer questions.

Of the many assumptions, in this entry, we shall be exploring the most common.

How well does the candidate do on aptitude tests?

Aptitude tests are by now an industry standard. They are the modern version of the IQ test.

To be fair, high IQ is a major predictor of success later on in life. Individuals with high scores tend to more easily grasp new concepts and apply them in practice. My argument then is not against IQ tests but against using them as the sole measure of capacity.

You see eventually it gets hard. Sure natural talent will help you breeze through the basics of the language and the framework, but no amount of it will make your first true mess up any easier.

In the office, we were discussing the intricacies of software development and whether it really is a high IQ sport as its touted. We concluded it wasn’t, 90% of the time, the work is processing simple inputs from the user and triggering the right events. As Thierry Schellenbach from Stream puts it

For many applications, the programming language is simply the glue between the app and the database

Then perhaps you should not be as worried about how high the IQ of the candidate is but how well they are able to understand and interpret your client’s needs.

Do I like this person?

Usually, this question is masked as “Are they a culture fit?”. Formally known as the Halo effect, we naturally drift to individuals we like.

Now, the good engineers I have met care a lot about their craft, not so much how symmetric their face is. By being ignorant of the fact you are actively biased towards likeable people, you may lose out on great talent.

This is where stereotyping happens. Take the unspoken case of ageism, it is far harder to be trusted as a developer once you hit the 40s. Somehow, coding has been taken as something only young people do. Thus when a middle-aged person walks into the interview room, your mind starts looking for signs something is terribly wrong with them.

For those who imagine they are somehow immune from this effect, think again, no one is. The bias is hardwired into your brain, you must then design your recruitment process to remove the bias.

How many twitter followers does the candidate have?

Sounds kind of stupid when read aloud doesn’t it? Yet this seems to be routine in a recruitment exercise. So much so almost all CVs I now see have a link to the candidate twitter profile.

I honestly have no idea why this happens, my best guess is a big followership implies others have also validated the talent and so you follow suit.

A friend of mine actively filters out candidates with an average of more than ten tweets per day. He reasons anyone who can afford to sink that much time into Twitter is not likely to be working on whatever they are actually paid to do. I don’t actively support this position but I think its worth some consideration.

What is their presence online?

Building a personal brand is very important, you should try to at least have content you control on the first page of the search results for your name.

This doesn’t mean you dismiss individuals who are not as adroit in the art of personal promotion. Maybe they just don’t like writing about themselves.

Open source software is great, but it’s not a requirement for you to contribute before you earn your stripes as a software engineer.

Have you ever experienced any of the issues mentioned above? Talk to me in the comment section below or on my twitter @jchex

 

 

While for now am not as active in the software consulting game. I have been there enough to come across the perils of overrefined plans. This issue primarily has come up as an artefact of how most westernized countries do work, through contracts.

A contract is a binding agreement between two or more persons or parties; especially :one legally enforceable

Now contracts and especially written ones are great, they have certainly played a key role in the formation of the economy as we know it. Yet their traditional use as loss prevention tools doesn’t auger very well with what we now know about software development.

What you find is the client what everything to be developed in written form and in great detail at while at it.

This is a bad idea. In this entry, let’s look at why detailed contract and detailed plans, in general, are a bad idea.

The future will likely turn out differently.

The art of predicting the future has a long and time honoured tradition of being dead wrong. Matt Nauvak has an extensive library of predictions made in the past and how they turned out.

The problem is when we think about the future, we simply imagine what we know today but in an exaggerated format. For example, the client imagines the application will have to handle thousands of query requests from sales managers who are looking to better understand their customers. This feature may be based on another plan to capture user activity within the application.

All this is well and good until we realize nobody wants to login to use the application and we now need to pivot! So there is no data to be showed on the beautiful dashboards to be used by the salespeople. Some time wasted, but still all good, the real problem comes six months later when the client once more wants their dashboard. You remind them you had a meeting and decided to pivot, they, of course, proceed to remind you meeting notes are not binding, contracts are!

I thus urge you, no matter how certain you feel about the project, bake within the agreement the provision things will change.

Decisions should be made at the last responsible moment

My personality registers as INTJ. One of our key strengths is the ability to make decisions quickly, as you already guessed it, this is also a weakness.

Plans are great because you are able to constrain the range of possible options and get everyone focused on one path. Swahili’s have a saying:

Kuishi kwingi kuona mengi

Roughly translated:

To live a long time is to see a lot of things.

This rings true in software. As your product unfolds more information comes to the foreground as assumptions get tested in the crucible of reality.

It would be terrible to ignore your insights because the plan you made one year ago is in contradiction to them.

Plans fail in highly dynamic environment

Homogeneity is great for some types of work. This tends to happen in routine types of businesses. To give an example, imagine the work of building an estate with fifty apartments all of the same design. There will likely be some surprises in the first few houses, but after that, you can make fairly detailed plans to take the remaining houses to completion.

Now imagine a software project, even if you were CTO at a successful startup say Stripe, if you then started your own business say Airbnb, you would still be encountering surprises every day. In fact, even if you stayed at Stripe, new technology say bitcoin, would still keep presenting new and surprising information.

Fighter pilots have a term I particularly like. OODA

Observe Orient Decide Act

The world changes, OODA loop makes sure we don’t stay stuck with our plans which are now irrelevant.

Avoid the trap of elegance

A common misconception is we love our children and that is why we give up so much for them. In reality, we actually love them because of all we have given up for them. Think about the concept of sunk cost fallacy.

Sunk cost fallacy: The idea that a company or organization is more likely to continue with a project if they have already invested a lot of money, time, or effort in it, even when continuing is not the best thing to do

Now, if you have ever been to a proper planning session, you know they can take entire days if not weeks. Once you have put in that kind of time, you generally don’t want to see it all go to waste. Your mind will play all kinds of tricks on you to ensure you stick to it.

Elegance is great, but as Reid Hoffman says:

If you are not embarrassed by the first version of your product, you’ve launched too late.

This is also true of plans if you put too much effort into your plans, its value is now lost.

Look through your own plans? Are any of them excessively detailed?  Talk to me in the comment section below or on my twitter @jchex

 

 

 

 

Some years back, Martin Fowler and Alistar Cockburn adapted the concept of ShuHaRi from Japanese martial arts.

At its core, it’s simply a way to think about learning.

The idea is that a person passes through three stages of gaining knowledge:

• Shu: In this beginning stage the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, he concentrates on just the one way his master teaches him.
• Ha: At this point, the student begins to branch out. With the basic practices working he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.
• Ri: Now the student isn’t learning from other people but from his own practice. He creates his own approaches and adapts what he’s learned to his own particular circumstances.

From this lens, you realize the sacred cows of your own agile practice can be criticized.

Is it really necessary to have a daily standup meeting which is physical every day?

Does your Kanban board really need to have all those lanes?

Must all pairs share a keyboard in your XP practice?

In this entry, we will look past the individual features of the specific agile methods and look more broadly at what unites them, what is their DNA?

Frequent delivery

The idea that final products should well, be final is a pervasive one. It’s one thing to read all about the benefits of iteration and quite another to have your boss or client scream at you for presenting a half-baked product.

Thus we build generous timelines to protect us, to allow to do all the work needed to ensure we present the product that is just right. We know when it’s not. There will be hell to pay.

Agile adopts a more evolutionary mindset, it advocates you ship what works, for now, gain feedback and improve on the product.

This is why Scrum, for example, insists on two-week sprints. There is nothing magical about the number, its simply meant to convey you are supposed to ship something, perfection be damned what we need is working software.

Communication

You may have noticed this, the speed by which a project is executed is closely related to how well everyone understands what is to be achieved.

Simon Sinek explains the concept quite well.

If you did manage to forgive the audio quality, you got the vibe, people respond to alignment.

You see communication, especially in software development, goes much deeper than sending and receiving of signals. It took me long enough to realize you can be in a meeting speaking where everyone else is only there physically appearing to be listening to you but lost in their own world.

To properly communicate, you must be able to externalize your mental model and have the other person internalize it. This, in my opinion, is best done when you work together on a physical media, say a whiteboard or a shared doc to express what you perceive. This back and forth helps expose any incoherence in your understanding of the situation.

 

 

Thus boards and other interactive information radiators in Kanban help the teams build a shared mental model of the work to be done.

Continuous improvement

The primary school I attended had an interesting motto:

Better your best

It has taken me all this time to finally appreciate what it means.

Continuous improvement is the idea there is always something you can improve. It doesn’t matter if you are a beginner or have thirty years of experience.

Integrating this philosophy into your mindset has two advantages.

First, you never settle, your product is always going to be improving. This is in line with the more general truth of impermanence, no matter how fit the product is to its market today, the market will change tomorrow. Thus you must continue to adapt.

Second, you get the validation to ship your product imperfections and all. After all, there will be a chance to improve on it later.

In agile practices, this principle shows up in retrospectives, where the team stands back at the end of an iteration and reviews its work searching for clues on what they could have done better.

If you learn nothing else about agile, learn this three principles.

What do you think is the unifying theme of agile practices?  Talk to me in the comment section below or on my twitter @jchex