“We’re having a hard time filling this position”

Mythical-Man month issues aside (adding people to a late software project makes it later), there are times when you just don’t have enough people to get the job done, so you’re trying to hire more developers, and it’s just not working.

I could write for days on this subject, both as a former hiring manager and as a developer with over a decade of experience evaluating companies.

Dan Luu, someone who is known for treatises on tech, wrote a piece that is especially relevant to this problem. Take some time, and read it. It largely mirrors my own experiences. Here’s what I would add to it for this audience:

1. If you want young developers without a lot of experience, focus on the glitzy: Free food, foosball tables, happy hours.
2. If you want experienced developers who are good at what they do, focus on the mechanics: developers pick their own computers and work equipment (any price under 10K), developers have quiet working conditions, developers get paid training and conferences (no hoops). This is an especially inexpensive way to lower turnover as well.
3. If you want bottom-line focused developers, focus on the how developers interact with the business: Do they sit in client meetings or have discovery sessions with clients? Or is that walled off from the development team? Do they have KPIs/OKRs that are about the business’s work? (For instance, Initech’s software team is judged by the retention rate of their SaaS product) Or are their KPIs or OKRs focused on developer issues? (Initrode’s software development team is judged by how many bugs are found, or how many features are shipped). Business focused developers will help you improve your retention rate.

This post originally appeared in my daily email newsletter. If you liked it, subscribe below.

Developer Affinities

We’ll say (jokingly) that developers are interchangeable, that if you lose a developer today you’ll be able to replace them with another with little or no change.

For something like construction, that follows a well-defined standard (every stick-built house will follow the same builder’s code), software is a bit more… loose in its standards, which allows for more variability in what a developer understands and is good at.

This leads to developer affinities — based on a developer’s career and their interests, they can wildly diverge from another developer of the same programming stack.

I know a guy, he’s a systems guy. He believes strongly in systems thinking and the Theory of Constraints. I wouldn’t ask him to design and implement a user facing feature, but I would put him in charge of any messaging or queuing in our system, and I’d also ask him to champion Continuous Integration/Delivery because he has an affinity towards that.


Every workplace has one of these, but I also knew someone who was spectacular at solving hard problems in the system. They weren’t ever going to be on the critical path for a release, but they’d get every hard production problem we could give them.

Neither of these developers are interchangable. If they were to leave finding a ‘hard problems’ person or a ‘systems thinking’ person is tough — and finding developers is tough enough for businesses. Nor could one swap for the other without things moving more slowly.

Until software development becomes rote, that will continue to be the case. It’s also why judging programmers against their peers can be fraught — no two programmers took exactly the same path and exhibit the same level of knowledge or affinity.

As a manager leading a team towards delivering value, finding out the affinities developers have is a good first step to maximizing everyone’s productivity and happiness.

Today:

– Think about the developers you work with. Where would they excel? would it be in developing CI/CD pipelines? optimizing the system? Writing back-end features? Focusing on user-facing design and those features? Do they have a knack for fixing bugs in a certain area of the system?
– Are they currently working in those areas? If not, why not?

Make it work like excel does

“Make it work like excel”.

I’ve heard this quite a bit from non-technical managers and (and even some technical ones). You can point to many features of excel that businesses use day after day to do large tasks. Excel powers businesses because you don’t have to be technical to master it, and it has 20+ years of documentation and “How do I?” covered.

From the software perspective, make it work like excel, is akin to asking your everyday development team to learn how to scale Mt. Everest — that’s the scale of the difference in saying it vs doing it.

I use excel as an example because you’re probably familiar with it; but the same example could be used for any commercially produced movie, TV Show, or piece of software.

The part hidden to us is that millions of dollars and years went into making the first version of excel — and they’ve had over 20 years to improve excel.

In instances where business people wanted me to ‘make it work like excel’, I’ve had more success stepping back and figuring out the business behind the spreadsheet.

Why is excel being used? Is it for data entry? Manipulation? Complex formulas? replacing rote text? Why is it there? Figuring that out then shifts the conversation from replacing a spreadsheet based workflow with a crappier spreadsheet-looking workflow to implementing a workflow that captures the essence behind why the spreadsheet was necessary in the first place — and that doesn’t take millions of dollars and 20 years.

I’m interested to hear from you on this: What do you use excel for in your business? What manual processes does it replace? Are you happy with it?

Sometimes the Inmates are running the Asylum

Do you ever get scared when developers come back from conferences? I do.

How many times have you’ve had a developer come back from a conference and say, “We should use framework X to build this?”

Recent examples would be, “We should make this into microservices” or “We should use Kubernetes”, or “We should write this new front-end in React.”

There’s a lot to unpack behind this, and I’ve been a part of numerous projects where this was necessary, and even more projects where this torpedoed any chance we had to meeting the expected business outcomes.

Corey Quinn, author of Last Week In AWS, speaks of this phenomena in his talk “Come Scale Away with Me: Solving for problems you don’t have” and its often negative effect on development teams and businesses.

Adopting new frameworks can be critical to the longevity of a business’s software, but those times are few, and the inflection points are often telegraphed (Microsoft has indicated all new development should target .NET 5 (rebrand of .NET Core), so if your business is running on ASP.NET 4.x, you’ll have several years of support ahead of you, but you should start considering moving off of ASP.NET to ASP.NET Core).

Framework changes are akin to tearing down and rebuilding a building. It may be necessary, but is a large capital expenditure and should taken with the same seriousness that building a new office building would be.