http://www.nytimes.com/2013/10/21/us/insurance-site-seen-needing-weeks-to-fix.html

First, when management says “a few weeks”, what that really means is a few months. Yes, months.

Second, because it’s so big with many of the parts not under the purview of the contractor, they can’t rewrite it. That means, it’ll take 2 times or more longer.

Third, bringing on additional contractors/people will not help fix the problem. There was a book written in the 1970’s called the Mythical Man Month that debunked the claim that adding more programmers will make things get done faster. It causes the opposite. See Slate’s coverage here: http://www.slate.com/blogs/moneybox/2013/10/21/obamacare_and_the_mythical_man_month.html

Fourth, launching a site before it’s fully tested is fine and encouraged. Software, currently, has no fool proof way to detect for all problems. There are certainly languages and programming techniques some mathematicians can use, but that’s not the tools the private sector uses to build web sites.

Fifth, even if fixed, it’s clear the parties they’re responsible for connecting to for customer data are a huge component and huge part of the problem such as the Centers for Medicare and Medicaid Services. Since they are not under the direct control of CGI Federal, the contractor originally responsible to build healthcare.gov, there is only so much you can do to compensate for someone else’ incompetence & lack of communication. Meaning, holding CGI solely responsible unfortunately is not an option. It’d be easy to blame CGI for the failings, but that’s not how software, and our bloated government, work.

Sixth, 8 out of 10 software projects are failures, and 9 out of 10 are perceived as failures. Software is hard. We do it not because it’s a lottery, but because when it works it makes a huge difference despite the huge assurance we’ll fail.

Things will slowly improve. There will continue to be glitches, some of which the press may even talk about, a year from now. Jan 1st deadline is unrealistic.

… and for those who are curious about what just 6 million lines of code can do vs. 500 million, check it: http://arstechnica.com/information-technology/2013/10/the-navys-newest-warship-is-powered-by-linux/

I won’t cover whether money can buy you happiness or not. All I’ll say is that for some people it does, and others it does not.

Many of the financial and tax nomenclature below applies to the USA, but the types of work are the same regardless of country.

Introduction

Early on my consulting career, I found the maximum amount of money I could charge per hour was $100/hr. I had just assumed it was a simple linear graph: the more time that goes, the more experienced & marketable I get, thus the more money I can make per hour. This wasn’t the main metric I used to measure my success, but it’s certainly how a lot of people, at least in America, do. “How much money do you make?”

As time went on, and I actually did get more experienced, I learned it’s not a linear line. A variety of things can happen, or not, to affect it’s elevation. Examples include not working for a couple months, whether intentionally or not. There are a variety of stages you can possibly go through, at least in software development, and I’m still learning all the possible vs. desirable ones.

The basics are starting out in an internship or job, then breaking away to do freelance, and finally starting a company.

Below are the 3 things that don’t work.

W2 – Salaried Employee

Salaried employees are those who work for a company, called a “job”, and that company takes out your State and Federal taxes for you. They pay a salary, a flat amount of money per 1 days worth of work, whether you actually work 1 hour or 12 doesn’t matter. They also offer “compensation packages” such as 401k matching, 20 or more vacation days, and 5 or more sick days. People put their own arbitrary dollar amounts on these which helps companies offset their lowered salaries.

The problem with W2 is that you eventually max out. I’ve yet to see a salaried programmer make more than $175,000, although most are $120,000. That’s gross, not net. That’s still only about $90 an hour if you take out vacation days and holidays. You’re replaceable, and there is only so much code you can produce in a given time on your own. Although there are skill trees for development, getting better doesn’t lead to making more money. You basically have to go into management, leadership, or sales to sometimes fully utilize all those software skills you know. There are SOME options for hybrid roles such as Enterprise Architects, people who dictate how to build things but don’t actually build the things. Sales Engineers are another. You travel with a Sales person and get their back when the clients ask highly technical questions. Sometimes you get to code, but they’re often just simple prototypes, not real projects.

Finally, W2 is perceived as a form of “stability”; something long term, something earned and deserved. Unfortunately, that’s how things were back in the 1940’s, not anymore. Regardless, the prophecy is self-fulfilling for some people, so they believe it to be true, and thus it is true even if it’s not.

Unless you actually want to get out of programming, W2 isn’t an option.

1099 – Freelance

Freelancers usually charge by the hour or project (obviously they like the former). They are synonymous with contractors: someone who works for the company but is their own business. Your own business can just be 1 person: you. You are ultimately responsible for all of your finances and taxes, thus you file a form for the IRS called a 1099. The common rule is when you get a paycheck, you immediately take 33%, round up, and shove into savings so you can pay once a month, 4 times a year, or once if you’re a slacker the taxes you owe the State you live in and the IRS. None of that includes your operating expenses like buying your own computer, contributing to your retirement, and paying your own medical insurance.

The key here, though, is you can pay those first, THEN get taxed on what you have left over using “pre-tax” money whereas in W2, you’re taxed twice: first on your paycheck and then whatever you buy with it, the IRS still assumes you made X per year. For example, lets say you make $100,000 per year. You then buy $50,000 worth of hardware, software, and office space. You then only owe $16,500 in taxes vs. $33,000 like you would as a W2. This desire to spend your pre-tax money, whether on stuff, services, or even contributing to retirement accounts like SEP IRA’s is yet another to balance in your time that has nothing to do with programming. W2’s don’t have to worry about any of this crap.

This amount of work is not to be understated. This is how many companies go out of business. It’s also a lot of work for 1 person to handle just 1 persons business finances, let alone all the time spent hustling to get clients. More importantly, though, companies bear this “burden” when hiring W2’s. This is why a lot more companies are going the 1099 route or hiring contractors for set projects, not providing benefits, nor the “free” tax services like Amazon and others are doing in the UK and in the states.

There are a variety of reasons programmers go freelance. There is no growth potential at their W2 job. They don’t like the clients they’re working with and want to choose their own. They have short attention spans and want smaller projects. They hate the large code base they’re working on that’s messed up and they didn’t create, and want the opportunity to create their own. They want to utilize a completely different technology stack and there is no opportunity to do so at their current job.

Whatever the reason, the POTENTIAL exists for making more money than W2. Sometimes, you’ll make less. The reasons for those are also numerous. While you may get many high paying gigs, you may actually have many weeks or months with no work. While W2 has a steady paycheck, 1099 does not. Additionally, there is a cost of doing business that you now incur. Time spent on the phone, writing emails, going to meetings and conferences, writing books, blog entries, curating relationships with your content and others on social media; all of that takes a lot of time that no one is paying you for. Some of that could lead to getting a client to hire you to build something. Sometimes that client just wants free consulting, or is asking you and 9 other contractors to bid on a project and they just want you to do the quote for them with zero intention of actually hiring you.

The reasons are vast. The theory, though, is that you’re using a technology with either a local market (where you live) that has a need for your skills, a remote market (meaning you telecommute with clients you’ll never meet face to face), or both. Sometimes you’ll get many concurrent projects. While one project has slow communication and is long term, and other is more clear, and shorter. While you’d prefer to have both side by side, the companies hiring you, and their clients, usually dictate the schedule, and they don’t care that you haven’t had any work all June and July, and now 3 companies want to start work immediately in August all at the same time. Sometimes that can work; other times it can sacrifice your code quality so you can only get one.

Bottom line, this is where most programmers get stuck. If they do manage to break the $100/hr barrier, it’s because they got a fixed bid contract and just did it in a shorter time. Meaning you produce the work for this amount of money, no more. If you work 4 hours or 40, you still get paid the lump sum. So, if you can do 40 hours worth of work for less than 40, then great, you just made more than $100/hr. Sadly, this is just 1 week out of the year. It also doesn’t factor in the cost of doing business to actually get that contract signed.

1099 is a mindset. You either like the freedom, the “harder I work, the more I get paid”, or just the lifestyle of having your clients… even if those clients are just like a W2, only with none of the benefits. Worse, many large companies cannot do work directly with 1099’s, and want to do W9. While that’s fine, it’s usually assumed those W9’s are a preferred vendor, or have workman’s comp and a lot of other bs that isn’t needed and doesn’t matter. If you get the W9, great, but if you’re not a preferred vendor and you haven’t convinced the company to go through the process, you’ll simply have some company you’ve never heard of take $10 to $30 an hour off your paycheck. Horrible.

