(Don’t forget to read Part II.)
The premise is not overly complex: there is a distinct difference between a well rounded software engineer and a programmer in professional settings. Sure, a software engineer programs – but the realm of tasks, responsibilities and aptitudes are quite different. I don’t meet many software engineers during interviews. I meet programmers. And it’s a shame.
The Programmer of Today
The work is on vertical, highly specialized (a.k.a. segregated) teams where tasks are finite. There is still a lot of magic at play to them, and in that way they are very close the the end user. Ask one of these specimens “how is your app deployed” and, often, you may see the shine of mysticism fog over their eyes as they consider the dark voodoo that happens by the operations team. They may speak of a “farm” or a “build team” – all external, fantastical and potentially dangerous. Much like primitive groups living outside of the bounds of civilization, these programmers live by what they can see, what’s been told to them via tribal knowledge and, are thus, deeply afraid of these operational mavericks who inhabit the other regions of an IT shop.
But, this is because they aren’t really engineers. They’re not really developers. (Don’t get indignant just yet.) Somewhere, they’ve lost – or never learned – the ability to think about systems. They just program. Allow me to demonstrate another case from an interview I was conducting.
“Tell me Joe, if I told you we had a 3-tiered system, what tier would you like to find yourself working in?”
“Tiers…what do you mean?”, Joe replies.
“Separating parts of a system. Think of them as layers instead if that’s easier…”
“A layer? N-tier? Database, UI, service, middle…”
Joe’s response, “Oh, the middle tier. That’s where I like to program.”
Which brings us to the fallacy of the middle tier.
The Middle Tier Fallacy
What I hear far too often from the poor soul sitting in front of me – who has spent too many years in a dead-end job doing data processing muck (yes, thank you recruiters for your accuracy finding candidates for a growing ecommerce shop) or the typically average programmer, is that they like the middle tier the most and that it consists of:
– class A
– another class , B, that has some calls to stored procedures
– A calls B
I lovingly refer to this approach as P.O.O.P – procedural object oriented programming and it’s definitely something junior enough I wouldn’t expect folks to bring up during an interview and almost entirely blows away any possibility of an interesting conversation.
What’s more interesting here is that what they describe isn’t even a tier, as in a layered architecture, but is just some code. Code, as in classes doing something – but that’s where they are. I’ve probed about taking A and B and invoking them remotely to some candidates. Unfortunately, at that part, I often here a response about “…in theory….”. The descriptions by these candidates of their (ahem!) middle tier work can range from processing XML to transforming a discrete piece of data from a loan application into a format to feed into the real processing system.
Why do they have this preference? It’s possible they have a mild case of Stockholm syndrome that has caused adoration for their boring job, employer and killed all motivation to escape. At the very least, it’s cognitive dissonance and epistemological arrogance. A coworker stated the problem better than I could after another “middle tier” candidate, summarizing their experience as:
“they’ve not worked on the challenging aspects of software – complex UI’s or transactional backends, so all that is left is some code in the middle. No need to worry about consumption and run time; just call my public methods”.
Trying to be a conscientious interviewer, I will steer the question towards what they have termed middle tier to learn more. But…sometimes they don’t even know where hydrated objects come from. Can you imagine? The opportunity to describe their strengths turns into a serious liability – no knowledge of domain modeling, factories, repositories, facades. These are not deep technical questions like some of my more serious and deeply technical coworkers will ask. Seriously, if you are a developer, lead, manager or architect who actually worries about performance, durability, scalability or just plain old fashion maintenance – these people might be somewhere in your company.
Of course, what else could they do? DBA’s write SQL in their world and web UI/flash/ajax/jquery is non-existent replaced with drag-n-drop and those “other teams”. There is nothing left for them to do but write some crummy C# business code – of course, without polymorphism or OO techniques and focus on the small problems answering questions with “From what I understand…”, yes, tell me more, because you obviously don’t understand the problem at all.
The core concept behind systems thinking is: instead of narrowing focus of a problem into sub-problems, the focus is broadened to include more and more interactions to get a wide view. It’s almost the antithesis of formal analysis, but one that has proven importance since it’s formative years in the mind of Professor Jay Forrester at MIT in the 1950’s. He was looking for a way to make implicit conclusions and improvements to social systems similar to that of mechanical systems.
So? So, building software is much more about a social system than engineering or mechanical. It’s widely understood in the industry today that the largest obstacle to delivering software is getting teams to work together towards a goal – and then deliver on that goal to such an extent that developers now care about how projects are run while shunning traditional project management. Inside of this day to day work are many decisions with far reaching implications and it’s important for the member of an effective team to be able to see the forest for the trees – at least occasionally.
Gerry Weinberg, one of the great thinkers about software intensive systems management, started writing seriously about Systems Thinking in the early 80’s. His use of system dynamics, a way to visualize and apply systems thinking, had effects as far as Kent Beck and the formation of TDD, XP and eventually the Agile movement (this is my own assumption based on reading some of Beck’s work). His work may not be that well known, but then again, our industry does not hand down information in a formal manner either, so lots of great work goes under appreciated.
Solving Small Problems
Thinking through little problems and missing the big picture (failure to apply system thinking) isn’t just at the detriment of organizations – it effects people too. Aptly, the friendly Middle Tier programmer.
They focus on XML (another trite example) and transforming some messages. What for? To what extent? Is there a better way? Isn’t this just21st century clerical work using a compiled ASCII based syntax.
And in this way, fail to be well rounded or a thinker, and thus, become dated, extinct and the wide eyed doe’s during interviews – just barely trying.
Ignorance to Industry
This industry does not stop. At the same time there is so much need that we can’t shake a lot of the hanger-on’s. If this was a regulated field, like medicine, those of us who know what we’re doing would all drive Bentley’s. But it’s not, so the flotsam and detritus of the field applies itself like barnacles to our hulls to slow progress. Here is just a brief list of what the Middle Tier programmer lacks knowledge of:
– OOP is not about code reuse (Dr. Alan Kay at your service)
– Some OO principles most basic of which is the Single Responsibility Principle, i.e. inverse of Big Ball of Mud
– An assembly, or any deployment package, is not an object
– Who Martin Fowler is (one need not be a sycophant to know this…Refactoring was published in 2000 afterall)
– What is a factory is. Even a modicum of knowledge here in its most basic form is so appreciated.
– Basics of HTTP; how does a cookie work
The above items are not entirely complex. One or two may be pointed out with the congenial “I don’t even know that” but, summarily, this is rather basic if you’re not just graduating from college.
Ability to Present Oneself
It’s quite possible that the reason the Middle Tier programmer appears so inept is because a deeper study on their habits hasn’t been performed. What do they read and watch? What time do they get into the office or what do they eat for lunch? True – this research hasn’t been done. Unfortunately, interviews are not about a deep dive – they are an opportunity for the job seeker to present him or herself to the organization. What follows are some ways they can blow the opportunity.
Poor Interviewing Skills
The obvious ones don’t need much discussion – eye contact, strong hand shake, asking questions – instead, just one example illustrating that interviews are not egalitarian affairs.
Myself: “Thanks for coming in. How is your day so far?”
Candidate: “Fine fine, thank you. How long is this contract?”
“Hmm, well, I don’t know. That is something I would have expected the recruiter to inform you of.”
“Ok. Ok. Sure. 3 months, 6 months?”
“I don’t know for sure. We can adjorn the interview and get your questions answered if you’d prefer.”
“No, that’s ok.”
“Want to continue?”
Questions are asked and answered….then….
Myself: “Ok, that’s what I have. What questions do you have for me about the job or the company?”
Candidate: “Hmm, yeah. How long is the contract?”
“Ok, we’re all set then, I’ll walk you out.”
This individual, besides wasting my time, showed himself to be paranoid, distracted and unprepared. I can’t imagine how well he could have answered questions to get a call back.
Good at what?
Here is the axiom of the Middle Tier Programmer – they don’t know it’s a problem. They think it’s ok, which leads the interviewer to press the candidate to find what they are good at. It’s the candidates responsibility to make this clear. Very clear. Crystal clear. But they don’t.
If the candidate is neither good inter-personally or technically, they won’t be hired for a real job. If they are neither quixotic or pragmatic, they won’t be hired. Stand out for something
The last point on the ability to present oneself is chapter one of How to WinFriends and Influence People. It’s chapter one of most books on working with people: show genuine interest in the other person. During an interview this could even be removed one layer to show an interest in the problems of the company. Too many times I walk away thinking that the candidate doesn’t care one iota about my problems or the company – and that is not a pleasant feeling.
If You are this Individual
All is not lost. This is not career coaching – just some plain old advice from someone who’s been around a bit in his career. Take it or leave it, but be warned, I know lots of people who make hiring decisions that think similarly.
Read these books:
Be familiar with these ideas (at a minimum):
- Singleton, factory, facade
- Domain objects
- Understand how a distributed system works
- Basics of HTTP
Do something once a year
- Learn a language; write an app; attend a conference/webcast
- stay sharp:http://www.ayeconference.com/staying-sharp/
- if you’re doing something outside of the mold – speak up!
- Passion – are you in the right field? Consider this well – you can’t learn passion!
It’s possible to escape the designation of Middle Tier programmer. If you are one, go, learn and be fruitful. Otherwise, use this editorial as a guideline to give words to the people who clog up your interviewing process, a programmers career pattern to avoid.
(Don’t forget to read Part II, post Reddit comments.)