NoionLabs - Appropriate Technology

What You Should Know About Tech Talent

By talent I do not mean latent or natural ability to do something as in some people have talent and some people don’t. While I think different people posses different abilities & potential from birth, what really counts is how someone has developed their innate ability.

What I mean is the people that have worked hard to grow their ability, and more specifically I mean software engineers, programmers, & developers. Though I think much of this applies to other information technology fields as well: project managers, designers, system administrators etc, it is developers that I observe, interact with, and hire the most.

Expiration Date

You should view all technical talent as having an expiration date. The median time spent at a company is between two and three years. Why? If they have enough curiosity, and drive to continually grow their ability, they will outgrow the company. If they don’t grow their ability, technology will move on and they will no longer be a fit. An exception to this might be if your company is growing very quickly, but only if you can avoid becoming bureaucratic. Bureaucrats and makers don’t mix and while the technical challenges may be there, the bureaucracy will chase away the skilled people away.

Averages

It is hard to beat the average. The larger you are, the hard it is. Better to create a system in your company to produce great results, with average inputs. Therefor even if you could find above average people, and retain them for much longer than average (which you should try to do). You should make a plan where above average inputs to your system, or above average results are, well, above average, something extra, not have them be a requirement for your business to function.

Compensation

The market for skilled people is much larger than the number of people availble to fill it. This means that at present, and for the foreseeable future, it is a sellers market. Please understand this, it is a different dynamic between employer and employee then has existed in many industries for a long time. If you have a chronic under staffing problem, look here first.

There are many forms of compensation. Appreciation, flexible schedule, ability to work remotely, the company’s mission, esteem from an elite team, stability, fairness, vacation time, and in last position: wages, health insurance & perks like the company discount or gym membership.

One of the problems with companies that believe they are in the strong position, that believe they are the benefactors, and that employees should appreciate their favor, is that it destroys the other benefits. If you are in such a position of power, would it be honorable or wise to use it that way? If you work for an employer that acts that way, should you stay?

How much should you pay? It depends, on where you are at, how specialized your needs, how much of your team will be remote. Start with the bureau of labor numbers, remember that they are an average and that you don’t want average, then if you are in a higher cost of living area, add on a percentage to compensate. These are rough numbers, a local recruiter, or trying the market will give you a better idea.

Value

Talent which is a great fit for an organization, makes a big difference. For many businesses a 10-15% variance in the business’s performance is the difference between great, and going out of business. The difference between developers is regularly on the order of 10x, some estimate it as much as 100x. At the low end I’ve seen it mean the difference between building something in two weeks instead of six months, and at the more extreme end, between a smooth implementation, and never completing. Given these numbers, it would be hard to over value, or over compensate, great talent.

Grow if you can, hire if you must

It is hard to find great talent. There isn’t enough to go around. It is also hard to find people that are a match for, or who can improve your team culture. Once you do, you still have to bring them up to speed on how your team works, what your business is, and your existing code base. Hiring is expensive. It is much more cost effective to grow the ability of the existing members on your team. Create (by giving permission, and rewarding) an environment where senior members of your team are always teaching, always mentoring, and where everyone is perpetually learning.

If you don’t believe in someone enough to invest in them, don’t hire them. If you have already hired them, fire them. If you have team members left, start investing.

Rockstars and Ninjas

Everyone wants to find an ace, a “rockstar” or “ninja” that can pull off projects in record time, who cuts through delays like a hot knife through butter, and that never comes to management with “trade offs”, bugs, or complicated technical jargon. Mostly these people don’t exist. Really talented people do exist, are wonderful to work with, and can pull hard feats off. If you find one, listen to what they tell you, and reward them well. Hard problems only yield to talented, hard working teams, where the business people and technologists can work together.

– Jordan


People are Happy when they are Effective

When you first start practicing anything new, there is an initial novelty, a joy of discovery, and then, just as certainly there is a period where practice is work. It doesn’t matter what the subject matter, piano, riding a bike, Latin. Many people give up at this phase, mistakenly thinking that they aren’t any good at it, or that it just doesn’t fit their brain. In actuality this is a step everyone goes through, it just matters whether you keep going or not. It is work to master, or to begin to master anything worth doing.

If you keep pressing on, you will gain competency, and with perfect practice and sufficient time, mastery. There is much to be said for the rule of thumb that master in anything takes about 10,000 hrs.

What is just as interesting is that anything at which you are very good, you are likely to enjoy. Even if you hated those piano lessons your mom made you take, if you kept on taking them and gained competence, you are likely to enjoy playing. Competence doesn’t guarantee that you will enjoy the activity, but it does greatly increase the likely hood that you will. If we take effectiveness to mean that you are good at something, and that something matters, then you are almost certain to enjoy it, and doing it will increase your happiness.

Software development is notoriously hard to measure. We approximate it with lines of code, number of defects etc. But we know these measurements lie. The best engineers will produce much more functionality per line of code. Code you can avoid writing altogether doesn’t have bugs. The difficulty of implementing a feature varies widely, and hence the number of defects produced. Some features are never used by anyone, while another can save a business. Quantitative analysis of who is actually being more productive usually costs too much to do, and even if you could determine by the numbers who is being the most effective, the analysis would likely leave no clear guide how to help the low performers improve.

There is a simpler, better way: Optimize for programmer happiness.

It really really matters, and can revolutionize your team. It is the best guide to identify top performers, and to know what to do to increase productivity. If you don’t believe me have a look at how software companies die (it’s a good read, even if you do believe me)

As a side note, the happiest programmers I’ve ever seen are those in the emacs & Ruby communities. I think they are both very effective, and tend not to take themselves too seriously. Something for the Clojure folks to think about.

– Jordan


Permission, Fear and Innovation

fear

As a discipline we fear Object Oriented Programming (OOP), in the third sense of the word, and we fear breaking from the OOP tradition in the prior senses. And it is damaging our ability to innovate and to build better systems, and to grow beyond the best of what is currently known.

OOP has so long been “the right thing” that speaking critically, particularly with the degree of criticism that it likely deserves, will quickly get you written of as inexperienced, or a crank. There are no silver bullets that will cure all software development ills, and you will still be writing classes and using objects, but it would be better to limit classes & objects use to where they fit, and use other styles (especially functional and logical programming) where they fit.

It does matter. Software is changing the world, but making it is expensive, and maintaining it is even more expensive. OOP solutions are larger, harder to understand, harder to change, and harder to maintain.

I think one of Clojure’s most valuable contributions to the field is the permission implied by it’s success. It works. People are using it to build impressive things, with few people, on tight schedules and budgets.

Embrace the “odd” ideas of functional programming: immutability, minimize state, use built in data types where they serve well rather then creating your own (via classes) for each restatement of an old problem you encounter. Choose simplicity, choose fewer data types, and more functions which operate on them.

It is important to practice. In Japan the automakers have found that they cannot build better automotive fabrication robots, because no one knows how to make better cars then the robots do. The masters which have their 10,000 hrs of practice in, and which the robots are designed to imitate, have retired, or died. If you aren’t practicing the best that you are aware of, you aren’t ready to move onto the next step, and you certainly aren’t ready to push the state of the art.

Use new techniques, then let others know about your experience, so they can have the permission to know that non-OOP paradigms work and can they can try it them too.

I must not fear.
Fear is the mind-killer.
Fear is the little-death that brings total obliteration.
I will face my fear.
I will permit it to pass over me and through me.
And when it has gone past I will turn the inner eye to see its path.
Where the fear has gone there will be nothing.
Only I will remain

– Frank Herbert in Dune

– Jordan Schatz