Independent Contractor programmers, someone who owns a company strictly as a tax shelter and is a single person, aren’t usually paid more than $100/hr outside of California, New York, or Boston. So 1099 is usually a no go (exceptions below).

Recruiters

Recruiters are a waste of your time, and theirs.

Many companies lack the resources to “find you”. Even if you make yourself easy to find on the internets, they often won’t look. Swimming through mountains of programmer social media is less savory than paying a fee to someone to “find me someone with these skills”. While smaller companies who recognize the value of good talent DO use Github, LinkedIn, and Google to search for people such as yourself, they aren’t going to dump bling into your lap.

Thus, recruiters are often the gateway to jobs nowadays. Many in large companies like recruiters because it’s not their money being spent, and a litany of resumes arrive in their email with them not having to do anything but ask HR to send a list of requirements of what they need. As such, most job sites nowadays such as Monster, Dice, LinkedIn, etc. are owned by recruiters. I say owned because finding a job posting that ISN’T a recruiter is rare. If it’s not, the likelihood of someone with your skills getting past the often horrible interview web applications or HR wall (“Yes, mam, as I’ve told you, MVP is just like MVC, and Ember and Backbone share many characteristics, so if you know one, you can easily learn the other and be prod… mam? Hello?”)… all for W2 position we’ve already talked about is a no go.

They’ve seen their business explode since the information age started back in the 80’s and 90’s. We have some of the worst unemployment, underemployment, and those giving up and leaving the workforce since 1979. This means a few things.

First, it’s just “normal” nowadays that mid-size and large companies use them. You may not like the game, so you can either get played by it, play it, or make your own rules.

Second, a lot of them are NOT there by choice. We have a swath of college educated youngsters with degrees not in the Art disciplines who just can’t find jobs that their degrees implied. Many went to recruiting because they had no other choice.

Therefore, you shoulder never be rude to them for the above reasons. Yes, I troll them every chance I get, but that’s in good fun. You should never be rude; you never know when you have zero choice but to go through a recruiter for a job. We’re extremely lucky in software, and history shows it will not last.

Keep in mind larger consulting firms like Accenture, Deloitte, IBM, Randstad, etc. are hybrid. They sometimes act like staffing companies, but often have internal divisions that do consulting. Meaning, although they recruit you, can you get above $100/hr rates with them which often includes lots of travel, but is still longer term projects. Still, better to err on the side of caution; bring up money first to save yourself time.

That said, again, recruiters are a waste of your time, and theirs. I made $80,000 at one large company, and another $140,000. We went through the same recruiting firm for the same position. When I once was hiring for my client, the recruiting firm was charging $200/hr and paying him $80/hr. Finally, recruiter rates are beholden to the location in which they are hiring. You won’t get New York city rates in Nashville even if the recruiting firm is national; companies, even for telecommuters, often pay the local rate.

5 Solutions

So if “a job” caps out at or below $100/hr, freelance has no growth potential with maintenance pain, and recruiters are worthless, what to do? You have 5 options that I’ve seen work. I’m sure there are more, I’m just basing the below on what’s worked for me, others I know, and what I’ve seen work from past clients who’ve done it.

1. Build a Personal Brand
2. Score a large client
3. Find a Closer
4. Find a network and form a firm
5. Start a business

Build a Personal Brand

I’ve written about Personal Branding 7 years ago. I even talked in depth about Personal Branding in my video series about becoming a successful freelancer. Make no mistake; the level of effort is inversely proportional to how bad ass you are. This includes either your talent & technical prowess at programming, your charisma, or both. The less awesome you are, the harder you have to work. That’s called life.

Worse, if you cultivate a rock star status, whether on purpose or by accident, fame is fleeting. Trends in software occur just like they do in the music industry. A library you wrote, a blog post that became popular, or an app that scored you money and fame… is only temporary and you can only milk it so long. A personal brand is something that is cultivated often, like a garden. The decisions you make in the beginning help guide it and create expectations amongst those in the industry.

Writing blog posts, contributing to open source, releasing helpful code, speaking at conferences, and writing books are all staples of building a personal brand for yourself. Additionally, networking and PARTICIPATING in the industry, even if it’s just your small niche, are important. You want people to like you, you want them to want to work with you, and most importantly, THEY should be selling the client on you, not you selling the client on you. You don’t have a resume.

Those who have cultivated their epics skills/personality/brand are rife. Martha Stewart, Rachel Ray, Dr. Oz, Oprah, Craig Ferguson, Conan O’Brien, etc. In our industry, Grant Skinner, Bruce Eckel, Linus Torvalds, John Resig, Paul Irish, Joel Hooks, Alex Russell, Joshua Davis, Joa Ebert, and Ricardo Cabello (Mr Doob).

You may not know some of them, which is fine, but also potentially brings up a good point. Some of them spend more time using their talents, and the fame is just a byproduct of that, whilst others get the marketing angle, and help accentuate their work. People like me are 90% big mouth, 10% contribution. Any combination works. The point is, it’s hard work, but less so if you’re talented. And you can’t stop, you have to keep marketing yourself, either through continually producing awesome, or continually producing just enough awesome, and marketing like crazy.

If you’re famous, you can easily charge more than $100/hr for freelance work even for work that’d normally go for $80/hr. Just depends on the clientele.

Con? It’s a lot of work. All the time. Sometimes you have to start at square one if the tech changes. It can be done and repeated and is easier in a objective discipline like programming vs. the entertainment industry.

Score A Large Client

I’ve seen many large agencies and software firms sprout up like this. You’re 1 dudette/dude, 2 friends, or maybe you just know a lot of people you could sub-contract for design and other back-end/front end development if you could only get a large client. What happens is, the contractor gets a large client, can’t handle the size of the project alone, hires people, and voila: a company.

The money comes into play from 2 places. First, the job is obviously larger, thus requires more money to pay more people for more time working.

Second, those more people do not get the same amount you do. There are a variety of factors that dictate how much a designer gets, a front end developer gets, a back-end developer, manager, project manager, qa, etc. The more you make is inversely proportional to how much you pay your sub-contractors/employees. The less you pay, the more you make. Except it’s not you, it’s the company… or are you just paying yourself? That gets into running a business which I won’t cover here. Obviously if they’re an idiot contractor who’s good at coding but sucks at math, you can’t pay them less than living expenses, else they’ll lose their house/apartment/flat in the middle of the project, and that’s no good. Yes, you’ll get people like this.

You then bill those people out at a higher rate. This is how it works with big clients. Large company hires large firm. Large firm hires smaller firm. Smaller firm hires you as a 1099 contractor. The pay goes like this: Large company pays Large firm $300/hr. Large firm pays Smaller firm $150/hr. Smaller firm pays you $80/hr. Now that you’re the Small firm, you now get the $150/hr… and you’re sub-contractors get the $80/hr. Make sense?

The more sub-contractors you get, the longer the project is, or both results in more money in your pocket; well over $100/hr.

How does one score such a Large client? One way, you can become a preferred vendor/consultant/provider of your favorite technology stack. Whether it’s the company that makes it, or those who have a vested interest in it, one things for sure: those who make technology are not consulting firms. They focus on making tech, not forcing a bunch of people to travel to some random location to build something for random business for a bunch of dough. YOU and yours are the ones who actually represent that company and do the actual work. Obviously they have small arms in the sales team that do this, but they usually don’t scale that side of the business.

Another way is networking with past clients. One way to utilize a network you’ve created is to contact past clients’ clients directly if your non-compete is up. For example, lets say you worked for a company as a 1099 that worked on a project for Nike. You did a great job, and had a good relationship with the company, and even had the opportunity to work with some people at Nike directly. Most smart companies will ensure you never talk to them for this very reason. 1 year+ later (or whatever your non-compete states), you reach out to them and ask if they have any work. If you kicked ass, they’ll remember you. Suddenly, that cut in pay is gone since you can form a direct relationship with them either as W9 (corp to corp), and possibly become a preferred vendor for that company: 1 of many companies who gets first dibs on projects they outsource.

Other times, you just get lucky as a Freelancer, and you portray yourself as a “company” with 6 people (who are really part time sub-contractors). Thus, larger companies will come asking you to deliver something quite large. It’s not dishonest at all if you truly can deliver. I’m making the assumption here you’ve worked on multi-person projects and can actually do what you say you can do. It’s all about how sell yourself. Example: jessewarden.com vs. webappsolution.com.

