It’s a fact that one of the biggest problems with the software industry is the inflated focus on the individual. For much too long, the most common scenario has been this:
Some dude is coding somewhere off to himself, most likely with headphones on, doing whatever he thinks is right.
Why is this bad?
This is not only bad, it’s fukkin horrible! The reason why is because it’s too easy then for the coder to get emotionally attached to the code he’s producing. He feels ownership of the code.
He’s judge, jury, and executioner for almost every decision. His own personal tastes, opinions, likes and dislikes dominate the code he’s writing. As such, whatever his current worldview is regarding coding practices/guidelines/principles is what make it into the code. More often than not, he’s a Chump coder and is littering the codebase with a bunch of shitty code. But from his point of view, he thinks he’s making sound decisions and doing a good job.
Now, if he’s writing code for himself then no one cares. He can do what he wants and make his code as fukked up as what makes him happy. However, if he’s writing code for a company or expected to coordinate within a team environment, then this is where The MetaGame begins.
The MetaGame: The process of dealing with the emotional element of human beings in a field that depends heavily on objectivity, facts, and repeatable results.
Let’s back up a minute. How did we get here? Why is it the case that the following is true?
Some dude is coding somewhere off to himself, most likely with headphones on, doing whatever he thinks is right.
It all started a little over 60 years ago when this thing called a “computer” started being viewed as a tool for solving problems.
You have to understand that in those days, there weren’t a lot of programmers. Like less than 50 total, worldwide. The few programmers that did exist were extremely different from the typical programmer today. They were most likely middle-aged and had developed a strong work ethic from years of working in mathematics and the sciences. Hell, having the mathematics background alone was enough to ensure that the person was somewhat meticulous, careful, and well disciplined.
Back then, scientists and mathematicians could choose programming as part of their job duties should they so desire. There was no official “programmer” curriculum at any university. Programmers as we know them didn’t exist. There were only mathematicians and scientists that did programming.
Why is this relevant? Because if you were a “programmer” back then, it was already established that you were a smart muhfukka to begin with. Just being in the room meant that you had a beast of an intellect and were a force to be reckoned with. This, in turn, meant that it was easy to trust these individuals to work individually on programming tasks and you could count on them to get shit done.
As a matter of fact, from this small collection of mathematicians and scientists, came all of the programming solutions of that day. As the need for more and more programmers arose, more and more mathematicians and scientists were converted. It was just the natural progression of events for these professionals to work alone on a given problem and write up and share results, methods, and techniques with one another. This was simply the way of the scientist.
In the beginning, the state of The Meta (shorthand for MetaGame) was fairly relaxed. Dipping into The Meta didn’t take precious time away from getting results. In short, the work and the results changed the shape of The Meta.
But somewhere along the way, we started letting stupid, petty, insecure muhfukkas in and that’s when shit got real. In today’s programming world, the shape of The Meta changes the results.
There are two primary reasons why we cannot build software in isolation the way we did in the beginning:
We simply should not tackle these programming problems alone. Teams of developers working together is by far the most likely path to success. Most companies these days know this, but the lone wolf developer is still highly prevalent.
If they’re smart, the organization that you work for is creating software using teams of developers working mostly in pairs. Given then, that you work for a smart organization, the most common scenario is that you’re pairing with someone else.
Even if you do still write code solo, that code is reviewed by another muhfukka before it’s added to the codebase. This means that you have to learn to work with other people much more closely than the scientists and mathematicians of yesteryear.
After speaking to several developers over the last few years, it’s become clear to me that most of the problems in our daily work do not come from wrestling with the technologies or the code.
99% of developer problems come from dipping into The Meta… having to deal with the emotional state of co-workers rather than solve problems. Well, we are solving problems but we’re not solving technical problems for our clients. The majority of the time is spent solving emotional problems for our co-workers.
Why is this?
I’ve often asked myself why are a lot of the people that I work with today so much more fragile than the people I worked with 20 years ago?
These days, if you can read a blog post and get console.log to print “Hello World” in the Firefox debug console, you can call yourself a programmer. We need ‘em so badly that we hire anyone who can talk the talk. Then leave it up to the development teams to deal with the fallout when they can’t walk the walk. Sigh.
Gone are the days when “just being in the room” was proof enough that you were damn good at what you do.
What passes for a developer these days is often quite laughable. And that’s keepin’ it completely 100. The percentage of inferior developers is astounding.
When I consider a developer inferior, it has nothing to do with their skill. An inferior developer is all about attitude. Conversely, what makes a great developer is also attitude.
If you have the correct attitude but lacking in the skills or aptitude, I can fukks with you.
If you have the aptitude and/or the skills but the wrong attitude, fukk you and all you hold dear.
Given the correct attitude, you can help a developer maximize whatever aptitude they have. Maybe they can’t get to the point where they’re writing Assembly for multiple processors, but they can establish themselves in a particular area and make a damned good living for themselves and make meaningful contributions to their teams.
Take for example the terms front end, back end, and full stack. These terms are actually quite useful when used how they were intended. The intended purpose is to differentiate between areas of focus not importance. A front end developer is not lesser than a full stack developer.
There are developers who choose to focus on keeping up with the fast-moving world of front end technologies and there are those who concentrate more on the backend side of things.
I know front end developers who could easily code the full stack if they wanted and I know back end developers who could easily get more proficient at front end work if they so chose. Both groups have the aptitude and simply choose to focus in a particular area.
Again, neither is more important and both have a role to play. There’s absolutely nothing wrong with focusing on an area that maximizes your aptitude. As a matter of fact, you’d be a fool to not do this. The key is to keep the correct attitude and continue to expand your horizons to the best of your ability.
Your attitude and your aptitude work hand in hand to establish your skills.
Speaking of attitudes…
Once you’ve done the work of getting The Meta to a stable, workable state, you have to do a bunch of shit to keep it that way or your team’s productivity will start to suffer.
Why is this?
I’ll tell you why… somehow some of these lame-ass, simple-minded, rat-soup eatin’ muhfukkas got the notion that their feelings actually matter as much as or more than the results they’re being paid to produce.
Well I have news for your dumb asses… if the development teams don’t produce, then the company that’s employing you will fail, and your stupid ass will end up in the unemployment line dealing with much worse shit than your inability to deal with your own feelings.
But anyway, given that we do have to work with other humans beings and given that The Meta will exist and have a state because of this, what then should we reasonably expect from one another with regards to helping each other deal with our own individual emotional needs?
In other words, how much can one co-worker reasonably expect another co-worker to cater to their emotional needs?
I’m glad you asked!
As with most things, it all depends on context. The core of it though, depends on the nature of each individual relationship. The more professional the relationship, the less that can be expected. The more personal the relationship, the more that can be expected.
In professional relationships, you’re expected to display what’s known as common courtesy to every other employee. This is the minimum standard of conduct between one another.
When an employer hires you, they expect you to show up to work on time, do your job well, and not cause trouble.
It’s not required that you make friends with your co-workers or even like them. All that’s necessary is for you all to work effectively together.
Being the visibly Black man that I am, I’ve been in many situations where my co-workers couldn’t stand my Black ass. Even still, we were able to do great work together and get a lot of shit done because it was never required for us to like each other. They just had to show me the standard level of respect and communicate with me enough to produce results. Of course I owed the same in return.
Hell, I knew they didn’t like me (rather the idea of me) and truth be told, I respected them a lot more for keeping it 100. Personally speaking, I’d much rather deal with a person who’s straight up and has all the cards on the table than with a snake-in-the-grass ass muhfukka who gives all the appearances of cordiality and goodwill but internally hates my guts. I see you muhfukkas. Y’all can’t hide from me.
Them not hiding that they didn’t like me actually caused me to respect them more.
I owe common courtesy and respect to every single person that I will ever work with and I owe this to them whether they give that back to me or not… and so do you.
It’s not conditional nor optional. It’s not like you only owe common courtesy when it’s being reciprocated. That’s the minimum bar regardless of what the other person does.
We all owe our co-workers common courtesy and respect.
In personal relationships, you choose to invest your time, effort, and energy into another person. Given this, you implicitly assume a certain amount of responsibility for fostering the relationship and helping it grow. You owe some of yourself to your friend and that thing that you owe goes above and beyond common courtesy.
In short, you owe your friends more of yourself and have a responsibility to them and their emotional needs and concerns.
If a co-worker that you have a more personal relationship with is upset because of something that happened in a meeting, then yeah you kinda owe it to them to be there for them and help them work through it.
As a quick fix, maybe you have to take ‘em outside to smoke some weed or some shit until after work where y’all can get more deeper into it. Whatever it is, you gotta help ‘em.
All that’s fine and well but the truth is, a lot of organizations don’t differentiate between professional and personal relationships. We tend to expect every employee relationship to be more of the personal nature.
There are companies that want all of their employees to actually like and be friends with one another. They want a family atmosphere and do a lot to encourage this mindset. Especially if that company considers itself to be more progressive than traditional.
The more corporate level companies don’t really deal with this as much because it’s just easily understood that all twelve thousand of your muhfukkin employees aren’t gonna be friends. This unrealistic expectation doesn’t even enter into the equation. Although, they do have programs and shit in place to help with these kinds of things but on a smaller level.
The more progressive the company, the greater the effect that the current state of The Meta has on results.
This is because these companies place a very high focus on the emotional happiness of the individual over the production rate of that individual. They allow for the excuse that if you’re not at your best emotionally, then we expect your output to suffer as a natural result.
As such, rather than forcing the individual to put their emotions in check and keep producing, they instead invest a lot of effort into helping that person deal with their emotional issues with the expectation that the production will resume on its own once the emotions have been stabilized.
These organizations have an unspoken expectation that every person in the organization automatically have empathy for every other person in the organization. As such, these types of organizations encourage the belief in the individual that their feelings matter as much as or more than the results.
And this belief held by the individuals is the main reason for the explosion of The Meta.
Ok, so what does all of this mean? What’s it mean to dip into The Meta? What’s production like with and without this? Just what the hell have I been rambling on about? How do The Meta and its conflicts affect output?
Meta Conflict: A personal attribute in an individual that, when triggered causes the individual to reduce either his own output or the output of one or more members of the team. These triggers are possible because the individual believes that his feelings have priority and the company he works for encourages and supports this belief.
Dip Into The Meta: Solving programming problems by getting an individual (or individuals) to feel better emotionally so that they’ll actually do the programming that they’re being paid to do.
I’ll try to illustrate with my list of the top 3 Meta conflicts below. Note that, it only takes one person on a team to cause the entire team to have to dip into The Meta.
Some people are so fukkin obsessed with what they think other people think of them that they go waaaaaaaaaay overboard in trying to control what their peers think of their abilities.
Barney: “I was checking out some functional programming languages last night and learned a lot. I might do a presentation on it soon, if I get the time.”
Fred: “Oh I’ve been doing Scala for 3 months now and it’s great. I’ve written 5 apps in it already that I might publish on github. I also have a friend who’s been doing Haskell and other functional programming since 2003 and he’s the best functional programmer I know. If you want, I can have him show you some stuff or help you get started because he’s like one of the best ever. Dude I can hook you up with him easily so you don’t waste your time learning from inferior sources.”
This is undesirable because the conversation had nothing to do with Fred. Barney was sharing something he felt comfortable with regarding his learning path and Fred made the conversation be about him and what he knows and what contacts he has.
This negatively impacts The Meta because now:
Everyone will be more reluctant to share. Especially when Fred is around. The bonding that would naturally occur is stunted because no one wants to deal with Fred and his penchant for promoting his self-importance
Team members will tend to avoid Fred as much as possible without giving away how they really feel about him
There will be times when Fred will have the exact solution that the team needs, but his message will be too shrouded in self-promotion to be heard
The team is building some feature and because Fred hasn’t been made to feel important today, he starts some tangent about how he coded in a blizzard on an iPad while walking to school uphill in the snow for 9 miles. No one wants to hear it, but no one wants to confront him either so they all cringe and lose focus while he self-promotes.
People start calling in sick, or working remotely, or taking vacation days so they can reduce the interactions with him.
This causes dipping into The Meta because once the team has been fragmented and the production slowed, in order to get it back, you don’t solve it with technology solutions. This is solved by addressing either the emotional state of Fred, the team, or both.
Management sits Fred down to tell him that he has to stop promoting himself and that he’s negatively impacting the team. But if they do, he’ll start judging the team members and wondering who it is exactly that has a problem with him. He’ll start to feel out of place on the team and his own production will suffer.
Tell Fred about himself, give him clear examples and give him a timeline for improvement. Let him know that everyone values his contributions when he’s actually contributing but if he doesn’t improve quickly (like days, not weeks), put him on another team that may be better equipped to deal with his need for self-promotion or get rid of him completely.
The funny part about this is that muhfukkas don’t wanna be told they’re wrong especially when they are. What da fukk?
Like it or not, everything you say and think is not correct. When working in a technical space, you will be wrong. Often. Period. Accept it. The fastest and most efficient way to move forward is to filter out the bad ideas and move forward with the good ones. But if you do, this fukks up The Meta.
Jerry: “If you run the Ruby version of Cucumber then your SUT has to be a Ruby app.”
Tom: “That’s not true. You can use the shell to call out to a CLC or hit a Web API.”
Jerry: “I’m not going to contribute to the conversation if I’m going to be attacked like this. That was very unprofessional of you Tom and you need to learn how to interact with people.”
This is undesirable because Tom wasn’t attacking Jerry at all. All Tom did was correct a false statement.
This negatively impacts The Meta because now:
Instead of swiftly advancing the conversation along, every team member has to figure out a ”fluffy” way to expose the errors in the conversation that won’t upset the original speaker. This is fukkin dumb because everyone is different and the things that trigger this bullshit in one person may not trigger it in another
What should be 2 and 3 minute conversations turn into 4 and 5 hour team discussions followed by multiple lunch pow wows. The fukked up part about it is that this even happens when you try to use the fluff because you guessed wrong in your particular fluff implementation and triggered this bullshit in the person anyway. Fukkin ugh. I hate this shit
Team members will tend to distance themselves from conversations and you won’t get full team participation. As a result, bad ideas will remain in play for much longer than they should
The team will try to have group conversations where they point out certain goals and ideals that the team desires in an attempt to get the message out there about open conversation and being able to correct each other without telling Jerry directly that they’re talking about him.
Jerry will say something wrong, get corrected and then get offended anyway and this will lead to yet another team conversation in an attempt to set expectations for Jerry based on what he just did. Again, it will be phrased as a group desire in hopes that Jerry will get the message without being singled out.
Jerry will continue to get upset and this will spawn multiple lunch conversations and one-on-one talks with Jerry.
If you tell the offender that they’re wrong, then they’ll either shutdown and not contribute further or attack someone else for pointing this out. If you don’t point this out, the team has to entertain this “wrongness” for however long it takes to find a way to get rid of it. Regardless, you lose productivity either by leaving the “wrongness” in play or fumbling around trying to figure out the right way to say to the offender that his idea sucks ass. If you can’t find a way to say it gracefully, then you’re left to deal with all of the ramifications of leaving this dumb-ass idea on the table.
Tell that muhfukka point blank that he’s wrong. Period. I expect every professional to know the difference between ”you’re stupid” and ”that’s not a good idea”. I refuse to accept that a mature, adult mind working in a professional space can’t tell the difference between a personal attack and honest analysis of a technical statement.
The company should assess candidate’s ability to distinguish between the two before they’re even hired on.
These type of developers really hinder the ability to collaborate effectively. More time is spent on their feelings than on finding solutions for our clients.
I’d put the onus on the individual to be mature and adult enough to deal with their own emotions and remove that burden from the team.
This is by far the most annoying and the most prevalent form of Meta conflict. These muhfukkas are so fukkin fragile that the slightest bit of scrutiny being applied to one of their ideas is enough to send ‘em scrambling to the dark ages.
If you challenge (or even question) any of their ideas, they’re ready to disappear. Sometimes I wish they would.
Betty: “Any system with more layers is automatically more complex than a system with fewer layers.”
Wilma: “Is that true? What makes you think that? Can you give some examples?”
Betty: “What makes you think I don’t know what I’m talking about? Why are you questioning me??!!”
This is undesirable because Wilma wasn’t questioning Betty at all. All Wilma wanted was to explore a statement further.
This negatively impacts The Meta because now:
The team is trying to collaborate on the best way to build a particular feature for a client. However, it’s impossible to thoroughly investigate all the options because exploration is discouraged.
If you push past the person’s sensitivities and have exploratory conversations anyway, you have two possibilities. If the sensitive person doesn’t express their displeasure, it still shuts them down and the team loses their participation. If the sensitive person does express their displeasure, we’re right back to where we were before.
I’d handle this in the same way that I’d handle the “don’t tell me I’m wrong” person. Be very clear and direct with milestones for displaying improved behavior.
I’d still put the onus on the individual to be mature and adult enough to deal with their own emotions and remove that burden from the team. Or get rid of ‘em.
There’s no escaping that The Meta exists and impacts our performance. This has always been true since the very beginning. It will always be true wherever humans interact.
However, its effect is much greater than in years gone by because even though programming is still a logic-driven activity, our decisions aren’t driven by logic (primarily) anymore. Unfortunately, our decisions are primarily emotional.
There’s some developer named Elmer who has a favorite blogger. That blogger has a rival. The blogger and his rival post sorting algorithms to their respective communities. The sorting algorithm supplied by Elmer’s favorite blogger completes in quadratic time. The rivals sorting algorithm completes in constant time.
Because Elmer has an emotional attachment to his favorite blogger, this dumb-ass muhfukka actually, willingly, and purposefully uses a fukkin quadratic time sorting algorithm in his organization’s code.
Not only that, he’ll fukkin rationalize a bajillion reasons why it’s ok “in this instance” to have operations that complete in quadratic time. He’ll fight, argue, kick and scream in defense of this algorithm. Not because it makes logical sense, but rather because he has an emotional attachment to it.
In the end, his goal (and everyone like him) is to remove objectivity. This takes on various forms but the notion behind them all is this world where everything is relative. Once that’s been accepted, then they can escape the (unwanted) chore of substantiating their decisions. They can simply answer every question with “this feels like the best approach for me.”
If someone on the team successfully manages to get Elmer’s algorithm removed and actually replaced with the algorithm from his favorite blogger’s rival, Elmer will now be feeling some type of way and his production will suffer.
The Meta will be all fukked up and the team is now burdened with dipping into it in order to get productivity out of Elmer again.
Please understand that the goal isn’t to remove The meta. The goal is to acknowledge it and understand how to successfully manage it. This requires effort. Defining just how much effort is reasonable is up to each organization or team within an organization.
My biggest suggestion to you is to form dedicated teams that work together for at least a year. This gives them the time they need to figure each other out and learn to work together. Once this bonding happens, it’s fukkin awesome and their ability to self-organize and manage their own MetaGame is fukkin incredible.
The key to dedicated teams is that, given enough time, the working relationships will automatically evolve into more personal ones. This, in turn, increases the team’s ability to navigate their own MetaGame due to shared understanding and genuine empathy for one another.
With that in mind, I’d also try to limit the max team size to about 10 - 12 people. This includes QA, UX, PM, support and developers.
Also, be aware that when a lone wolf developer transitions to a team based approach, he will attempt to bring his lone wolf mentality with him. For so long he’s been the sole authority for deciding what’s right, that he causes a lot of Meta conflict when this authority is taken from him and dispersed across the team or to a more knowledgeable member of the team.
Most importantly, you have to be realistic enough to admit that some people are just difficult to work with and will always trigger conflict in The Meta. In these instances, you have to decide if what they add to your organization is enough to offset what they take away from it.
The Meta exists. Be aware of the various paradoxes within it and manage them effectively.