"Four major disruptions drove this shift: Open source, the cloud, the Internet and seed-stage financing"
- The New Kingmakers, page 11
"What would happen if developers could choose their technologies, rather than having them chosen for them?"- The New Kingmakers, page 19
No, this doesn’t mean go out and buy a Foosball table. This means developers are happier when they’re working on hardware and software they like and have chosen. Stop mandating centralization of tools and standardizing. This doesn’t mean let the inmates run the asylum, it means, if you’re a CIO, the developers know more than you about how tool selection affects the products. Go talk to them!
As a newly minted MCP, I had easy access to an MSDN subscription. Reason being, my employer at the time was a Microsoft shop! The year was 1997, and the internet was relatively new, so I stuck with what was right in front of me.
The learning curve for setting a web server was fairly steep, Stack Exchange didn’t exist and Experts Exchange was charging for advice. I was basically stuck with figuring things out on my own within the constraint of the toolset my employer had. I didn’t have a choice.
Since I had access to these enterprise tools, I setup Microsoft Small Business Server 4.5 on an old PC at my house. Instead of relying on free email accounts, I setup my own domain, domain controller, and Microsoft Exchange Server simply to practice installing and configuring these tools.
A couple of years later that experience would come in handy as I worked as an independent contractor with a company that was building the backend infrastructure to support Harlequin’s newsletter engine.
Yes, that’s right. I created the interfaces to Harlequin’s Microsoft Exchange Server that would process out of office replies, and various other hard and soft bounces from people who were subscribed to their newsletter.
Man things sure have changed. Today instead of spending six months and hundreds of thousands of dollars to do what myself, and this organization, did with Harlequin, you can accomplish the same thing with a free MailChimp account.
The New Kingmakers describes precisely what I went through as a developer starting in the mid-90’s, to when I left development in the mid-2000’s. I still tinker once in a while to stay up to date though.
Today’s developers are becoming more “T” shaped, compared to when I was developing. I’ve worked with a few one-dimensional developers that worked only in one language, but for the most part, today’s developers are adequately skilled in multiple languages, using cloud services versus setting up their own infrastructure, and in multiple backend and front-end technologies.
This is largely attributed to the open source movement that arguably started with Netscape (remember them??) opened up access to the source code of their browser. Since then language after language has emerged, along with cloud computing services, like Amazon’s EC2 (2006) and various database technologies from MySQL to No SQL to Hadoop and more. I can’t keep up anymore!
The advancement of developer technology, low cost and easy access to developer communities, like Stack Exchange, has made it easy for anyone to become a developer.
The New Kingmakers describes how to find and retain good developers by focusing on letting developers choose their own technology stacks versus the old way of centralizing and standardizing.
So what would happen if developers could pick their own technologies? There are two main arguments against this.
First, it would be anarchy! There would be a hodge-podge of tools, and languages that would make systems too hard to maintain. Untrue! If developers are picking their own technologies, it’s because they’re familiar with them and passionate about them. They’ll be more likely to take and keep ownership of good code and better designed systems. The New Kingmakers describes fragmentation, which is a valid concern, but that problem is less about the technology and more about the decision and purchasing aspects of technology.
The second argument is, well, what happens if all the developers quit and the organization can’t find developers that know those technologies. If all of your developers quit at the same time, your organization has bigger problems. Second, if you’re worried about this, your organization isn’t one that would let developer choose their own technology in the first place.
From my experience, there is one major problem with optimizing for developer joy: Trusting your technology to someone other than the CTO, and management. If given too much power, some management functions become obsolete which is a scary proposition for some organizations.
The funny thing is, if your developer team is working on a $2 million dollar system, you’re already trusting them!
"Baby duck syndrome: The tendency for computer users to imprint on the first system they learn, then judge the other systems by their similarity to that first system"- The New Kingmakers, page 35
There’s a reason why the 43 year old developer you’re working with has created a monstrosity of infrastructure that only he/she can change. Developers, and people in general, create a strong mental connection with their first tool. They then measure every new language or tool with their first and it’s hard to get them to switch. Whatever technology stack you’re using, get kids in school using it. There’s less need to pry them away from their favourite stack if they’re already using it in school.
"Developers are increasingly putting their ability on public display via open source generally and sites like GitHub specifically"- The New Kingmakers, page 36
Stop with the CSV parsing code test! It’s easy enough to find a solution in every language on GitHub. GitHub provides algorithmic ranking of developers here.
I wasn’t aware of this until I read the book. I’ve always recommended to clients I coach to poke through any applicants GitHub repo to get a feel for what they are passionate about and what their code looks like, but I didn’t realize GitHub had an automatic ranking system!
The New Kingmakers accurately described my experience growing up as a developer in the ‘old world’ and the challenges I saw firsthand when PHP fired the first shot at big enterprise frameworks and tools.