Don’t be afraid to write contracts that are too large for you to handle. If they were, you wouldn’t have the cajones to actually move forward with it, and finding resources for a project that’s too big for you is a good problem to have. It’s already assumed at this point that you know a bunch of freelancers, and might have even put them in a spreadsheet to list their name, contact info, last known rate, and area of speciality. BUILD UP THAT NETWORK and then USE IT.

Find A Closer

All closers are salesman, but not all salesman are closers. Many companies spring out from a talented closer who scores that big client, whether from a cold call or networking. It’s like the previous “Score A Large Client”, except there’s no work on your part: you just unleash the closer and wait for her/him to catch you a big fish.

I’ve seen some successful firms/companies who are basically run by these closers. Many are partnerships where a talented programmer partnered with a talented closer and together they built a company.

Actually FINDING one is where I can’t help you. Most either formed the company on their own or the technical person had a childhood/college/previous company relationship beforehand.

Commissions don’t help, either. “Dude, I know 9% is the norm, but I’ll give you 20%.”

“Oh yeah? How much y’all pulling in a year?”

“Uh… I guess $1 million.”

“My current company gives me 9%, but they rake in 30 million. Thanks for the free beer, though!”

Find a Network and Form a Firm

You can form a firm in 2 ways. Basically, you do #1 where you’ve either established a name for yourself, and find like minded people who want to do the type of work you want to do with the types of clients you like to work with.

The other option is just like her majesty’s life advice: surround yourself with those better than you. You basically find a group of people, at least 1 but hopefully more, who think like you do. You all agree to find work, share work if you’re too busy, or help each other out on projects WITHOUT a premium; meaning you don’t take a cut of the rate from each other. This makes some freelance gigs a lot easier because you can borrow people for helping you out on some projects. Since they make you a priority, and there is no worry about rate negotiations, it’s a no brainer. THAT has some serious value to clients that you should up-sell. Most clients who know what they are doing recognize that already when dealing with companies that have more than 1 person vs. an independent contractor… sometimes.

More importantly, though, is the hope that they already have the preexisting network contacts described above. Even better, you can combine networks. It actually goes over quite well when you describe to the client that you’ve left the previous firm to found your own since that client wants you anyway. They’ll often assume you formed it to work with like minded individuals and you’re still in the idealistic and prove yourself/your company phase.

This is basically what I did when one of the firms I was working with exploded on itself. Preferred vendor, existing client base to get opportunities from, and 3 guys who all have different strengths that compensate my weaknesses, specifically 2 of them doing back-end Java (I’m 100% front end). The bigger clients want Web App Solution, not Jesse Warden.

This is the opposite if your brand is really powerful, though. For example, some strong personal brands form a company, and larger companies will hire them strictly because they want that one person’s expertise/clout/reputation.

$101-$119/hr is no mans land. Once you have a company that consists of individuals, not just a bunch of subs, $120 on up gets tons more likely… because the sum is greater than its individual parts. That has a lot of value to companies who need you to scale, be used to scaling quickly, and have a network of your own to acquire certain resources for certain types of projects (UX, design, business analysts, etc). That and it’s easier for the CPA and lawyers to swallow since you’re a more legit entity to do W9 work with for tax and legal purposes.

Keep in mind, while it’s obviously nice to have a track record that you can show to existing clients of your firm helping companies build awesome, often it’s just as accurate to use past clients as that track record. For example, all of your past freelancing clients you can include in your company’s repertoire of past clientele.

If your partners, or even just sub-contractors don’t have a network, you better have one… else you’re just fishing for the big client with extra lines in the water.

Start A Business

Everything I’ve talked about up to this point has been B2B: Business to Business. Some company hires your company. However, that’s not where the real money is for software development. The real money is in products. Now, granted, you can create products for a certain set of businesses, thus making you a B2B, vs. targeting consumers as a B2C, but the point here is you are NOT a services company: You’re a product company.

If a clients software project fails, your company doesn’t fail. If your a product company, and your product fails, your company fails. Huge difference.

Products also have the nice ability to sometimes make passive income. That means, while you sleep they make money. Some products require companies around them to build and support them, hence the current state of Silicon Valley. The amount of effort gets less every day, as does the cost of entry.

While there is more risk, having hundreds or even thousands of people pay $10/a month for your software is a lot more appealing then hustling multiple times a year to get a client to pay for the next few months. You can flip that around, too; a few dozen customers paying you $250 a month.

While there are a bunch of great articles and books on the subject, here’s the general idea:

1. Find a problem you think you can solve with software, and if it has competition, you think you can solve it better.
2. Build a prototype in less than a week.
3. Show it a potential customer and ask them if they’d pay for it.
4. Iterate weekly/bi-weekly until they do.
5. Get more customers.

Eventually you’ll reach what Paul Graham calls Ramen Profitable. It’s a way longer ramp up time, but has a potentially greater reward. It’s also assumed you’ll fail multiple times getting there which is hard for some people to swallow in a culture that’s all about winning and “the thought of losing… is HATEFUL to Americans.” — Patton.

If you ain’t failin’, you ain’t trying hard enough, sucka!

Dangers

There are a few potential dangers you need to be aware of going the above route.

First, you need to be flexible. Are you willing to accept work at or below $120/hr? If not, can you survive on savings until you find a client? The “I deserve” or entitlement mentality is dangerous. You don’t get what you deserve, you get what you negotiate. Some companies just don’t have that kind of money.

Second, it’s hard to go back to salaried positions once you’ve gone the Firm or Freelance route. The startup route is a lot easier, and the freelance somewhat easier. Often, if the company doesn’t know your brand, it doesn’t matter. You need to be careful how you pitch your “long term consulting” or “short term freelance”.

If you ran a company, you suddenly know a lot about the game, and companies get nervous when you want to quit that and go back to W2. Sometimes that’s uber valuable to them, but as a front line software developer, it’s sometimes hard for them to see that value. Others get nervous if they see a lot of short term gigs on your LinkedIn and/or resume and you suddenly apply for a long term position. If you talk to a business owner, it’s an easier conversation; they get it. Other times this can backfire; “If you’re running a business, why come work for me? What about your competing interests?”. If you talk to an HR, manager, or senior developer, they might not understand at all. Remember, the truth of your history is written by you; modify your social media and resume to match the position you’re going for.

Also, be aware it’s a new world. Going back to the old one can be hard. You can sometimes forget what it’s like to NOT speak about business and software in the same sentence… vs. just software. This is reflected in your resume, social media, and conversations with people.

Conclusions

If you want to break the $100/hr barrier, getting a salaried position, being a single freelancer, or wasting your time with recruiters won’t get you there. There are a few exceptions with freelancing, especially on the back-end. Many Ruby/Python/Scala etc. guys can charge $200/hr to $300/hr in the Bay Area. The key, though, isn’t getting a project for that much money, it’s getting a career where that’s the norm.

Whether building a strongly recognizable personal brand, scoring a large client which is a catalyst for creation and growth, finding a closer, forming your own firm, or even creating a product that itself validates the company around are just 5 ways in which you can break that barrier. I’m sure there are more.

Even not being successful, you still learn a ton, and if you’re a long time software developer, constantly learning and re-learning is probably something you already do anyway. So it’s ok to try some of the things above and fail, especially the last one. I’ve had a lot of failures. I even once refused work for 6 months in an attempt to learn how to double my rate. I failed but I learned a ton.

I also posted a companion video to this post, embedded below, that you can watch.

The Priority Pyramid is a tool I use to stay on track with new consulting clients. It prioritizes how, who, and what I engage in at any given time. It can be overwhelming when thrust into a challenging situation, a code base in dire straits, and a frustrated team. You need a strong pillar of guidance.

This article goes over what parts make up the Priority Pyramid from a high level. I’ll talk about what milestones make up each section and how you navigate back and forward between the priorities.

When done, you should know how to engage your client’s team and tackle working on a large code base at a frustrated client site with 99 problems.

Why?

Over the years, I’ve prioritized what I need to be doing when working my consulting clients. There are countless things I need beyond “coding”, and all have to do with “people”. Code in its own right is challenging enough. Add people to the mix and it gets more complicated than it already is.

Every engagement is different, even with repeat clients. This is why I like consulting. Meet new people, travel new places, learn new things.

