Even though I modified my resume not to match laundry-list job postings I still receive emails from recruiters seeking things like this:

• 8 years working experience developing in JAVA with Microservices.
• Expert in Core JAVA / Spring Boot, Framework, Security, Cloud / Hibernate / Web Services
• Working knowledge of Apache Camel, JMS, JNDI, JUnit, and Cucumber
• Advanced knowledge developing REST APIs and micro-services
• Experience with relational, NoSQL, and event streaming database implementations (Oracle, MySQL, PostgreSQL, MongoDB, Cassandra, Kafka)
• Practical use of XML, JSON, XSLT

So, I guess seven years isn’t enough, eight is the magic number? What are they actually needing? What’s interesting to me is they don’t actually care about programming skills, analysis skills, design skills. What they care about are libraries and products.

It’s almost like what they want is: Coder, Java Enterprise, One (1) each.

Is that really what allows companies to generate extraordinary software?

No I in Team, Ordinary People Making Extraordinary Results

Apparently, programmers are interchangeable and the only distinguishing characteristic is the product list.

Let’s convert this into symbolics:

1. FS is a feature set that contains features F, where F is something like “Practical use of JSON”
2. PR is is the set of all people who claim to be programmers
3. FSd is a feature set “desired” by a team for a new team member

Any entry P from set PR such that FSd is a subset of FS(P) is suitable.

Let’s flip PR from programmers to baseball players. Let’s advertise for baseball players with feature set FSd containing:

• 8 years experience playing baseball
• Expert in throwing Rawlings baseballs, Louisville Slugger bats
• Working knowledge of batting lineups, Wilson gloves
• Advanced knowledge of hitting home runs and bunting
• Experience with running, sliding, and stopping on base
• Practical use of signals from coaches and pitchers

For some reason, I don’t think an arbitrary pickup team meeting that requirement would be as good as the Major League teams. But why?

It honestly doesn’t matter what domain one picks, people aren’t interchangeable.

Ever.

Well, Process Makes it So!

No, it doesn’t.

No matter how great the pages of a three ring binder are written, and no matter how zealously the ordinary people (who are still qualified as their FS(P) contains what’s needed in FSd) follow the procedures, different people still won’t get the same results.

If they would, then all fruit pickers or janitors would do equal work. They don’t.

Process has taken the place of “developing the people” since, courtesy of the process, anyone can do “whatever” it is.

How’s that been working out?

What’s funny, it doesn’t mater what the process is.

Waterfall takes a beating. It’s the go-to process for “bad process.” In all honesty, waterfall with an excellent team of experienced people will do better than agile with a team of less experienced people. I know, that’s not what we’re supposed to say. But I’m saying it.

The most common process I have seen in all of my thirty years of development is “ad hoc.” In other words, the teams may claim any process they want (and I’ve seen many processes and methodologies claimed) but in reality they “do the paperwork” with a nudge and a wink and write software however the hell they want.

It generally doesn’t work well for them, unless the people are capable of writing the software. If they are capable, they will find (amongst themselves) the way to work together to succeed. If they are capable, regardless of what process is thrust upon them, they’ll still work as they wish and blow off the process. Or pay lip service to it … and do their own thing.

Is this bad?

No, frankly, it’s not.

What is the purpose of a team? To accomplish its goals, or to follow a process?

I’ve never seen great results from a team focused on process. I’ve occasionally seen great results from teams focused on results.

What Can We Do Then For Staffing?

As painful as it sounds, that’s the wrong question.

I know people that I like to work with who I’ve been successful with in the past. If I’m seeking team members, I’m going to go to them again. If they’re not available, I’ll ask them for referrals.

It’s almost like finding team members is a social more than “automated matching” challenge. This is true.

It even makes sense. Because we’re not machines. We command machines. WE are people. Humans. Homo sapiens. We are living beings.

Those of you who want “machine with list of features” are going to continue making bad software and worse making your people unhappy and then you’re going to wonder why you have high turnover and miserable people.

I don’t like being treated like a computer. Do YOU??

Brian Jones