Do you remember when I explained that to build software professionally, you need two components? I called these components the business and development. I think it will help you to become a much better professional software ninja if you take the time to learn how things look from the view of the business instead of only focusing on the tech / developer side of things.
To go even further, I’m resolute in the belief that many of your decisions both in the code you write and your personal code of conduct at work will be markedly improved if you continually frame said decisions in the context of the business.
Let’s answer a basic question. Why would an employer hire you?
Obviously, it’s because they think you can add value to their business. That’s it. That’s all.
The usual way that you’re expected to add value is by increasing the profits for the business. This can be done directly or indirectly, but the reason you’re there is because they can profit off of you in one way or another. Period.
Even if you work for an awesome company that places high value on the human experience, that place won’t survive for long if it’s not making enough money to support the ideas that it values. At the end of the day the business needs you to add revenue in some form. Don’t deceive yourself into thinking otherwise.
It’s always about the money.
As such, one of the very best things that you can do for your career is to learn why the business has you around and then make sure you’re meeting or exceeding those needs.
In order to do that, you need to first understand that…
Practically every software ninja that I’ve ever worked with (unless they were management) felt at odds with the business. They’ve unilaterally viewed the business at best as a major pain-in-the-ass and at worst as a bunch of fukkin morons that should be killed or teleported to some pain-filled dimension.
There are various reasons for this and sometimes I’m sure those reasons are valid. Sometimes the business representatives really are fukkin morons. The problem though, is that this isn’t a one-off attitude and it’s not usually formed in-context based on some buffoonery from the business. It’s more like the default setting for every programming muhfukka out there.
By nature, software ninjas do not like and seldom respect their business counterparts.
This is both baffling and stupid.
The first responsibility of a professional software ninja is to meet the needs of the people that pay ur dumb ass.
I’ve seen developers literally throw a hissy-fit because we were asked to enter our billable hours on time. I remember sitting in a staff meeting where management pleaded with the staff to please, please, please enter your billable hours by the end of the pay period so that we can invoice our clients.
After this meeting, some of the developers were livid! They felt genuinely violated and disrespected because the people that paid them asked them to do their part. What the fukk man? I was stunned. These dudes literally felt like it was an infringement upon their lives for them to enter their billable hours.
Ummm… bro… Don’t you realize that your main job is to help keep the business alive? Why the fukk do you think you’re there?
I’ve been in situations where two developers literally stormed out of a meeting because they didn’t meet a deadline. But check this out… they had already missed the deadline once and management asked them “Based on what you now know that you didn’t know before, how long will it take you to finish?”
These clowns answered “If we could get two more weeks, we can have this wrapped up for sure.”
So management says “Ok, we’ll give you a month. Will that be enough?”
So that month goes by and management is expecting the features to be complete right? Wouldn’t you? In addition, there were two very important stakeholders flying in for a demo that afternoon.
Guess what happened at the morning meeting? Management asks about the feature, these idiots say “It’s not ready, we need another two weeks”.
Management rightfully replies “But we already gave you two more weeks than you asked for. We have stakeholders flying in from D.C. today for a demo. The entire team knows this. What happened?”
It was at this point that these bastards practically yelled at management “Don’t micromanage me!! It’ll be done when it’s done!!” Then stormed out.
What the fukk man?
Where do these bastards get these punk-ass attitudes and inflated senses of entitlement from?
The following tale, by a master guru, is very revealing and something that I think every programming muhfukka can learn from. It doesn’t matter if you’re a seasoned veteran, a rookie, or an aspiring software ninja… pay attention to this story.
It’s his account of how he learned to appreciate the business that paid him.
How Robert Martin (AKA Uncle Bob) Got Fired told by Robert C. Martin
The only time I was fired from a programming job was in 1976. I was working for Outboard Marine Corp. at the time. I was helping to write a factory automation system that used IBM System/7s to monitor dozens of aluminum die-cast machines on the shop floor.
Technically, this was a challenging and rewarding job. The architecture of the System/7 was fascinating, and the factory automation system itself was really interesting.
Everything should have been great. The problem was me. I was enthusiastic enough about the project, and about the technology, but at the grand old age of 24 I simply could not bring myself to care about the business or about its internal political structure.
I simply could not get to work on time. And I thought it didn’t matter. After all, I was doing “a good job.” And it was true, I was doing a very good job at writing my programs. I was easily the best technical programmer on the team. I could write code faster and better than the others. I could diagnose and solve problems quicker. I knew I was valuable. So times and dates didn’t matter much to me.
The decision to fire me was made one day when I failed to show on time for a milestone. Apparently John had told us all that he wanted a demo of working features next Monday. I’m sure I knew about this, but dates and times simply weren’t important to me.
We were in active development. The system was not in production. There was no reason to leave the system running when no one was in the lab. I must have been the last one to leave that Friday, and apparently I left the system in a nonfunctioning state. The fact that Monday was important had simply not stuck in my brain.
I came in an hour late that Monday and saw everyone gathered glumly around a nonfunctioning system. John asked me, “Why isn’t the system working today, Bob?” My answer: “I don’t know.” And I sat down to debug it. I was still clueless about the Monday demo, but I could tell by everyone else’s body language that something was wrong. Then John came over and whispered in my ear, “What if Stenberg had decided to visit?” Then he walked away in disgust.
Stenberg was the VP in charge of automation. Nowadays we’d call him a CIO. The question held no meaning for me. “So what?” I thought. “The system isn’t in production, what’s the big deal?”
I got my first warning letter later that day. It told me I had to change my attitude immediately or “quick termination will be the result.” I was horrified!
I took some time to analyze my behavior and began to realize what I had been doing wrong. I talked with John and Ralph about it. I determined to turn myself and my job around.
And I did! I stopped coming in late. I started paying attention to internal politics. I began to understand why John was worried about Stenberg. I began to see the bad situation I had put him in by not having that system running on Monday.
But it was too little, too late. The die was cast. I got a second warning letter a month later for a trivial error that I made. I should have realized at that point that the letters were a formality and that the decision to terminate me had already been made. But I was determined to rescue the situation. So I worked even harder.
The termination meeting came a few weeks later.
I went home that day to my pregnant 22-year-old wife and had to tell her that I’d been fired. That’s not an experience I ever want to repeat.
You can find this story and more in the must-read book: The Clean Coder: A Code of Conduct for Professional Programmers. If you don’t read anything else on programming ever, get a copy of that book and read it.
So in my own words, what can we learn from Uncle Bob’s experience? That’s easy.
No matter how fukkin good you think you are, if you’re not meeting the needs of the business, why the fukk do they need you there?
Like I said before, one of the very best things that you can do for your career is to learn why the business has you around and then make sure you’re meeting or exceeding those needs.
Again I ask, why would an employer hire you?
Again I answer, because they think you can add value to the business.
You come into work, they pay you for the work performed and hopefully this cycle can continue ad infinitum in peace and harmony. It’s pretty clear that if you work, they’ll pay you for it. It’s also pretty clear that they (usually) want the best work you can do.
So it should be clear that the business is not our enemy.
I’m not sure, however, that the same thing can be said in reverse. At least not perceptionally anyway. Many of our actions reinforce to the business every damned day that software development is the enemy of sound business.
Don’t believe me?
The following is an excerpt taken from this full article on Bloomberg. The part that I’ve extracted and re-posted here was chosen because it does an excellent job of putting you firmly in the mind of the business.
Without further ado, let me introduce you to…
You are an educated, successful person capable of abstract thought. A VP doing an SVP’s job. Your office, appointed with decent furniture and a healthy amount of natural light filtered through vertical blinds, is commensurate with nearly two decades of service to the craft of management.
Copper plaques on the wall attest to your various leadership abilities inside and outside the organization: One, the Partner in Innovation Banquet Award 2011, is from the sales team for your support of its 18-month effort to reduce cycle friction—net sales increased 6.5 percent; another, the Civic Guidelight 2008, is for overseeing a volunteer team that repainted a troubled public school top to bottom.
You have a reputation throughout the organization as a careful person, bordering on penny-pinching. The way you’d put it is, you are loath to pay for things that can’t be explained. You expect your staff to speak in plain language. This policy has served you well in many facets of operations, but it hasn’t worked at all when it comes to overseeing software development.
For your entire working memory, some Internet thing has come along every two years and suddenly hundreds of thousands of dollars (inevitably millions) must be poured into amorphous projects with variable deadlines. Content management projects, customer relationship management integration projects, mobile apps, paperless office things, global enterprise resource planning initiatives—no matter how tightly you clutch the purse strings, software finds a way to pry open your fingers.
Here we go again. On the other side of your (well-organized) desk sits this guy in his mid–30s with a computer in his lap. He’s wearing a taupe blazer. He’s come to discuss spending large sums to create intangible abstractions on a “website re-architecture project.” He needs money, support for his team, new hires, external resources. It’s preordained that you’ll give these things to him, because the CEO signed off on the initiative—and yet should it all go pear-shaped, you will be responsible. Coders are insanely expensive, and projects that start with uncomfortably large budgets have an ugly tendency to grow from there. You need to understand where the hours will go.
He says: “We’re basically at the limits with WordPress.”
Who wears a taupe blazer?
The CTO was fired six months ago. That CTO has three kids in college and a mustache. It was a bad exit. The man in the taupe blazer (TMitTB) works for the new CTO. She comes from Adobe and has short hair and no mustache.
Here is what you’ve been told: All of the computer code that keeps the website running must be replaced. At one time, it was very valuable and was keeping the company running, but the new CTO thinks it’s garbage. She tells you the old code is spaghetti and your systems are straining as a result. That the third-party services you use, and pay for monthly, are old and busted. Your competitor has an animated shopping cart that drives across the top of the screen at checkout. That cart remembers everything customers have ever purchased and generates invoices on demand. Your cart has no memory at all.
Salespeople stomp around your office, sighing like theater students, telling you how embarrassed they are by the site. Nothing works right on mobile. Orders are cutting off halfway. People are logged out with no warning. Something must be done.
Which is why TMitTB is here.
Who’s he, anyway? Webmaster? IT? No, he’s a “Scrum Master.”
“My people are split on platform,” he continues. “Some want to use Drupal 7 and make it work with Magento—which is still PHP.” He frowns. “The other option is just doing the back end in Node.js with Backbone in front.”
Those are all terms you’ve heard. You’ve read the first parts of the Wikipedia pages and a book on software project estimation. It made some sense at the time.
You ask the universal framing question: “Did you cost these options?”
He gives you a number and a date. You know in your soul that the number is half of what it should be and that the project will go a year over schedule. He promises long-term efficiencies: The $85,000 in Oracle licenses will no longer be needed; engineering is moving to a free, open-sourced database. “We probably should have done that back when we did the Magento migration,” he says. Meaning, of course, that his predecessor probably should have done that.
You consult a spreadsheet and remind him that the Oracle contract was renewed a few months ago. So, no, actually, at least for now, you’ll keep eating that cost. Sigh.
This man makes a third less than you, and his education ended with a B.S. from a large, perfectly fine state university. But he has 500+ connections on LinkedIn. That plus sign after the “500” bothers you. How many more than 500 people does he know? Five? Five thousand?
In some mysterious way, he outranks you. Not within the company, not in restaurant reservations, not around lawyers. Still: He strokes his short beard; his hands are tanned; he hikes; his socks are embroidered with little ninja.
“Don’t forget,” he says, “we’ve got to budget for apps.”
This is real. A Scrum Master in ninja socks has come into your office and said, “We’ve got to budget for apps.” Should it all go pear-shaped, his career will be just fine.
You keep your work in perspective by thinking about barrels of cash. You once heard that a U.S. dry barrel can hold about $100,000 worth of singles. Next year, you’ll burn a little under a barrel of cash on Oracle. One barrel isn’t that bad. But it’s never one barrel. Is this a 5-barrel project or a 10-barreler? More? Too soon to tell. But you can definitely smell money burning.
At this stage in the meeting, you like to look supplicants in the eye and say, OK, you’ve given me a date and a budget. But when will it be done? Really, truly, top-line-revenue-reporting finished? Come to confession; unburden your soul.
This time you stop yourself. You don’t want your inquiry to be met by a patronizing sigh of impatience or another explanation about ship dates, Agile cycles, and continuous delivery. Better for now to hide your ignorance. When will it be done? You are learning to accept that the answer for software projects is never.
Unfortunately, the experience that the author describes is highly prevalent in our industry. It’s a shame that we make it so hard for the business people to complete their portion of the process.
Have you ever put yourself in the shoes of the business? How would you budget for projects if you couldn’t get a set of reliable estimates from your developers? How would you tell your superiors and clients when the project will be finished when no one will commit to a deadline? How would you do your job at all if the development staff was horribly unapproachable?
It’s a damned shame when the business feels the safest course of action is to simply avoid the developers. This lack of trust and unreliability is what spawned the Agile movement in the first place.
From the perspective of the business, this bullshit happens all the time. I’m curious how many of us actually realize and consider all that goes into allowing us to build software.
This shit ain’t free man.
I put this on my mama and my dead homies… you need to learn to work with the business, not against it.
So before you write that ugly ass line of code, ask yourself “Am I contributing to a bigger bonus for me and my co-workers if I do this?”
Before you shit on Agile, ask yourself “What’s the most productive way to get the software built?”
Before you code business rules without writing tests first, ask yourself “Is the long-term profitability of the business hurt or helped by this decision?”
Before you take that stupid shortcut, ask yourself “Am I really helping us if I create a situation that will most certainly levy a Time Tax against us?”
Hell, before you get a pissy attitude with management, ask yourself “Are their demands and expectations really that unreasonable?”
Make it your business to be about the business of the business that pays you so you can take care of your business and bills and shit.
Teamwork makes the dream work.
Oh yeah… I know that “perceptionally” isn’t a word but I also know that you programming muhfukkas knew exactly what I meant when I used it.