While I enjoy and thrive on improv, what I didn’t like was not having a set of guidelines to deal with each new client. The business blogs & books I’ve read are pretty dry, and don’t really focus on the people issues coders encounter and have to deal with. Most also assume YOU are the one creating & maintaing the app, not fixing/modifying a large one extremely behind schedule. It’s either sales, management, or product management. This includes the consulting books. Some approach it from a larger consulting perspective, where you come in, listen to the client’s problems, write up a plan, and pass it off to India. If you are involved, it’s just to either head off major disaster and/or provide face time for the client.

This is NOT what I, and my colleagues I’ve worked with over the years do. We’re in the trenches, working alongside our clients, playing the politics games whilst coding.

So, I made my own rules for engagement, prioritized based on importance, with verification points to ensure I’m on the right track. If I cannot work towards getting through all tiers of the pyramid, I will not be working for the client long, whether by my choice or theirs. It’s important I flush out these red flags early and tackle them full bore.

That… and it has D&D connotations.

Quantitative vs. Qualitative Foundations

I’ve used both quantitative and qualitative results from case studies, white papers, and my own experience to base this set of priorities on.

Mythical Man Month/Brooks’ Law: “Adding manpower to a late software project makes it later”. Some of the bad projects I’ve been on had too many people on them. Your goal at that point is to delegate refactoring to the team to compensate, lead with good architecture, and leverage your trust currency to guide the various teams into a direction you need them to go. Also known as software chaos management. This requires you be at a high enough level to be in charge of various teams. If you’re not, God help you.

Code Review: One person, reading code for up to but not exceeding 1 hour finds more code defects than unit testing. This is not peer review, but that is also effective. Citations: Code Review at Cisco Systems, Klocwork/Forrester “The Value and Importance of Code Reviews”, and some other stats from Code Complete. Keep in mind while most of the studies mention that defects do not significantly decrease after 1 person, the ability to learn from your peers and getting architecture suggestions are very well documented in the blogosphere.

Cheaper to Find Defects Early: Whether you are ruthless about upfront requirements gathering and/or initial architecture, or are adamant about short development iterations that includes scope reduction, both allow the ability to find more defects early. It’s easier to both find, and fix problems earlier than later for a variety of reasons (code size, feature acceptance, contractual obligations, etc). Beyond the IBM studies back in the 70’s here’s an excerpt from High Quality Low Cost Software Inspections. Also, crazy charts from Capers Jones (they have some other good studies). This is why I’m so adamant about getting the visual design (wireframes/design comps/ux/information architecture, etc.) right from the get go, even if 6 months into the project. Lowest hanging fruit and saves tons of time/money.

Distributed Development (PDF): The result that physical distance between developers doesn’t matter. Different room/building/country… not a big deal at all. What matters is how far the software developer(s) are from the stakeholder(s) in the organization management hierarchy. This is extremely important. I am firm believer in both telecommuting as well as on-site visits with clients for communication & leadership reasons. This is central to identifying the power structure of the organization in Tier #2 and garnering trust with those who can help you talk to who you need to talk to in Tier #3. I’ve been ineffective at more than one consulting engagement because I wasn’t  high enough to affect the required positive change.

Toyota Production System: Their continuous improvement philosophy and respect for people are what really ring true to me. While It Takes a Village to build great software, sometimes you have a crowded, drama filled city that you have to work within. Doing your best to get the team motivated to constantly improve, and SEE the improvement occur over time for motivation reinforcement, is just a small way to continually improve. You can only do this if you do in fact respect the people you work with. Empowering leaders amongst those who actually do the work can lead to effective production. You can use these Toyota Process strategies in your own team delegation.

The Priority Pyramid

The 8 steps are in order of importance:

1. Report
2. Understanding
3. Trust
4. Lead
5. Build
6. Explosions
7. Diagnostics
8. Architecture

While it implies 4 are about coding, make no mistake: The Priority Pyramid is all about people. It’s built on your relationships with them and those relationships ensure you can do your job.

Lets break down the tiers the following way: What milestones do you need to complete, how to do you move on to the next tier, and when should you move back? I make the assumption if you’re on a team, you’ll divide tasks appropriately.

A Note on Tier Foundations

Each tier works on top of the foundation of the former. If the foundation is weak, it won’t strongly support the one on top. If you don’t have the trust of management and your co-workers, it’s difficult to lead them. If you don’t have a good understanding of the company and people who work within it, it becomes very difficult to affect positive visual design changes to make architecture easier. It’s ok to be in Tier #8 and realize you need more understanding of how the application will be deployed from Tier #2; just like refactoring code over time, you can continue to strengthen the foundation tiers over time as well.

Tier #1: Report

Milestones Before Arriving

1. You’ve talked to stakeholder(s) on the project to have an idea of what you’re getting into.
2. Verify you actually want to get into it. Some consulting gigs are hard to get out of. Some can reflect poorly on your firm/you even if you do a good job. Make sure you’re willing to make the plunge. We’re looking for red flags here to save you tons of money and stress. I’m not saying be choosy, I’m saying be careful.
3. Where you’re going, who you’re supposed to see, and when.

Milestones

You/your firm has scored a client, you’ve booked your airfare + hotel, and you’re 1st day on-site has arrived. You look sharp, are excited, and looking forward to making a good first impression.

1. First question out of your mouth after small talk should be “Who’s do I report to?”. Yes, it’s ok to follow up this question once you’ve scored more rapport with “Great, so… who’s my boss?”. This ensures you don’t do good things that get you in bad trouble.
2. Second question: “What will make you happy when I leave?”. This helps verify why you’re really here, and what they’re really paying you for. Sometimes this takes alcohol to get the true answer. Sometimes just a neutral setting outside of the office/building.

Successful Exit

Know who you work for and your true goal in life for the next 8 months.

Tier #2: Understanding

The best communicators are good listeners. Your task now is to look people in the eye, lean forward, and listen well.

Milestones

1. Listen: Get people talking, asking questions, and listen to what they say. This is the most important step in the entire pyramid.
2. Goals: You need to understand what the goals are for the project, both stated and real. What are you and the client really trying to accomplish? Answering & documenting this will guide your actions for the rest of the project, overridden only by “Who do you report to?”.
3. Problems: What are the problems and challenges the company has run into? Do any relate to why you’re here? Do they have a thorough list or are there more? Solving problems earns trust, and helps in the next tier. It also validates your paycheck. Why does the client have those problems? Where do you fit in? Who’s accountable for identifying solution(s) for and solving those problem(s)? These are your first challenges in the game.
4. Dissect People: This is also an opportunity for you to start learning who the players are in the game. You need to understand what makes someone tick to best interact with them. Do they like business first, small later or the opposite? Do they have ulterior motives? Can they be trusted? Can they give you valuable intel on the project others won’t? What will it take to make them comfortable enough to tell you more? How can you possibly help them? You’re going to be spending the next 3 to 18 months with these people. Get to know them, make a good first impression, and understand them. These are the people you want on your team, who you want to do certain things for you, who you want to trust you. Once you understand them, you can effectively engage them. Sometimes this is done simply by watching how they interact with others. Ask questions to get them talking; their personality whilst reveal itself. Finally, figure out who reports to whom for real? What is the power structure? You’ll need to play within this framework; best to know how it works for real vs. what the label says on their door.
5. Explore: Finally, code stuff. Time for initial reconnaissance. Taken what you’ve learned, it’s time to verify what you heard is recent, relevant, and can be corroborated with the code. This should still be framed from a “learning the company” perspective. You need to:
1. Learn the Data Model: The VO’s, the Services it calls, and what those business objects actually mean to the organization.
2. Learn The Framework: How is the code architected; what framework did they use?
3. Understand The Story: With another developer, preferably one who worked on the code base and/or your client, ask the developer questions to learn the story. Even the worst code base has a reason how it got there. Like an archeologist, you want to understand this history, the pivotal decisions, or lack thereof, that made it the way it is. You’ll learn the to respect, and pity, even the worst code base once you’re armed with this knowledge.
4. Look For Red Flags: Both the currently benign, and the “holy eff we’re eff’d”. Whether that’s everything being a hashmap in Java, Angular & Backbone both being used in the same code base, or ActionScript 2. You don’t want surprises, you want to frame your perspective of the code base with your client’s. This is a VERY important step. Don’t say it, but talk about it internally in my mind. Find out why there is a disparity in perception.
5. Look For Mines: Like red flags, these are things that down the line of a project, based on what you learned above could go boom. They aren’t a priority but need to be documented.
6. Look For Validation: Did everything you learned in Steps 1 – 4 get validated or where you completely off? If so, continue to dig, and redo steps 1 – 4 to re-verify.

Successful Exit

When you firmly understand the client’s reality, the reality the code reflects, and the real reality once you’ve resolved the two, you’re ready to move on. If they still don’t mesh, keep asking questions & researching.

Tier #3: Trust

Assuming you’ve made good first impressions with those you’ve met, it’s now time to validate those initial impressions in those you’ve met. It’s time to start building trust.

Milestones

1. Provide Immediate Value: Check in code into the company’s source control your 1st week there. Preferably the code fixes a bug. Do NOT try to save the world in the code base. Pick some litter instead. If you clean the entire thing in a day, great, but get your feet wet and see what happens. A lot of drama and things you couldn’t predict happen AFTER you’ve checked in code and it goes into production. Start small and work your way up. Just ensure it’s immediate.
2. Make Professional Friends: Respect those you work with and get to know them. Whether this is small talk that’s sincere or genuine interest, whatever works to build a positive relationship. People trust those they like. Trust is a currency you’ll sometimes have to spend in buckets to make positive headway so start investing in earning some now.
3. Visible Logger: Invest in a visible logger. Even if the code doesn’t currently have problems, when it does, you want it to talk to you. Not only you, but the company. You want to corroborate this communication with your boss. When production explodes, and you know within seconds because your little secret keyboard shortcut debug window shows the error, that inspires confidence. It also provides a kind of transparency to your client when others start using it proactively to find problems. You just empowered a company to work together; well done, that’ll earn some trust. Make the code talk to you so you can trust what it’s saying, then expose this communication channel to your client.
4. Provide Transparency: As you start getting your feet wet, whether this is struggling to get your environment setup so you can compile, or are deep in the bowels of fixing your first bug, let your boss know. Keep them appraised of what you’re doing on regular intervals, even if she doesn’t ask. Come across with confidence; you KNOW what you need to be working on, and you’re informing your boss as such. Additionally, she has a chance to re-prioritize if you need to be working on something more pressing. No communication, and neither of these things happen. If they know and have confidence in you doing what you say you’re going to do, they can play defense and keep their boss off your, and your team’s back.

Successful Exit

Do you think people trust you? Have you checked in working code that fixes a problem and your boss has verified this? Can you even compile? Do you know the names of those you’re working with/near? If yes to all, you’re ready to move on.

NOTE: If you ever lose trust, fall back to continually adding immediate value. Trust isn’t given, it’s earned. If you lose it, the only way to get it back to is re-earn it from scratch.

Tier #4: Lead

At this point you know enough about the goals of the project to start formulating plans on moving forward, whether this is how to implement new features or how to fix/refactor existing ones. You’ve provided enough value to earn a modicum of trust. It’s time to lead people forward.

A manager puts people in a line, puts the guy with the machete at the front, and leads people through the jungle effectively. A leader climbs the tree, and tells everyone they need to go left instead.

Milestones

1. Short Term Goals: You’ve assessed the situation and identified priorities that need to be refactored (using my previous article). You need the team to agree on a common logging interface, both in code and visually. Finally, you need the team to agree on an architecture.
2. Long Term Goals: You’ve identified architecture holes that need to be plugged. Sometimes there are design problems that if changed could save months of work and hardship. You need to start work and documentation on it now. Solidify the long term goal into something defendable, and get the teams input. Be careful how you go about talking about it. While you need client feedback (remember transparency), it must be attainable to company-relevant, short term steps. You can spend trust currency for longer term refactoring/re-architecture endeavors, but I recommend against it.
3. Resources: Sometimes you need to hire additional people, whether from internal client teams, additional consultants/contractors from your firm, or hiring on behalf of your client. This could be staff augmentation or hiring a specific skill set you need/want. Identify these early and ask your boss.
4. Divide, Delegate, and Conquer: Whether the client’s employee’s or your firms, you need to divide up the massive amount of work amongst people. Offer up tasks first, and then assign to those you deem appropriate if no volunteers materialize. Building upon Tier 2 and 3, you should have a gut feeling for who’s best for what task. You cannot save the world by yourself. It may seem that you spend more time aiming people in the same direction then actually walking that direction yourself. Don’t fret; you’re on the right track.
5. Be Positive: While misery loves company, people like and follow positive people. In talking & delegating all of your goals, plans, do so positively. You’re not “fixing a pile of rubbish”, you’re “building an awesome application” or “improving an important machine” or whatever you can say and actually believe when you say it. Eat right, exercise, and/or surround yourself with positive influences. Make this the year you commit suicide, reorganize & clean your working environment/home office, or just accomplish a small goal that’s not work related that you use as positivity fuel. Mentor & encourage your team but don’t come off as a know-it-all/holier-than-thou. Play to win.

Successful Exit

If you know what you/your team needs to be working on today, next month, you’ve approved the hiring you need, and the team is all tasked up, then it’s time to move on.

Notes on Tier #5 – 8

The latter teirs are development specific, but rely on a strong firm foundation from the first 4. Remember, the human component is your weakest link, not your Factories. Strengthen them; do not enter these 4 latter tiers of first 4 are weak.

Tier #5: Build

You need to easily build the software. This is the most common, and frequent, option you’ll do many times a day, every day. The longer this takes, the longer it takes you to develop. This can also kill your team’s momentum. If something goes wrong, such as someone checking in a bug that breaks the build into source control, or a feature needing be implemented for a presentation by some date, a slow build exacerbates time to resolution.

Worse, some developers will start making their own build setup, leading to code that works on some developers machines and not on others. Validation of working code suddenly becomes meaningless which can adversely affect project schedule metrics. Even worse, you can think your code works, but it doesn’t for others. Who’s right?

Milestones

1. Quick: The build needs to run quickly. This obviously an arbitrary metric based on code size, libraries, continuous integration setup, etc. If developers say “the build is slow”, then it’s slow. Utilize libraries so the entire thing doesn’t have to compile, inject dependencies at runtime, utilize modules… whatever it takes.
2. Easy: If the build is complicated to do, you’ll get developers making a lot of mistakes during code validation time before they check in. They’ll either check in bad code, or make their own setup that allows the code to work on only their machine. They should be able to just click 1 button, run an Ant/Maven script, or do a 1 line command line execution.
3. Duplicated: The build should be able to be duplicated on a new developers machine. It’s completely fine to have company standards, such as only Windows 7 PC w/admin rights, Flex SDK 4.6, running Rake 0.8.2. It’s also ok if that takes some time with another developer to setup. What’s not ok is once they do that, it doesn’t work. If there are 3rd party dependencies that cannot effectively be deployed x-machine, find a way to remove them. Solutions include, again, using libraries, modules, development servers vs. local server setup, etc.

Successful Exit

If you can run the build multiple times a day without pulling your hair out, it can be run multiple times on the same code base and not break, and anyone on the team can explain to a new developer 90% of the setup, you’re good to go. Another validation includes Developer A checking in code, then Developer B updating to latest and running the build and it works on their machine as well.

Tier #6: Explosions

When things go awry, you need to immediately know where and why. More than a euphemism for errors/exceptions, explosions also include errors in the application that constantly cause fire drills in the company.

Milestones

1. Exceptions Handled: Handle all errors save null pointers. If you have global exception handling capabilities, implement it/them. This doesn’t mean just wrapping something in a try/catch; it means not only logging the catch, but putting something meaningful in the catch so you’ll understand what it means when it happens.
2. Logging: You need to centralize all long into a single library. It’s ok if this library is your own that builds on top of the built-in provided one, such as Flex’ ILogger. As long as anyone, anywhere on the team wants to log something, they use that vs. print/trace.
3. Visual Log: Optional: A visual window, built into the application itself (SWF/JS, etc), that prints out the log levels. This is done to allow logs to be seen by developers, not users. It also allows non-developers, especially QA, to proactively find problems and talk directly with those responsible vs. the 1st developer they can find. The value this provides in empowerment and time saved should not be underestimated.
4. No More Fire Drills: Wrangling in challenging errors to help prevent fire drills can do 3 things. First, you score a lot of trust in “knowing” why something is wrong vs. 10 people running around aimlessly trying to figure out why. Second, you can clearly cite accountability; is it the server-side team, your team, or the database team? Instead of yelling “I think your stuff broke” you can confidently say it did with helpful data for them to test against. That kind of attitude is much easier to solve problems with. Third, fire drills no longer sabotage your productivity.

Successful Exit

If an error occurs and you know where it happened, a general reason of why, and who’s potentially accountable, you’re in insanely good shape. Users don’t see these errors, just null pointers, or those you’ve built a GUI for (ie Alert error dialogue). Bonus points if fire drills happen on other teams that aren’t related to yours… but you have a way of helping through logging to make testing easier.

Tier #7: Diagnostics

Diagnostics form a range of tools, not just code. They are anything that helps provide insight into code issues or runtime errors without costing more overhead in maintenance than the value they provide. The reason diagnostics is before architecture is that in larger applications, especially in a consulting context, adding simple diagnostics has a ton of value with little effort whereas architecture takes a ton of effort but tends to have low perceived value (yes, it’s valuable, just harder to sell).

Milestones

1. Unit Test Coverage: Even if you’re not doing TDD, unit tests along help find & prevent bugs as well as improve API’s. Unlike code reviews, they don’t get tired, benefit the entire team, and if written well only slightly add to code maintenance. Finally, they can be automated. These are also great things to work on in down times such as when JIRA is cleared, you’ve hit a brick wall with another bug, or are waiting on dependencies for a feature.
2. Integration Tests: These are my favorite on service layers, more so than unit tests. The reason being is most of the Flex projects that I’ve worked on in a consulting context had some form of service layer problem; ie how they talk to the back-end. Both refactoring the service code and writing unit tests that allowed me to automate the testing. It’s also nice to quickly know what part broke with confidence; client, server, or database. Automating these also makes you feel better when the server guys test new code, you can quickly help them test. There are more to integration tests, but these are the low-hanging fruit of ’em.
3. Automated Builds: Expanding upon Tier #5, streamlining your build process to be more inline with continuous integration practices. This means designating a resource to setup, and maintain, a continuos build tool like CruiseControl/Hudson/TeamCity, etc. You should know who checked in bad code and when.
4. Custom Diagnostics: Some applications have challenging domains of complexity. For example, video; there are TON of things that can go wrong at runtime even if the code compiles just fine. There are also a sequence of events that can cause video to fail, and knowing this sequence is paramount in debugging it, or shrugging it off since there’s nothing you can do (i.e. CDN is down). More importantly, though, sometimes you need a way to glimpse this in a more visual way than a logging window can provide. Conversely, sometimes you need to see environment variables in real-time. This little window can verify your application is running in the mode you think it is for a developer in another country. Simply making a box with a text field in it that showed Flash Player’s sandbox security type saved me 3 days (I lost 3 figuring this out, heh). Additionally, they can help empower others to do testing & diagnostics on their own. Just be careful these are not a security risk for code and/or company information if deployed in production.

Successful Exit

If you have good unit test coverage, can automate their running, your build is automated in some fashion (even if just client side only), and you have gui or command lines way to gain insight to your running application to find out more about errors, you’re in awesome shape.

Tier #8: Architecture

While good architecture requires a book full of information + years of experimentation to get right, what we’re concerned with here is IMPROVING existing architecture. If you are starting a project from scratch and own the architecture, great, use this phase for maintenance. Otherwise, we’re looking for that sweet spot of a 1 day change for a more decoupled, easier to use & test in code system. If something takes longer than 3 days, you’ll be hard pressed to merge it back in and not inconvenience other developers… unless it’s very little code.

Milestones

1. Tight Factories: Any part of your application which takes outside data into it’s system, such as external JSON/XML as well as user input, needs to be further hardened. DRY the code, layer with #moarUnitTests. Form a convention on what happens when parsing/decoding fails; do you throw errors or return null and log them, thus passing the burden of handling null to your system? Decide as a team.
2. Fault Tolerant Services: Whether to a back-end, an external call to JavaScript in a host page, or an ad library… if it’s not your code, it’s a service. Make sure you wrap that with a Proxy that can NOT explode, and logs everything that went wrong. That extra 20 minutes pays off mad dividends.
3. MVC/MVP/MVVM/YourMom/SC/PV/PM: As a team, pick one an over arching architecture pattern and stick with it for new code. I like Supervising Controller, while others of my front-end  ilk like Presentation Model. A lot of JavaScript web frameworks follow more of a Passive View. The only right choice is team consensus & comfortability. Then endeavor as a team to get certain parts moving in that direction. If there is old code, and you’re currently working on it, see if I can convert in less than a day to make more congruent with the rest of the architecture.
4. DRY: If none of the above can be improved, simply making code more DRY is a good fall back task to more unit test coverage.
5. TODO/FIXME/KLUDGE/HACK: Do a find all in the code. If you see those, fix them. #fixBrokenWindows

Successful Exit

You never really exit Tier #8; in fact you tend to loop back to either 7 or 6 and 7 and then back to 8. However, if you find yourself working on new features, or fixing bugs with no other drama and the rest of your team is doing the same… then you’re in epic shape.

Conclusions

As you can hopefully see, my priority list helps keep you focused on delivering value to those that matter quickly. Good software development is iterative. Earning trust is also iterative; you don’t take people’s money and disappear for 6 months (that’s called good Capitalism via Waterfall). This whole list, while referring to software development, is all about relationships with people. Excluding code review, your challenge as a leader is delegating the tasks in each tier to divide & conquer, mitigating conflicts, and solving hard software problems in addition the rest of your responsibilities.

Each tier builds upon the former all the way down the line. While deep in the bowels of fixing explosions in Tier #6, I’m still continuing to build meaningful relationships in Tier #3.

Remember:

1. Report: Know your true boss and what will make her happy.
2. Understanding: Listen, learn about the company, the people, and dive into reading the code.
3. Trust: Earn trust by providing immediate value.
4. Lead: Take the initiative and move the team forward. Delegate, divide, conquer.
5. Build: Make the build fast, easy, and capable of being duplicated if need be.
6. Explosions: When things go awry, you need to immediately know where and why. Prevent fire drills.
7. Diagnostics: Get good unit test coverage, integration tests, automate your builds, and build any custom diagnostic tools needed.
8. Architecture: Decide on a direction/framework, and continue to nurture the code, and developers, in that direction. Loop back to 6 & 7 if need be.

Title photo by Ewan Monro is under a Creative Commons – ShareAlike Attribution license.

1. The User is the Most Important Thing
2. If You Don’t Evolve, You’ll Die
3. Using OOP, Design Patterns, Frameworks, and TDD with the Right IDE Will Solve All Your Problems
4. You Can Code Something Right The First Time
5. There is a Clearly Defined Career Path in Programming

1. The User is the Most Important Thing

Making money is the most important thing.

Anyone who says the user is the most important thing hasn’t been in enterprise software, is endeavoring to fight against bad software, doesn’t run a business, or is talking about Open Source.

If you want good software, yes, you should pay attention to the user. Doing informal user testing, engaging with real users/customers while developing the software should be done. Investing in design early, heavily, and constantly are great ways to lead to building software that has a great user experience that people want to use.

That doesn’t implicitly make software magically sell itself. For mid-size to larger companies, those using the software aren’t the ones who pay for it. Often they’ll never use it, nor see it. They’ll be looking for the right marketing messages, and/or validation that it solves key problems THEY are concerned about. They are hoping to solve what they perceive as important problems to their business, not those actually using the software in their day to day jobs for their business.

A lot of the most profitable software is the most tortuous to use. Case in point, SAP. Atrocious user experience. Yet, it sells extremely well (well, did, heh, read Blue Ocean Strategy). SAP can “run your entire business”. No other software product can make that claim with that much history to validate the claim.

This is important when you consider extremely large companies with a variety of different departments from HR to shipping, to finance, to IT. Even a modicum of perceived productivity enhancements across the board implies a significant amount of money saved. Remember, the 3 ways to make more money in a business:

1. Raise your prices
2. Increase your output
3. Lower your overhead

If something can “run your entire X” where X is “your business”, “your IT hardware & software operations”, or “patient scheduling for 3 hospitals”, those signing the check are doing so because they perceive #2 and #3 improved. That’s what writes the check to your company building the software, not the nurses who use the software for patient scheduling and loathe the interface. Who cares if they do, as long as people keep buying it, it’s profitable.

Like TRON, I too fight for the User. If you want to build software that’s a pleasure to use, you must focus on the user. Life is too short to produce crap merely for capitalistic gain. Many companies build pleasurable user experiences and are profitable, from 37Signals to Apple.

Just remember making money is the most important thing. The happy user is not an implied gateway to bling.

2. If You Don’t Evolve, You’ll Die

You can learn 1 language on 1 platform on 1 OS, and remain employed with no worries, or get a new job if you need one.

Those insecure about their own career and investment in a particular technology stack project this line a lot. They do it in a variety of ways such as saying it as a factual proclamation for dramatic affect, as an ominous warning, or as a matter of fact statement that is law. Technical journalists creating click bait do this as well.

I’ve been employed & done consulting at enough places to tell this is completely wrong.

Some facts:

1. 80% of the world runs on a 50 year old language, COBOL .
2. AT&T still uses Fortran for some of their dialing services.
3. Although we’re in a tech hiring bubble, university/college enrollment in tech has continued to decline.

Business Insider has 2 good bullet points at the end of their hiring article which explains the problem well.

…skilled labor simply can’t change overnight. You can’t become a top-notch programmer overnight, and becoming skilled and proven takes years.

…this shortage has been around and acute for the past decade.

The same tech hiring shortage we have now is the same one we had at the turn of the century. Microsoft had such hiring problems by 2005, Bill Gates was actively lobbying Congress to ease hiring restrictions overseas since the terrorist attacks of 2001 had made it much harder.

Additionally, it’s a perception problem for new students. In 1999 they were told tech was a path to riches. Then the dot bomb happened, and the media wrote about out of work tech workers with no options, so students fled. Although the opposite now, you still get the same types of scare tactic articles published.

Any software dev who reads even part of that article, or its ilk, will recognize the problems. Learning a new language isn’t what employers need. If you’ve ever done any interviewing or hiring for another company, you’re all to aware of the problems with tech job postings. The job will list 15 technologies when you only need 1. It’ll claim that you must know all 15 as an expert when no one on the planet actually does. It’ll say that you must have all of this or won’t be considered. Sometimes you’re fielded by HR and if you’re honest, you won’t make it through even if you’re the exact candidate they need.

So playing the hiring game is one problem. It has nothing to do with software skills and is rarely taught (well) in schools/colleges. This includes self-marketing, personal branding, and learning how to teach yourself.

The second problem is focusing on languages vs. fundamentals. If you know procedural, OOP, Design Patterns, Frameworks, an IDE, source control, error handling, logging, debugging, formatting, commenting, documentation writing, unit testing, software processes (waterfall, scrum, peer programming, etc), and how to search for help on Google for your problems… it doesn’t matter what language, technology stack, or OS you know. Those same core skills can be applied to any language on any platform. Employers who know this will hire for those skills even if you don’t know the particular language/stack.

GETTING to be noticed by those employers is what you see happen with a lot of unemployed software developers critiqued in those tech journalist articles.

Knowing a programming language doesn’t imply you have core fundamentals. Additionally, you can still remain employed at a company, or get hired to a new one, when you don’t have them.

I’ve worked with companies that have spent $80,000 over 3 months for what they perceived as 10 competent outsourced developers. They delivered nothing excluding emails stating they were working hard. At the end, more money was sent to this outsourced firm to hire more developers… the opposite of what I thought would happen.

I’ve worked with companies who had developers breaking the build every day. The accountability & reprimanding was a company wide email pleading with them to fix the build since with 200+ software devs & QA’s, it brought a lot of them to a stand still for half the day or more over 3 time zones in 3 countries. This continued for 2 years, and only got worse. I never saw any firing or anyone laid off in my 4 months over 2 years there.

I’ve worked with a company where a developer rewrote their core part of a larger application 5 times. Each time, it still didn’t work. They still kept their job.

The stories are countless. The press articles give a false impression of a larger whole that isn’t there. Even a modicum of ability to write code and have it compile will ensure a job. Like writing the first book, the key is to play the game to get the job. That’s the low hanging fruit to learn, not a new language through a college course.

I’m a huge proponent to never stop learning. Even learning 1 new language a year is a wonderful way to improve your skills even in your existing preferred language. A college course can work as well if that is your desired way to learn vs. self taught.

Do not think, however, if you fail to learn the latest new tech your job is necessarily in jeopardy. Depending on the company, I’ve seen teams, not just individuals, who provide no value, are hostile to work with, and yet keep their employment. They continue to produce no revenue for the company years later. Learning politics in that case is more valuable than learning Ruby or Scala. Others aren’t actually specialists, but someone who “codes what they tell me to”. They in effect become Jacks of All Trades in that they’ve touched a lot of technology types for that particular company.

What these developers, who proclaim “evolve or die” statements, are really afraid of, and thus projecting onto the world, is mediocrity. They do not want to be bored, under paid, or unchallenged in their jobs. They don’t want to “have a hard time” finding work or a job. They want to have fun, be paid well, and be challenged all the while being courted with lots of job opportunities. They want to feel that their technology choice is in fact relevant, and ensures they are achieving those goals.

I can tell you with confidence there are a lot of Unknown Coders out there with as much job security as the next coder. This doesn’t even touch upon how hiring a college kid right out of school for $100,000k, who actually costs the company money vs. providing revenue, actually helps the company because it ensures the competition doesn’t get a potential, even if that potential cannot be easily recognized.

3. Using OOP, Design Patterns, Frameworks, and TDD with the Right IDE Will Solve All Your Problems

Learning, applying, experience, working with mentors, and having stakeholders who care & are apt leaders makes software development easier. Having competent designers who get what you do and are actively involved along with helpful QA and good Product Managers also help. As Dave Wolfe said, It Takes A Village.

Just because you know how to use Object Oriented Programming in your particular language, or even many, doesn’t make all the other problems go away. You still have to think how to solve real world problems via code. You still have to think, AFTER you’ve written the code, how on how to make it more DRY. You still have to interpret other’s “perception” of what they consider to be OOP vs. your own. You still have the overhead OOP has in creating more code and have to in turn manage this. In short, you have to think more. Good software allows the user not to think. Code that’s clever is usually code smell.

Design Patterns are still concepts, even if you understand them, and can effectively communicate to team members using those terms to help understanding. Every developer tends to implement them slightly differently. You need to interpret how to apply common design pattern solutions to real world problems. You need to interpret how another developer has implemented a design pattern, and what their interpretation of the value is. In short, you have to think more.

Frameworks are an interpretation by an individual or team on how to solve common software development problems. Using learned conventions, configurations, and forced (re)definitions on existing concepts, you and/or your team are theoretically capable of solving common problems, working together easily on the same code base, and having that code be more easily modified by your team or a different future team.

A framework is usually an amalgamation of OOP and Design patterns with a particular belief on how things should be defined, implemented, and thought about. You need to sometimes change your thinking, adopt that mind set, and teach that to those under you through analogies that are congruent with existing literature on traditional software OOP and Design Patterns. In turn this needs to be related to your current technology stack. In short, you have to think more.

Using TDD, or even just unit tests, or integration unit tests, helps in a lot of places. For building API’s, it forces you to actually be a consumer of the API you are building, and thus results in a better API. It also helps with backwards compatibility. Reading the tests helps document how to utilize the code. For loosely typed languages, it helps reduce the amount of time hunting down null pointers.

You now have to write more code to test existing code. You’ll find you have to manage a separate code base. You have to maintain the tests. Even if you don’t test first, you still have to ensure your code is easily testable. This requires re-refactoring. Usually more challenging, however, is to encourage your team members to not only write their own unit tests, or help you maintain yours, or at least make their code easier to test so you can write them if they are not test proponents. All this assumes your GUI and path of development doesn’t take drastic changes early on negating large portions of your design & code base. In short, you have to think more.

A comfortable developer is a productive developer. A good chair, a quiet (or loud) environment, and a helpful IDE. Doesn’t matter what it is (VIM, Eclipse, Visual Studio), as long as the developer likes it, it helps them code faster, and helps them find errors & debug easier, and thus more quickly. Although learning new IDE’s can make you think more, and take a lot of time investment, whether testing yourself or reading about others’ adventures on blogs, the hope is they actually make you think less… which can help a lot with the above points where you’re required to think more.

Combine this with years of experience, academic and real world learning, and application in a breadth of technology stacks, you should be at the top of your game, never failing. Sadly, this isn’t the case. Simply learning everything there is to know, whether in core fundamentals, or for a specific technology, is in no way a guarantee for success.

The first problem is other developers. Even after you learn everything, getting consensus in programming is actually called “compromise”. Every developer has their own interpretations of implementation details, OOP, Design Patterns, Framework best practices, favorite IDE setups, etc. Some are religiously devote in these beliefs. In driving, no matter how good you are, you need to drive defensive (not professional racing). In programming, same thing; you need to adapt to the developers you’re working with.

Secondly, and more importantly, there are a lot of things that can go wrong, regardless of how smart and/or adept you, or your team, are. This includes users not knowing what they want, stakeholders simply not caring, technical debt created by others, or the company running of out money or simply cancelling the project. Sometimes you’re hired to ensure the project internally or by a separate firm tanks so your firm can take over development. That’s correct: You can utilize your knowledge & experience on how to make software succeed to ensure another software development project fails. Other times you’re just not high enough in the food chain to affect positive change, thus, you keep the Destiny flying for as long as possible.

The good news is as you learn, it does get better. A lot better. In fact, you’ll find that the majority of your time is spent not in software, but trying to fend off those types of problems. Just like how science continually answers questions that just leads to more questions, so too does learning software development lead you to realize there are bigger problems that can set you up to fail that have nothing to do with software development.

Anyone who says by learning TDD or some language will solve all your problems are selling something, or are the types of people who think that awesome, working software that was never shipped is still considered successful. Keep learning, it’ll pay off.

4. You Can Code Something Right the First Time

The best way to code software is to release early and often.

This means you code it as quickly as possible to get a working build in front of real users. You take their feedback, filter their responses into a more accurate flight path, and move forward.

There are a few problems with this. In my experience, most people do not do user testing, even in an informal context. While it’s a horrible shame for companies, it can be dangerous for software developers. There is a reason why Joel Spolsky and others recommend software developers answer support requests from customers. While having incentive to fix the problem is one thing, it teaches relevance.

Software developers, especially inexperienced ones, have strange perceptions of what’s relevant to do at a given point and time. This is completely justified in that they are required to create their own tasking for building software which is complex, has a plethora of details to keep track of, and future ramifications that they need to watch out for because they’ll be the ones to suffer them, and no one else will.

One example, a start up I worked with spent months on building a core product. I continually pushed for, and failed, at getting them to get real users feedback. 8 months in we finally did and we had usability problems. We knew about them, but it was a lot harder then to make drastic design changes. We forged ahead anyway. A year later with the 1st customer, they only actually needed 10% of the interface in a specialized form to run their business. We canned the other 90% and pivoted to use a completely different interface for the CMS to support it. Torching 11 months worth of code, and letting go of a pivotal, valuable team member was completely lame on a variety of levels.

Another example, I had one developer spending an inordinate amount of time optimizing the underlying architecture of a cover flow like component. Being in charge, and knowing how both versions of the component worked, I told him to move onto other tasks as it worked fine. We vetted a build with the customer that day, and they preferred the sortable list vs. the cover flow. I should note that the previous day, the customer liked the cover flow, and felt it worked/performed just fine. The developer in question heard this, and seemed visibility happy to hear this. I can only surmise in their pyramid of needs, their need for approval drove them to hone on this particular component to ensure it performed optimially to maximize the client’s approval of their work.

Bottom line, the client didn’t need it once we provided a better design. Going with this same pyramid of needs theory, the developer started to modify the list control to be faster. While I didn’t agree with the amount of time spent, at least his work was now relevant.

Again, when giving the software to the user, you can validate what you are spending your time on is actually valid. Same with answering support calls; you as a developer have an incentive to fix the problem, both for the user’s sake, and your own.

If you don’t do any user testing, then you have to focus on “getting it to work”. This is why, even without user testing, iterative software development is good in that it forces developers to get compiling code, sooner. They can’t spend 3 days in a cave refactoring some super, awesome architecture because it has to compile and be shown tomorrow.

Another example is DRY. Although some developers think they can predict DRY right out of the gate (like putting methods in utility classes), other times the most valid way of making something DRY is through re-factoring. You won’t see the duplication until it’s created. This happens more in larger projects with multiple developers on disparate and/or non-communicative teams. It’s your job to recognize this after the fact and recommend a solution to reduce/remove the duplication.

Big classes are another. Packages, frameworks, and IDE’s with good search & refactoring capabilities are extremely helpful in managing large code bases. Inexperienced developers think they need to organize now else they’ll be left with an unmanageable mess later on in the project. Not so. You’ll know when it’s getting too big. At that point, you can refactor it out into multiple methods, classes, etc. Obviously you’ll already know how much forethought you can put into it. You’ll reach a point, however, where you don’t know and you’re guessing. Unless you have a valid reason, it’s best to start coding for the now. If you can’t refactor, you’ll learn. Refactoring is the one skill gained through experience which allows you, and your team, to be successful in iterative development.

Plan for what you know, not what you don’t. Being good at refactoring will save you if you get cornered. Remember, 80% of a Scrum Sprint is spent refactoring. No software is ever 100% “right” when you build it. I can tell you, though, if you work hard, you’ll reach a point in your career where you’ll love your code, your architecture, your tooling, and your approach. Your only problems at that point will be preventing politics from sabotaging your courting of users.

5. There is a Clearly Defined Career Path in Programming

Once you become an architect level, you have 3 options: Continue on, become a manager, or start your own company.

I bring this up because no one told me this lie. In fact, no one told me anything. I was raised by good (and bad) role models from the WW2 and Baby Boomer generation. To them, you worked hard, and climbed the corporate ladder for success.

However, some cultural changes happened since their generation. Globalization, outsourcing, and easy to make companies with readily available investment. Software started actually impacting consumers lives, not just businesses. Oh yeah, and the Internet. Once Microsoft became the most profitable company, the Information Age started.

You no longer had pensions at companies. You didn’t work there for life. You didn’t “deserve” certain things because you had seniority. People became a lot more expendable. Replaceable. BA’s and MBA’s no longer guaranteed a job.

I didn’t at the time know any of this and fell in love with software. Fast forward to 2006, and I became… stuck. There wasn’t any clear path on where to go. My father and step-father weren’t any help because they couldn’t comprehend my career path, let alone what was “next” since it’s so vastly different from their generation. The best I could do was research what others do.

What I’ve found is what I’ve wrote. Either you stay hungry and keep learning new things as a developer or branch out into consulting.

Others will turn in their developer hat and go into management, whether as a perceived increase in pay, value, or just because that’s where they think they’ll make more of a positive impact (like the things that affect lie #3). Perhaps they’ve lost the hunger and need something new.

The third is they start their own company. While being technically savvy is good, and being able to target a market you already know in B2B, or even consumer is also good, it’s easier nowadays with readily access to investment capital even if you are a developer.

The other option is just to continue your service work, whether that’s freelance to choose your projects, make more money, or even creating your own consulting or software development shop.

I’ve been with companies that had “career paths” for software devs, but they didn’t make any sense to me. Either they were merely title changes that had very little if anything to do with software, had a bit more authority that didn’t really help with actual development, or lead directly to management positions.

On a positive note, I will say doing architecture for large teams, consulting, freelance, and running or working for startups offers a tremendous opportunity to learn new, relevant skills.

If you’re looking for the old guard style of career path, software from what I’ve seen doesn’t have it. They do have defined paths in government and larger organizations, but the incentives to “rising in the ranks” there are either pay raise, or authority levels, and you don’t code anymore.

Conclusions

Remember, software that makes money is the most important thing. If paying attention to users helps, great but never forget the first.

You don’t have to learn the latest tech craze to stay relevant and employed. You should learn, however, to make it easier if you want career flexibility. Make it fun. It SHOULD be fun. Create sample projects that are creating something relevant. You don’t have to finish, they’re just to learn.

Learning software fundamentals and mastering them will not lead to some software utopia. Individuals are smart, but people are stupid. You’re coding for, and amongst, people. Continue to master software, and then you can focus on the larger problems with much prejudice.

Given how users never know what they want nor can they effectively communicate it (nor clients), and businesses’ needs constantly change, software development is 80% refactoring, 20% calculated risks. Move forward, relying confidently upon your skills. If you need to change direction, refactor.

Knowing that a career in programming results in a life long career in programming, management, entrepreneurship, or running your own software shop, be aware of that early and work towards it vs. suddenly learning about it like I did.

Download – Keynote | PDF | JPEG’s | Slideshare

Resources Referenced:

• Steve Krug’s Book “Don’t Make Me Think”
• Gary Vaynerchuk’s Book “Crush It!”
• “Minimum Viable Product” blog post
• Startup Book “Start Small, Stay Small”