Top Ten Things You Should Learn from your Job Search and Interviews

Turning a Losing Situation in a Win-Win

Think of interviewing for a job as asking someone out on a date. You find someone you are interested in, you ask if they want to meet, they say 'yes' sometimes, then you meet and talk to see if you hit it off. Then, someone may make you an offer, and you live happily ever after. But that is about where the similarities end, so get your mind out of the gutter. Now let's talk about how job interviewing differs from dating.

Job searches are like an open-book test that you can re-take as many times as you like, each time earning a better grade. If you make a point of learning something from each interview and making adjustments before the next interview, your chance of success goes up each time.

 

Here is a list of the things you should find out before, during, or after the interview. The first three are things you should research in advance, the next three are things to ask during the interview, and the last four are post-interview tasks.

 

1. Research the Industry Expectations and Standards

Don't be surprised going in. Do your homework, so you know what the industry pays, what hours to expect, what skills you need, etc. Know whether you need so-called "domain-specific knowledge" (i.e. how important is industry expertise).

For example, I once was told that I was a shoo-in for a job in a financial company. I had been through four or five interviews that all went well, and I was just supposed to get the final stamp of approval from one of the VPs. I had researched his background on LinkedIn and could tell he was not a programmer so he was unlikely to ask me any technical questions.

I thought it might be a very easy interview. Instead, he asked very specific questions about financial terms. He threw out acronyms and the names of standards that I really didn't know. Try as I might to relate my prior experience and background to the current position, he just wasn't willing to take a risk on someone without financial experience on his resume.

Early in the the interview, ask, “What sort of industry-specific experience do you think will be most relevant to candidates such as myself?”  If you didn't get the job this time, you'll know to check the job posting requirements more carefully next time!

2. Research the Company and its Products

It is best to do some research on the company ahead of time. Start at the company's web site and read beyond the job openings. Read about their products, their press releases, and their staff. Does everyone look young and fresh, or old and experienced? Does the company sell itself on its innovation, or on its history and track record. What key words and phrases appear on their site? What are their core competencies? Do they match yours? If you work with a recruiter, ask what s/he can tell you about the company.

Be prepared to act like a product manager. If the interviewer asks, "What one innovation or improvement would you suggest for our products?" you should have an answer ready. This demonstrates you have done your research, have thought about how you may contribute, and can articulate your interest in and understanding of the company's core mission.

3. Research the Interviewer

Always find out about the person you will be interviewing with. This is easy, because you always know the company they work for, and you will usually have at least their name, and often their job title. Use Google and LinkedIn to find out more about them: where they went to school, what degree they have, how old they are, etc.  Check the company web site, especially if you have only the interviewer's first name.

If the interview goes south,  you should at least figure out if it was something related to the person's background. So the best hint you have is knowing the context of the person you interviewed with. Stay away from the obvious landmines, such as personal issues, politics, religion. Stick with the stuff in your roundhouse, such as sports, travel, or a shared alma mater.

The number one reason you will get the job is because of a shared personal rapport with one or more decision makers. Never underestimate the personal touch!

Often, you'll interview with multiple people on the same day or over the course of several days/weeks. Always ask the current interviewer about the “next” interviewer. For example, “Well, thanks very much. I understand I'm supposed to interview next with Bill Smith. What do you think will be the most important qualifications that Bill will be focused on?”

4. Always Ask what the Company is Looking For

The hiring party is always happy to tell you what they are looking for, so ask! But don't focus on the candidate (you); focus on the company's needs.

For example, you might ask, “What would you say are the two most important skills or qualities you are looking for in the ideal candidate?” That's okay, but can also sound amateurish.  Put the focus on the company's needs.

A much better question to ask might be, “What are the two greatest needs for your team based on the skillsets of the existing team members versus where you need to take this project?”

Or try, “What are the two greatest obstacles between this project, as it currently stands, and where you want to be in the next six months?”

5. Know the HR and Hiring Committee Process

Understand how hiring decisions are made at the company. Some companies allow hiring managers to select candidates on their own. But very often, it is a group decision among colleagues.

For example, you might interview with two programmers, one director, and one VP.  As long as no one has any objections, a strong recommendation from one interviewer (such as a technical interview/test) may carry the day.

But the decision may be made by people who have never met you. At a hiring meeting, the Hiring Committee might review your resume, plus receive reports from each person who conducted an interview.

At such meetings, the hiring manager has to “go to bat” for you. S/he may be unwilling to do so it, for example, you haven't completed a college degree in a relevant field or if your work experience is a bit thin.

The likelihood of getting hired is inversely proportional to the political capital that has to be expended to get approval to hire you.

If you think you are going to be presented to the hiring committee, ask the interviewer, "Are there any questions regarding my work history or credentials that you'd like me to clarify, or do you have everything you need?"

6. Ask About Other Open Positions

Find out what other jobs are open at the company (many are never advertised).

Especially if the interview doesn't seem to be going well, always ask if there is another position in the company for which you might be better suited.

During the interview, ask something like, “Based on the job skills I have, what roles do you think I might fill in this company?” Or, if the interview is going south rapidly,  ask, “Who else might I speak with about other roles in this company for which I might be a better fit?”

7. If You Didn't Get the Job, Figure Out Why

The easiest way to find out why you didn't get the job is to ask. Sometimes, the hiring party will be forthright. It may be as simple as, “We are looking for someone with more Java experience,” or, “We were looking for someone more senior,” (your experience is too skimpy) or ,“We're looking for someone more junior” (you're too expensive, too old, or too arrogant).

There are lots of reasons why the interviewer might not tell you. When working with a recruiter, they might be more likely to give you the reason. If someone won't tell you the reason, then try to figure out what you thought was your weakest point. Did you talk too much and ask too few questions? Did you answer their questions accurately and succinctly?

If you don't feel comfortable asking why you didn't get the job, make it less direct and easier to answer, such as, "If I'm looking for similar jobs in the future, what is the one thing you think I can improve on most?"

Don't worry if you don't get a given job. That's okay! But be sure to learn why not, so you can begin to make course corrections. If no one will tell you, ask your best friend if you have b.o.

8. Learn the Answers to Questions you Failed

Look up the answer to any interview question you couldn't answer. Research any topic/skill they said was a requirement for the job. This one is a no-brainer, yet most people fail to take heed!

Suppose you are interviewing for a Project Management job and the interviewer asks how familiar you are with MS-Project. If the answer isn't “fluent,” then you probably have to go out and learn it.

Or suppose they ask you to describe the software development life cycle, or compare waterfall and agile methodologies. Guess what? You need to look those things up and practice discussing them intelligently.

9. Hot or Cold?

Remember that kids' game where you'd walk towards some unknown item and the person running the game would say "getting hotter" or "getting colder"? Well, your job search is the same. You will be getting constant feedback about whether you are getting warmer or colder.

Are you getting more or fewer responses? First interviews? Second interviews? Job offers?

Make an honest assessment of which direction things are going. If things are improving, be patient. If the trail is cold or getting worse, you need to do a serious personal and professional reassessment.

10. Major Reassessment

If you are on the wrong track, it may be time for a significant change in your approach. Do you need to learn a new skill, switch fields, accept lower pay, or move to a different city? Do you need an advanced degree?

Ask for honest feedback from potential employers, recruiters, colleagues, and friends. Then listen, and be honest with yourself. Correct the most glaring flaw, whether it be your resume, your dress, your interview skills, or your unrealistic salary expectations. 

There are a finite number of variations as to how companies operate or why you aren't getting hired.

For example, if you run into four interviews where you lose the job because you don't have a college degree, you either have to get a college degree or apply for a different type of job.

If you keep eliminating the most glaring problem, eventually, there will be no fatal flaw that prevents you from getting offers, and you can start choosing among jobs.

Find the industry that fits you, and find a mentor to help guide you to the career at which you know you can excel.

Conclusion

You might say, “What is the point of finding out this information after the fact? If I didn't get the job, I need to put it out of my mind and move onto the next one.”

You are confusing a single job role with a job search. That one job may not have worked out, but it is probably highly correlated with future jobs you still want.

Think of each interview has a practice swing. The beauty is that you can never strike out, and you'll eventually learn to hit the curveballs if you just keep improving.

So, think of each interview as a chance to get free feedback on what mistakes you have been making.

There are an infinite number of companies out there with which you can get a fresh start based on the lessons you learned at the company that just didn't work out.

Sometimes it is just a numbers game! If you get 100 swings at the ball, eventually you will get a hit.

So get back in the batter's box and take another swing.

Happy job hunting!

Please comment, link, share, etc., and check out the other articles on the right-hand side.

BADASS Scale for Project Assessment

Bruce's Analysis, Deployment, and Solution Status (BADASS) Scale

It is nice to have scales to describe something in a shorthand that is common to all participants. Oldies but goodies include pH, Richter, and Saffir-Simpson.

Here is the scale that I've been using for many years in my cramped little head...but now it's going to be a thing.

The BADASS scale is very simple but will save a ton of time when trying to communicate the status of a software project (or potential project) to your technical managers. The most common question is "How long will X take?" or "When will X be ready to ship?" but that skips the most important part - a common understanding not just of the requirements but where we stand as an organization relative to the requirements in terms of experience and skill.

This scale can be used for things other than software development including sports, parenting, and construction, but without further ado, I'll discuss it only in terms of software development.

We'll start with the extreme negative end of the scale:

Minus Four (-4)

• Might be theoretically impossible (i.e. defies known laws of physics, economics, etc.)

MinusThree (-3)

• This idea is a Bermuda Triangle. Every company that has tried it has ended up in a watery grave, and we have no reason to believe we'll be any different.

MinusTwo (-2)

• We don't know of anyone who has ever succeeded, and we know some people have failed at similar things, but we don't know that this has ever been tried precisely. It doesn't seem that impossible, and we have some expertise that others who attempted it might not have.

Minus One (-1)

• Preliminary indications are that, while it hasn't been proven, it certainly sounds feasible, and we are relatively confident we can succeed if we devote sufficient resources to it.

Zero (0)

• We know others have done similar or identical things, or preliminary research confirms it is indeed feasible. We haven't done it yet, but we know it can be done by the team we have.

Zero Point Five (0.5)

• We have done this, or something highly similar, at least once. What he have so far is just a proof-of-concept (POC) or perhaps a rough beta version. There are no known obstacles that would prevent completion, but there is still some work to do to ready it for internal release, much less public consumption.

Plus One (+1)

• We have solved the problem and implemented a solution but it is still "version 1" of the product. We may have hard-coded some things to get it working, so it isn't necessarily elegant or scalable. We probably need to do some refactoring. We have only done this for one client, with limited scope, so other future clients may need further customization or flexibility. We anticipated what we could, but, with a limited data set, we didn't put in every bell and whistle. There's still a lot of work to do, and we've incurred some tech debt along the way, so it is still a bit early to celebrate. We still have no ability to customize it for different clients rapidly. If you are going to sell the hell out of this solution, we'll need some lead time to ramp up.

Plus Two (+2)

• We have a solid version 1.1 (maintenance release) and are well on our way to version 2. We've released the software for at least two clients, so we've worked out some of the kinks and eliminated some hard-coded stuff. We have proven that we can distribute a single piece of software with sufficient configurability that it can be used by two somewhat different clients (i..e, support skinning, etc.). We are starting to feel confident about software but awaiting feedback from customers, etc. We're not out of the woods but we can see a clearing up ahead.

Plus Three (+3)

• We have released at least version 1.5 and more likely version 2. We have a handful of clients using the software. We've proven that everything works as intended, and there is sufficient flexibility that we can customize it in a reasonable time for a new client. Suppose it took six months to develop the software, but we can customize it for a new client in less than, say, a week, preferably a day or two. We're still cleaning up some tech debt and doing ongoing QA, but it looks like all systems are go for limited scale. The number of unique requests from customers has begun to trail off, so we are 95% confident that new customers won't have unique requests we've yet to account for.

Plus Four (+4)

• We have released the software for at least a dozen clients. We have proven that there is minimal to no "hand-work" that needs to be done for a new client. Set up is smooth and reliable, and mostly automated. We've proven we have sufficient hardware, software, and support resources. The Help system is functional; there is documentation. We are confident we can scale by another 10X factor without adversely impacting other deliverables, reliability, etc. We are 99% confident that we can sell to the target market without having to do custom development for a new client. Our architecture is proven. We have monitoring in place to account for any contingencies.

Plus Five (+5)

• We have had the software in the field for a substantial period of time. Operations are running smoothly. We have scaled it massively (100x or 1000x or 1,000,000x original scale), and we have all the hardware and software needs in place. We have disaster contingency plans, 24/7 support, five nines (99.999%) reliability, etc. Everything is automated and operating like a well-oiled machine. If our lead developer quits tomorrow, we won't miss a beat.

 

Some Sample Conversations

 

So, let's imagine how easy conversations can be between people who understand this scale compared to people who do not.

By analogy, let's assume we have two people talking about the weather. Here is the conversation:

"Wow, it is 34 degrees out!"
"I better get my coat and scarf!"
"Are you crazy, you'll need a bathing suit and sunglasses!"
"I thought you said it was 34 degrees!???"
"Centrigrade, dude."
"Oh, I thought you meant Fahrenheit."

How many conversations have you had that go like this:

Developer: "Okay, we're done with Appliances Unlimited's installation. I need a break."

Manager: "Great, we need to release the software to Mega Dept. Store on Monday."

Developer: "Whaaaat? We've only just released a prototype to Appliances Unlimited!"

Manager: "So, it's the same thing, right?"

Developer: "Well, no. We cut a lot of corners, have to do a lot of things by hand, and won't be ready to release it to another client for a month."

Manager: "But we've already been working on the software for six months. Why didn't you tell me this was an issue?"

Developer: "This is the first I've even heard about Mega Dept. Store. Why didn't you tell me we had sold another client the software? I didn't even know we gave them a demo."

Manager: "Why didn't you tell me that the software wasn't that flexible?"

(Curtain)

BADASS to the Rescue

 

Now, let's imagine what would happen if everyone had a common understanding of the BADASS scale.

Developer: (when the project starts) - "Wow, this is a 'minus two' if I ever saw one." (There could be substantial roadblocks, possible fatal ones. There are a lot of unknowns.)

Manager: "Do you think it is a 'minus three'?" (Thanks for letting me know it has a lot of risk. Are we screwed?)

Developer: "No, but I'll need to so some research." (I need more time to answer.)

Manager: "Okay, let me know if you think it is a 'minus one'." (Let me know it is achievable.)

(A week passes)

Developer: "Okay, good news, it is a 'minus one' or possibly a 'zero'. I think can get get it to a 'zero point five' in three weeks." (It has been proven, but we haven't done it yet.)

Manager: "Great, I'll start laying the groundwork for resources." (Good news, but I realize we still have a long way to go and haven't really written any software yet.)

(Three weeks pass, and there is a status meeting)

Developer: "Okay, this is a good solid 'zero point five.' What else is on the horizon, and when do we need to get it to a 'plus one'?" (I have a proof-of-concept, but it isn't ready for prime time, so don't promise too much to anyone yet.)

Manager: "We've promised the initial delivery to Appliances Unlimited in six weeks. We've communicated that this is still version 1 of a new product and won't have all the modules, right away. What is realistic to deliver in the first wave?" (I understand that version 1 always entails unknowns and risks, so what can we cut back on? I know Rome wasn't built in a day.)

Developer: "Let's deliver modules 1, 2, 3, 4, and 6. We'll leave module 5 for some future release." (Agreed, Rome wasn't built in a day, but as long as you understand where we stand, I'll do my best to help meet the business needs.)

Manager: "Okay, we need to be at 'plus one' by June 1st, so we can deliver it this quarter." (I'm getting pressure to deliver software that the customer will approve and pay for. We can't deliver a beta and expect to be paid for it.)

(Two months pass, during which software has been delivered)

Manager: "We're in talks with Mega Dept. Store, are we at 'plus two' yet?" (I realize I'm jumping the gun a bit here, but I wanted to give you a heads up. Are we at all close to having this project ready for a second customer?)

Developer: "Well, we're at about 'plus one-point-five' but I'm confident we can get to 'plus two' in short order." (Thanks for understanding that there is a lot to account for with each new customer, especially at this early stage. I'll do my best.)

Manager: "Okay, is three weeks realistic?" (We really will tank as a company if we don't get revenue soon. How hard can I push you?)

Developer: "Let's make it four weeks to give a little breathing room." (Pretty hard, but there is a lot of work to do.)

Manager: "Well, the pipeline looks good for Q3 and early Q4, we have to plan to be at a 'plus three' by November." (You need to be thinking about automation and scalability. If we can't scale, we fail.)

Developer: "I think we can be at a 'plus three' in late October, but automation will take at least until January, so let's target being at a 'plus four' by February." (I've been thinking about automation all along, but we're still putting in new features for each customer. We should be in the steady state soon as far as product development, but we need to work a lot on process, support, automation, and monitoring.)

Manager: "Okay, let's have a status check every two weeks to keep on track." (Yep, I appreciate that. Let's keep talking so we can make plans as to schedules, scope, resources, etc. I know that the software is "done" in some sense, but there is still a ton of work to do.)

(Curtain)

Conclusion

There is a tendency, when you are on the hook to do the work, to think that your manager is being unreasonable or unfair. More often than not, the manager simply doesn't understand the scope of the "plumbing" that goes into a software product.

Imagine someone is buying (or selling) a home.

Do they mention the excellent plumbing, electrical, and insulation?

No. If they can't see it, then they probably don't think about it very often.

What can your manager "see" about your software project? Probably almost nothing. Chances are, they have never even launched the software and clicked through the options. That is someone else's job. (Your manager is spending all her/his time worrying about sales and keeping the company solvent.)

How can you give your manager insight into the software development process?

The answer is "Understand that s/he doesn't care. You need to translate it into things they care about."

They generally care about schedules, expenses, resourcing, support, and deliverables.

So, until you have a common understanding about what is in a deliverable, and how different stages of software development have different needs and obligations, you won't be on the same page about the other things (expense, time, resources, etc.)

It is your job to teach your manager about the things in the BADASS scale above. If you haven't done that, then it is your responsibility to educate the manager and improve communication.

Be sure to share, link, comment, etc., and read more of the great posts on the right-hand side.

Happy coding!

The LeBron James of Programmers

How should Hyper Performers be Judged and Compensated? (How to Make the Case for a Raise)

I'm often asked questions about compensation by both employers and candidates, such as:

• What is a fair salary for this position?
• Why can't I find a higher salary?
• Why can't I find and attract top talent?
• What skills pay the most?
• How can I get a raise?

For many years, I have wondered why a great programmer (one who is 10x as productive as a poor programmer) doesn't make 10x the income.

There are a number of factors, as described in The Myth of the Bell Curve, but that only explains part of the discrepancy. Even if we agreed that a programmer is 3x as productive, are we willing to pay 3x more? Should we be willing to pay 5x more once you take into account the fixed overhead, such as health insurance, and indirect savings through making others more efficient?

I find that the missing piece is a shared understanding of how to measure the minimum skills required for the job. Because I think the question that dictates programmer salaries is, "Who is the least qualified programmer I can get to do the job?" In another post, I'll try to cover how low-rate programmers cost companies more, but the focus of this post is the hyper performer.

How Much is LeBron James worth as a Programmer?

The average NBA player's salary is about $5,000,000.

The lowest-paid NBA players, like poor Mario West, make about $25,000.

Kobe Bryant makes about $30,000,000 but his salary is an outlier; the top 10 players average about $20,000,000.

LeBron James, widely considered the best player in the world, makes a little less than $20,000,000. He could make more, but he agreed to a lower salary in order to keep the Miami Heat under the salary cap while attracting top teammates. Not to worry, his endorsements raise his total haul to around $60,000,000 per year.

I've been using all the zeroes in the preceding numbers, instead of abbreviations such as $25K or $20M, so you could appreciate the orders-of-magnitude difference in compensation.

Please note:

• The highest-paid players make about 1000x the salary of the lowest-paid players.

• The top 10 players (top 1.7% of 565 players) each make about 4x the average player and 800x the lowest-paid players.

• Even the lowest-paid players are all incredible athletes who have made the NBA. They are undoubtedly better than the vast majority of college and undrafted players who are not in the NBA, and perhaps better than players in other leagues throughout the world.

How much am I worth as a Basketball Player?

 

Instead of trying to evaluate my worth as a basketball player, in the aggregate sense, let's narrow it down to some specific metrics by which a basketball player can be evaluated, such as free-throw shooting.

How much am I worth as a Free-Throw Shooter?

 

Let's suppose that LeBron James and I are having a free-throw shooting contest (foul shots).

His career free-throw percentage is about 75%. Let's assume mine is about 25% (I can dream).

So, is LeBron worth only 3x me as a free-throw shooter? Perhaps.

Now, let's change it to a game situation, in which LeBron James earns 7.6 free throw attempts per game, because if they don't foul him, he is going to score anyway.

If I was in the NBA, and I played as many minutes and took as many shots as LeBron, I'd average zero free throw attempts per game, because no one would ever both fouling me ("He's open for a reason.") Let's be generous and assume I make 1 free-throw per game.

So, as a free-throw shooter, LeBron is worth at least 7.6x as me.

How much am I worth as a Three-Point Shooter or Slam Dunker?

 

Now let's imagine I have to make some three-point shots (about 23 feet away from the basket). With no defender, I might make 1 shot in 10 from the three-point line.  LeBron makes about 36.5% of his three-point attempts in a game situation, which is only 80th in the league!

Maybe I'm worth more than I thought.

Now, instead, let's imagine we are in a slam dunk contest. Granted, this isn't required in a game, but let's pretend it is a job requirement.

How many times, out of 100 attempts, will LeBron successfully slam dunk the basketball? I'd guess about 95% of the time, even when doing trick dunks, judging from this video.

I have never dunked a basketball on a 10-foot rim without using a trampoline. I will never be able to dunk a basketball, even if I get my knee repaired.

So, if dunking a basketball is part of the job requirement, LeBron James isn't just 100x or 1,000x more valuable. He is infinitely more valuable, because I simply can't do the job.

How Much is LeBron James worth as a Programmer?

Now, let's imagine we're in my house. LeBron won't stand a chance.

Can LeBron:

• Write a Jenkins script?
• Configure SVN and train the team on best practices?
• Create a re-usable component?

I'm sure he is a smart guy who can do many things, but he presumably less of a programmer than Michael Jordan was a baseball player. (MJ made about $5/hour as a baseball player.)

How Much is a Great Programmer Worth?

 

So what are the factors that typically determine the low and high end of a programmer's salary?

The following are examples of things that cause downward pressure in your value as a programmer:

• Low level of skill required (basic HTML, or template work)
• Lots of repeat work required but not highly original (i.e., programming banner ads)
• High number of qualified applicants relative to job openings
• Easily outsourced or off-shored to lower wage markets
• Low-paying industry, because people think it is glamorous (fashion, sports, etc.)
• Low-paying because industry is not profitable (non-profits, dying businesses)
• Low-paying due to lack of capital (start-ups, mom & pop shops)
• Low paying due to poor stock market, IPO, or VC interest
• Cyclical or boom-bust downturn (2000 Tech crash, 2008 Recession)
• Dying technology with glut of existing programmers competing for declining number of roles.
• The geographical market pays little (college towns, etc.) due to low cost of living, etc.

The following are examples of things that cause upward pressure in your value as a programmer:

• High level of specialized skill required (quant, enterprise architecture, big data)
• Highly original or creative work (award-winning advertising or game design)
• Low number of qualified applicants relative to job openings
• Harder to outsource or off-shore due to time constraints, security restrictions, or high degree of communication required
• Historically high-paying industry (finance, etc.)
• High-paying because industry is highly profitable (pharma, energy)
• High-paying due to stock options (Facebook, Google, etc.)
• New technology with shortage of existing programmers (iOS, Objective C, HTML5)
• Booming market due to IPO and VC interest
• The geographical market pays more (such as NYC) but business and living expenses tend to be much higher.

 

Are you Worth 10x Other Programmers?

The definition of "what you are worth" in a financial transaction is, "How much is a willing employer offering to pay you?"

You are highly unlikely to command 10x the salary of a "good enough" programmer, almost regardless of your skill.

Here are some things you can point out to your employer to help make your case that you are worth 2x or 3x what they are paying other programmers, but you'll be lucky to be paid 25% more.

If you are 10x as productive as other programmers, you'll probably be paid no more than 2x their salary.

Bruce's Law:

For each 100% improvement in productivity over other programmers, you are paid only 10% more in salary. LeBron James earns 4x the average NBA player's salary, and you are not LeBron James.


May these Odds be Ever in Your Favor:

• You can perform some critical programming in time for a deadline that others can't meet
• You have a unique skill that other programmers simply don't have
• You can fix and debug things 10x faster due to your superior architecture skills, reusable components, and debugging skills
• You raise the level of all the developers, and make the team more productive
• You shorten time to market
• You shorten the QA cycle and let them hire fewer QA staff
• You wear multiple hats, so they don't have to hire other programmers to do those roles

All of the above pale in comparison to the one reason that give you the most leverage:

• You have another job offer and are willing to walk away

Conclusion

There's an old saying, "You don't get what you're worth, you get what you negotiate." I'll cover some of the non-salary points for negotiation in another post.

When negotiating, remember:

• If job satisfaction is important to you, don't make it all about the money
• Software development is a team sport. LeBron James didn't win any championships by himself
• Work to improve yourself every day
• Make your teammates better
• Learn what your employer values

Best of luck in all your career pursuits.

Be sure to comment, like, share, or follow this blog, and check out the other posts on the right-hand side.

Debugging Dark Matters

Learning to Debug in Familiar Surroundings

Welcome to Computer Science 101.

Today, I'll be covering the principles of debugging. In later posts, I'll cover the theory and practice of using a single-step debugger in software development. But this post is about the mindset and techniques needed to debug any problem or situation.

Let's start with a simple but powerful definition.

To define "debugging" as "solving problems" is circular, at best. We need a definition that gives us a roadmap as to how to solve problems. Here's mine:

Debugging is the systematic challenging of one's assumptions.

Bam!

If you're not challenging assumptions systematically, then, IMHO, you are not debugging. You may be guessing, experimenting, attempting to intuit, or daydreaming, but you aren't debugging.

Let's begin our sordid tale with one simple piece of knowledge: 

• We've entered a room and it is dark.

That's likely a problem, and we need some light.

"But, soft! What light through yonder window breaks?"

Sorry, the quote from Shakespeare's Romeo and Juliet is not "Hark, what light..." And now you understand why we have to challenge our assumptions (in this case by googling for the exact quote).

Let's list some of our initial assumptions and then go about challenging them:

• There is a lamp in the room
• The lamp is broken
• This room needs a working lamp
• The light is supposed to illuminate the room "reasonably well"

Note that we cannot begin to debug a situation until we have defined both the problem and what constitutes success.

In this case, let's define the problem as, "The room is too dark for me to find my pack of cigarettes," and define the solution as, "Illuminate the room so that I can find my cigarettes."

Note that success should usually be defined as some productive outcome (I want my pack of cigarettes). Don't confuse the light in the room--a means to that end--with the goal itself.

So that leads to alternative approaches we might investigate:

• Can I find the cigarettes another way? (maybe a basset hound can sniff them out)
• Can I grope around in the dark and still find the cigarettes? (avoid the light issue altogether)
• Can I buy other cigarettes or do I need this pack? (find an alternative goal)
• Can I light the room with my lighter instead? (find an alternative solution)
• Can I light the needed area with a flashlight? (temporary solution)

First Do No Harm, Then Gather the Spec

I must investigate the alternatives, such as using a lighter.

What if there is a gas leak in the room? Will using a lighter cause an explosion?

What non-destructive tests can I do?

Let's assume that in this case, the homeowner (project manager) has said, "I know you want to find your cigarettes, but I really want a permanent light/lamp in this room. It used to work, but now it doesn't."

You've now gained three really important pieces of information: The homeowner:

• Doesn't care about your cigarettes
• Wants the room lit
• Claims the light "used to work"

You can take the homeowner at his/her word for the first two bullet points. Let's assume that you respect and agree their opinion about these two. So, at least you've defined the problem and an agreed on a metric for success.

The goal is to light the room, preferably with the existing (but broken) lamp. 

What about the claim that the light used to work?

If you haven't personally verified it, or have 100% confidence in the person who did verify it, then you are not systematically challenging your assumptions and not debugging effectively.

I'm not suggesting you challenge the person directly, but I have seen countless engineering projects delayed because someone assumed that the initial claim was true. Take any unverified data with a grain of salt, not as the gospel.

The two most important pieces of information to gather when debugging an existing system are:

• When was it last known to be working? 
• What changed before it broke?
  

Elements of the Light Bulb Circuit

Now is where your expertise comes in. You should have a mental model of how a light works, and all the components that go into a working light. 

In this case, we'll assume the following (but in real life, you would investigate to verify):

• There is a floor lamp in the room
• The lamp is plugged into an outlet
• The outlet is controlled by a wall switch
• There is an incandescent bulb in the lamp
• The person reporting the problem is not blind or deaf, nor delusional, nor a pathological liar (be wary of the last two). 

The next thing you need to do is replicate the problem.

Once you have replicated the problem, you have verified many of the earlier assumptions, and you will be able to tell when/if you've fixed it. So let's try to fix it.

There is nothing wrong with making an initial guess. It is probably a burnt out lightbulb, so you might as well try swapping in another one.

Right?

Wrong. See next section.

Try the Easiest Thing(s) First

In this case, the easiest approach is to try these three things:

1. Check that the lamp is plugged in
2. Flip the wall switch on
3. Test any switch on the lamp itself

Did you notice any hidden assumptions in the above list?

How do you know what position constitutes "on" for the wall switch? Is it a dimmer switch that needs to be pushed and/or turned? Is it a flip switch that is reversed (or connected to a secondary switch) so that you may have to push it down to turn it on?

You need not be 100% sure of any of these things, but at least achieve reasonable certainty, or make a note of any areas of uncertainty for future investigation.

The most important principle at this point is to change only a single component or element state at a time. Record the results and make sure they are reproducible.

Swap Out Broken Pieces For Known Working Components

So, your best guess is that the lamp, lamp switch, wall switch, and cord are not the obvious culprits.

Is it a system in which you can remove the broken bulb (like a string of Christmas lights) and test the remaining ones?

If not, you'll need a known working bulb to swap in.

How do you establish a known working bulb? Well, one good way is to take the bulb from another room where it is already lighting a similar lamp.

Your goal in this phase should be to isolate or eliminate potentially broken components.

If swapping the bulb doesn't work, then maybe something else is broken.

In that case, it is prudent to carry another lamp (or other electric device) into the room, plug it in, and make sure the wall switch and outlet are working. Thus, you can continue to narrow down the likely problem.

Obtain and Learn to Use Appropriate Debugging Tools

So, at this point, we've either narrowed down the problem to something in the room, or eliminated all of the items in the immediate room as the culprit.

Let's assume something in the room is broken, but we don't know if it is the wall switch, the lamp, the lamp switch, or the outlet.

What hidden assumptions have we made?

Have you considered these:

• Is the problem reproducible or intermittent?
• Is there potentially more than one source of the problem?

For this discussion, let's assume you've narrowed it down to the lamp being the problem.

Do you go back to the homeowner and ask if you can permanently move another lamp into the room, or do you need to fix this lamp?

Is there an alternative outlet in the room that you can use? (perhaps one without a wall switch)

What tools and techniques can you use to debug the light switch and outlet?

• Do you have a screwdriver to open the switch plate or outlet cover?
• Do you have an electrical meter with a good battery?
• Do you know how to use them without electrocuting yourself?

Expand Your Horizons to Consider the Entire System

Let's suppose that you've verified the operation of the in-room components (lamp, lightbulb, switch, etc.) but it still doesn't work.

What other assumptions have you made that are perhaps invalid and need to be explored further?

• Is the circuit breaker for the room tripped?
• Does the house have power from the main panel or a sub panel?
• Is power out in the entire neighborhood?
• Is power out for large areas?

Why does it matter if power is out for the entire neighborhood versus the entire state?

Two reasons:

• If the power is out for just your house or neighborhood, have you called the power company to notify them?
• If the power is out for a large area, how does it likely impact the schedule for restoring power? Have you made a back-up contingency for an extended outage, such as a generator? 

Keep working through the elements with the standard process described above. When in doubt, do some research or ask for some help. When stuck, get some food or sleep, or just time away from the problem to clear your head.

Let There Be Light

So what have we learned about debugging in today's blog post?

• Gather the requirements - identify both the problem and viable solutions
• Reproduce the problem
• Identify and challenge your assumptions
• Verify assumptions by testing
• Swap out components to narrow down the problem
• Use debugging tools to find more details about the problematic component
• Consider outside sources of error
• Make contingency plans

Conclusion

We've covered a lot of things that may seem obvious, silly, or superficial.

But, believe me, these are time-tested techniques that work every time to debug any situation.

When you are struggling with a problem, remind yourself of this mantra:

"Basic debugging techniques apply"

That is, you should fall back on these fundamental techniques when you are stuck on a problem.

If you follow this process religiously, you will see how well it works, and you will solve problems that have flummoxed you or co-workers in the past.

Happy debugging!

Be sure to comment, like, or share, and check out the other blog posts on the right-hand side.

Of Snowstorms and Software Development

Explaining Software Development in terms of Snow

This winter has been brutal in the US. Record snowfalls, the Polar Vortex, crazy ice storms. I love analogies, because I think they can help non-technical people understand technical concepts. So what can snowstorms teach us about software development? More importantly, how can we use these analogies to explain these issues to non-developers?

How To Shovel a Driveway

How many times has this happened in your software development career? You are given an incomplete specification, or no specification, and asked to just start programming something. Or, you are asked to start some inefficient process (say, deploying some software by hand) because it will be faster than doing it the "right" way. (I'll talk about "The Right Way" in a future blog post.)

Or you've been asked to work on a single feature for a single project, knowing that it is (or should be) identical to the same feature in another project. But the software teams are divided by project, not by feature. For example, in pharmaceutical software development, there is often a team dedicated to a particular (prescription!) drug, with redundant development being done across teams.

How can you explain to management what they need to know about software development, when they don't recognize the things you take for granted (code re-use, automation, etc.) as valid and relevant?

I like to use the snowy driveway analogy.

Suppose your manager says, "Please, shovel the driveway."

Here are the things you should ask in snow-terms (and business terms):

• Is it even snowing yet? (Is there anything to do yet?)
• Do I have a shovel? (Do I have the necessary tools?)
• When is the snow starting? (When does the first requirement come in?)
• How long will it be snowing? (How long will requirements continue to come in?)
• How much snow do we expect? (What is the scope?)
• What is the reliability of the weather report? (Do we have an accurate spec?)
• Do we have enough shovelers? (Who else do we need on the team?)
• Should we get a snowplow? (What equipment do we need to buy?)
• Should we hire a plowing company? (Should we hire a contractor or outsource it?)
• Am I physically capable of shoveling? (Do we have the talent and staff to do this?)

On it's face, this technique seems juvenile if not ludicrous. But stick with me.

You have to remember that salespeople, project managers, and non-technical managers don't speak geek. How can I be so sure? Because the only thing more ludicrous than my analogy is the requests you get as a software developer to "shovel the driveway" without knowing answers to any of the above questions. And you're being asked to do things that are counterproductive by people who don't understand how and why their requests are counterproductive.

And one of the major goals of this blog is to help get you outside of your geek braincase and help you understand how non-developers think and communicate. This is the key to your professional satisfaction, productivity, and career advancement.

How Not to Shovel a Driveway

Here are some typical requests, and how you might reply.

Manager: I know that everything isn't ready, but please start on the project with the information you have.

You: I can certainly start some basic prep work, but it probably won't save any time. It would be better for me to work on another project while we wait for the spec to be defined a bit further. I can work with the project manager on that.

Manager: We need to get started on this project so we don't fall behind, and because Mary (Mary is always evil) will have my head on a stick if we don't start on it this week.

You: Well, I'll do what I can to help move the project along, but I want you to understand that it won't save any time. It is as if you are asking me to start shoveling a driveway while it is still snowing. I can shovel the entire driveway, but since more snow is still falling, the driveway is still going to be covered again. I'll have put in work now, with very little to show for it. And, I'll still need to shovel the whole driveway again later.

Manager: That can't possibly be true. What is the easiest thing for you to implement in module XYZ?

You: Any design you reasonably come up with is going to take the same amount of time to implement. What takes extra time is if the design changes. The best thing for me to do is work with Mary to agree on the spec. There is no benefit to starting on something that is not defined and/or highly likely to change.

Manager: Mary is out this week, please just get started.

You: Okay, now that you understand the situation, I feel much better that we had this conversation and know that I'm on the task you want me to be on.

Free Advice: Don't remind your manager s/he is uninformed. S/he understood the decision is inefficient, at best, but doesn't want to admit it to you and has a different agenda. S/he will use the same analogy to Mary's face later, because you gave her/him a talking point that Mary can understand. Your career will advance much faster if you see yourself as the student when it comes to office politics, and not the teacher. If you don't take my free advice, take your manager's free advice. Programmers are used to highlighting the important points to each other, such as, "You need to use this compiler flag or it will fail." Non-developers just speak English and expect you to read between the lines, which you're probably not very good at.

Always, be sure to check yourself. Are you just being combative or lazy?

Is it true that your snowy driveway analogy holds?

If the snow is already deep, then maybe you could take a pass now and get ahead on some of the work. If you wait, maybe the snow would be so deep you have to shovel twice anyway. Or, you can take this time to do research, so you can ask intelligent questions later.

Don't take the snow analogy too far. You can affect the weather! Instead of complaining about the snow, work towards solutions. Don't use the analogies as an excuse to shut down conversation. Use them as a path towards a shared understanding.

The Nor'Easter

For those who don't know about Nor'Easters, they are swirling snowstorms shaped like the Milky Way.

The relevant characteristic of a Nor'Easter is that they contain heavy bands of intermittent snow, interspersed with lulls in which the storm appears to have passed.

Here is how to use this analogy in business:

Manager: Now that we are done with that major push, we have time to work on this huge backlog of work.

You: Sorry, but I think this project is like a Nor'Easter. I think we are in a temporary lull after a ferocious period, but the storm is still there, and we will be hit by periodic waves of snow every three weeks for the next quarter.

Of course, this analogy fails if the other person doesn't know how a Nor'Easter works, so you may need to explain, or use a different approach.

The sneaky part of the analogy is that you've subtly introduced the concept of a recurring storm, which your manager can understand without any knowledge of software development.

You've taken the focus off the geek-speak, and given them a mental image of something they can grasp onto.

How do you drive that home?

Consider naming each of your projects after some weather-related event, and add a photo (in this case of a Nor'Easter) to the project home page. Once your manager sees the photo, s/he'll understand intuitively.

Tech Debt

Tech Debt is one of the most important concepts in all of software development.

Here is how to explain it in terms of snow:

Tech debt is like when you don't shovel your driveway, but you drive the car over it. That snow seems to be "out of the way," and you don't need to deal with it any more, right?

Wrong! That snow will turn to ice, and someone will undoubtedly slip and fall on it. When/if you decide to deal with it, it is much harder to scrape off the ground because it has been compacted and re-frozen. It is 100X easier to deal with by shoveling before driving the car over the snow.

Now let me give you the software developer's definition of Tech Debt:

"If I don't refactor this module, then the code will be brittle, and we'll have to spend more time in QA, and the software won't be as robust or performant."

Which one do you think your manager is going to relate to?

So try this:

"I can take a shortcut today, but it is going to cost us dearly in the near future. Any perceived benefit is just an illusion. It is like driving over snow in your driveway instead of shoveling the snow first. The part you drive over is going to be hazardous and hard to deal with later. Please authorize me to head off this problem today, and it will pay itself back 10x within a week."

Forecasting and The Weather Report

How many times have you been asked to estimate a project without being given any details?

Manager: We need you to build an advertising site for this new cell phone our client is promoting.

You: Okay, do we have any details?

Manager: No, we just need to know how long it would take to do a micro-site.

You: Well, I can give you a better weather forecast if I know the city, the latitude/longitude, and the season. At this point, I don't even know the planet we're talking about.

Manager: Just assume it is like every other project we do.

You: Okay, I can give you the typical highs and lows. These sorts of projects usually take two weeks to spec and three weeks to develop. But, I don't know if there is going to be a freak snowstorm that dumps ice on the unsuspecting Southeast. When the storm hit Atlanta, a typical 45-minute drive took 7 hours.

Manager: You made your point, but I just want to know what is typical.

You: Okay, thanks. I just feel obligated to meet my promises and my deadlines. As long as you understand this is just a ballpark estimate that will need to be revisited when I have more specifics, I'm happy to do everything I can to help approximate the work. Is there someone I can work with to get more specifics?

Manager: Thanks, I'll let you know.

Conclusion

We've covered a lot of territory here.

Some take-aways

• Look for creative non-technical ways to relate technical concepts.

• Use visual images to relate concepts. Most people think visually.

• You've made your point, now keep your mouth shut. Non-programmers can only keep from strangling each other because their communication is built on a foundation of ambiguity that allows them to constantly save face or leave room for interpretation.

• People in glass igloos shouldn't throw snowballs. Recognize that communication is a two-way street. Stop chalking it up to your manager's failure to understand your brilliance and expertise.

• Make a snowman in the shape of your manager and watch him/her melt . Do not run it over with your car. It will only be harder to clean up later.

Happy Coding! Be sure to check out the other posts on the right-hand side. And like/share this article if you found it useful.

Top Ten Non-Technical Skills Software Developers Need

Why aren't I Rich Yet? (Part 1 of N)

 

Developers are often really good at logic, structures, software development, etc., and often not as good at other skills that are widely praised and highly valued by non-programmers.

This is the first of several posts on this topic in which I'll try to help programmers understand why their careers and compensation might not be advancing as fast as those of co-workers they consider not as smart, indispensable, or productive as they perceive themselves to be.

1. Reliability/Punctuality

Whoever said "90% of life is just showing up" perhaps underestimated. Programmers need to understand that they get more credit for showing up early than for staying late. If your business opens at 9:00 am, show up at 8:55. Don't stroll in at 9:45 just because the first meeting isn't until 10 am.

Programmers tend to be the last to arrive and the last to leave, and often work many hours at home, at night, and on weekends. Sorry, but you get almost no credit for those things in your boss's mind. To the contrary, they interpret it as you being lazy, undisciplined, and inefficient in the use of your time.

I'm not saying those things are true, but you have to recognize that as the perception.

Programmers are often seen as flaky if they are hot and cold. One week, they may kick ass, and then next week they may be largely AWOL or burnt out. This happens especially with contractors who have to juggle multiple clients. I'll leave an in-depth discussion of this issue for a future post. Suffice to say, employers don't care what else you have going on. They want you 100% available for their task. Within an organization, you'll see the same phenomenon. If two project managers want you working on their project, they tend to underestimate the time you have to spend on another project.

2. Written and Verbal Communication

Learn to speak at a level non-technical people can understand. Hint: Ask questions, and say things at a much less technical and detailed level than you'd like (that will be the subject of a future post).

You need to be able to tone down the geek-speak in order to communicate with others along their wavelength, emphasizing a) what they can understand; and b) what matters to them.

For example, saying “We need a RAID array” is not helpful. You need to say, “If we don't invest in a more reliable disk, our business will be adversely affected when it crashes.” Better yet, add, "Here are three quotes from reputable vendors for the hardware we need. I think we should go with Vendor A for $2,500 when we have the budget for it. I think this will be critical by May, so I'll remind you in April. If we don't deal with it by June, it will likely cost us $50K in lost productivity and downtime, so it is wise to invest in it now."

Learn to write intelligibly. I've worked with many programmers who can't spell, even when English is their first language. It is simply not acceptable to mix up “too” and “two,” especially when your email will be read by non-native speakers who don't understand English homophones and are easily thrown off track by typos.

For example, suppose I wrote, "Test the Reporting module too," but meant for the person to test the second Reporting module ("module two") thoroughly. It might lead the tester to test the Reporting module "too" (i.e.,  superficially, in addition to the other modules).

Or imagine that I am working with a tester on Module A and Module B, but I confuse them in an email. A native speaker will usually detect the error from context and request clarification. For several reasons, a non-native speaker will tend to just take the instructions at face value, and end up testing the wrong module.

There is also a huge need to learn to make a competent PowerPoint, which requires both verbal and sometimes graphic communication.

3. Understand Schedules and Time Estimates

Your job as a developer is not to program software. Your job is to help the business make a profit by publishing software in a timely manner. 'Tis better to deliver adequate software on time than to blow through deadlines like a case of Red Bull.

You are expected, as a programmer, to be able to estimate accurately how long something will take. Learning this skill is a long and sordid tale, which I'll take up in future blog posts. The first step is to admit you have a problem. If the software is late, stop looking around for others to blame, and realize you have the power to improve the time estimates and affect the schedule moving forward.

4. Understand Budgets and Cost Tradeoffs 

Understand bang-for-the-buck calculations and understand the business value attributable to any software decision you undertake. What is the cost of extra QA, of being late to market, of hiring the wrong developer for the wrong role?

Don't spend time writing something by hand that can be better obtained off the shelf for less (and faster). Don't be afraid to hire an expert in the short-term that will get the product to market faster and make the company money in the longer term.

And when architecting a solution, don't neglect the ongoing cost of supporting that product. For example, if you are generating huge amounts of video traffic that is costing the company $100K/month to serve, you may need to revisit your bandwidth calculations. Can you get by with lower-bandwidth video that will cost the company much less each month? If you don't understand your bandwidth, server, hosting, and hardware costs, then you should ask someone in the company who does.

5. Patience

Developers tend to be smart and impatient. Businesses tend to make decisions over months and years. Developers tend to want it done today. Are you working in a start-up or a large conglomerate? Is there a big IT dept and a formal process for server deployments? Align your expectations with the reality of the business.

6. Managing Stress, Sleep, and Tempers

It is not acceptable to be snippy with co-workers because you pulled an all-nighter. You are expected to manage your behavior even when you are sick and tired, and even if you are overdue for a smoke break. If you can't behave, then send a polite email calling in sick. If you can't manage the stress of the industry you are in--advertising has notoriously high stress and tight deadlines--then try a different industry.

Take care of yourself physically. You need to get adequate sleep, food, exercise, etc. You need to shower, shave, and dress appropriately. Showing up unshaven in T-shirts and torn jeans just doesn't cut it. Grow up. Get some sun. Wear a decent pair of slacks.

7. Talk to people Outside your Dept

Be sure to talk to people in customer support, marketing, sales, and business development. Understand their needs and frustrations. Establish a relationship so that everything isn't adversarial.

Reach out to other departments to find out how you can help advance the business's interests. Here is an easy line to use as your fallback: "What is the most important thing I can do as the developer to help you in meeting the company's goals?"

The answer will often be that they need demos, sales sheets, predictable schedules, etc.

It is your responsibility as a developer to help the business, not just program software. You can't do that if you don't understand the business. Ask to go to a trade show, sales call, sales meeting, etc. You'll learn a huge amount.

Bonus: It feels great to see people actually using and benefitting from your software.

8. Handle Feedback and Criticism

Be open to feedback, and don't take criticism personally. We all make mistakes. Own up to yours, and work to fix the issue.

The major challenge is when someone criticizes you for something that you think is unimportant or not your fault. For example, if someone says, "Your code has a bug," you'll probably agree and fix it happily. But if someone says, "We need you to spend more time with the product manager and then write the spec," your initial reaction is probably going to be, "That's his job, not mine, so screw that."

Try to hear it in a different way. Maybe your boss is really saying, "You have expertise that no one else has, and the project manager really isn't capable of writing specs without you." It is high praise that appears to be negative feedback or criticism that you didn't do the task earlier. If you treat it as punishment, it is a missed opportunity. If you are doing the other things on this list, it will help your boss see you as someone who can willingly handle new tasks and responsibilities. That's how you get a bigger raise.

When in doubt, treat it like you are a baseball pitcher. The umpire will call some balls and some strikes. You'll give up some hits and make some strikeouts. There will be some fielding errors by your teammates. No one else expects perfection of you. They do expect you to take feedback professionally and adjust accordingly.

9. Take Ownership without being Territorial

Don't wait for someone else to move the project along. You weren't hired to be a cog in a wheel. If you see something that needs attention, bring the necessary attention to it. For example, if you are supposed to fix one dialog box, and you notice all the dialog boxes have the same problem, consider fixing them all (or at least raise the issue at the next meeting).

And don't be territorial - nothing is so tiresome as a defensive and territorial programmer.

10. Think Beyond your Current Assignment or Own Project

Suppose you are being asked to optimize a software product, and you realize that another software product (outside your assignment) has the same issue. Bring it to someone's attention. Example, when using Product A, customers have complained that the popup blocker prevents the “Save File” dialog box from appearing. Chances are, the same thing occurs in Product B. In an ideal world, the code would be centralized and could be fixed for both products at once, but if not, bring it to the attention of the Product B team. Maybe they already fixed it, or maybe they can implement your fix in their product.

Conversely, when someone from an outside team brings something to your attention that might affect your project, be open to it. See items 8 and 9.

Conclusion

 

You are a smart person and a great programmer. If you are not getting ahead in your career, it is because you are being measured against other metrics where you are weaker.

These tend to be the softer, emotional-intelligence skills, such as collaboration, consensus building, active listening, etc.

It took you many years to master programming.

The sooner you start working on these other skills, the sooner you'll see the beneficial impact on your career path.

Good luck!

Be sure to like, share, comment, follow, etc. And check out the other fine blog posts on the right-hand-side of this page, such as: Top Ten Things you Should Learn from Your Job Search and  Twenty-three Evergreen Developer Skills that will Keep you Employed Forever...

Twenty-three Evergreen Developer Skills that will Keep you Employed Forever...

...and Make You More Valuable and Productive to Potential Employers

Imagine you are either searching for a job or looking for a career change.

Think about the company you'd like to work for - whether it be a start-up, a midsize company, a multi-national, etc.

Now stop; you're going about your job search all wrong.

Instead, put yourself in the position of the hiring manager who is reviewing a stack of resumes. S/he doesn't know you or care about you (yet). S/he cares about the needs of the company. The only interest s/he has in you is whether you are the right person to fill that position, which means that, by definition, you need to be the candidate that will address the company's needs.

Technologies change, so no one programming language will keep you employed indefinitely, but many skills are evergreen. Highlighting these skills, in addition to having the core technical competency, such as Java, SQL, or HTML5, will greatly increase your success rate by differentiating you from other candidates.

Review the following list, assess your level of expertise, and think about how to introduce them in a natural way to your business communication. Be sure to touch on the relevant ones on your resume and your cover letter, and bring them up in the interview. If you don't have any of these skills, obtain them. Note: I am not advising you to say, "I use abstraction, so please hire me." Instead, you should address the business strength built atop the technical skill. More about this in the conclusion to this blog post.

1. Understand the relationship between the software development cycle and the company's business

Understanding the software development life cycle's (SDLC) relationship to the employer's sales cycle and business model is critical. If you understand the entire SDLC and the company's sales cycle and business model, you can make much more intelligent choices about how to allocate your time and attention. Without that information, you are likely to risk missing important deadlines, not understand how/when to prioritize features, and waste dev cycles.

For example, if the company sells to the educational market, perhaps any software demos that aren't completed by May will have to be delayed until September when school is back in session. Every business is going to have seasonal tradeshows that are key to sales.

You also need to consider how your employer gets paid by its customers. For example, if you are in the online advertising business, the primary client deliverable is a report showing how many ads were served and to whom. If you can't report ad views accurately, then the company won't get paid and repeat business will dry up.

So you need to learn to prioritize features that are important to the company's business. The easiest way to do this is to ask your boss and people in sales/marketing, “What is the most important thing I can do from a software standpoint to affect the business's bottom line?''

2. Version Control

If I could ask a software developer candidate only one question, it would be "Tell me about your favorite version control system and why you prefer it over other options." If they don't have an answer, I would consider it disqualifying.

If you are not using subversion (svn), git, or a similar source control (version control) system, you are not a competent developer, and need to learn how to use one immediately. Period. Without version control, you have no way to collaborate, track history, revert to prior versions, manage multiple versions, refactor with confidence, or fix bugs with confidence. I'll cover more details in a future post.

3.  Unit Testing

Unit testing is a long and detailed topic, which I can only touch on here. Unit testing and test-driven development (TDD) are an important way to define what software is supposed to do. In TDD, software is ready to be released, by definition, when the software passes all tests. Using unit tests allows you to make changes to complex systems while reliably knowing whether you've added the new feature successfully or accidentally broke something. Again, I'll cover unit testing and TDD in a future post in more detail.

4. Automation with Jenkins, Maven, and/or Ant or similar and Continuous Integration system

If you are manually building and deploying your software, you are likely making many errors, or wasting time, or not scaling your team. As a best practice, you should have a server running, say, Jenkins, that rebuilds the software after any changes. This can/should be integrated with version control and unit tests.

5. Understanding Software Architecture and Design Patterns

The ability to architect a project is critical to its successful completion. You wouldn't think of building a house without blue-prints, and yet people undertake complex software without any plan. You should understand how the different modules relate, where code can be reused, what components are common. And, of course, be familiar with common Design Patterns. Much more to come on this and code re-use in future blog posts.

6. Reading and Writing Documentation (Wiki, etc.)

If you can't read documentation, I don't want you on my development team. Learn how to google and read both official documentation and unofficial blogs/comments. If you can write documentation, you are infinitely more valuable. If your project isn't using a wiki, set one up. All the things you struggle with during the first week should be written down. This may include where important systems are (network drives, svn repositories, databases, utilities, installers), team contact information, or the best place to get take-out.

The arguments for/against documentation are long and sordid. I'll cover those in another blog post.

7. Understand Scalability and Repeatability

Know that every meaningful thing you do will have to be repeated in the future (See "Automation...and Continuous Integration" above).

Any meaningful piece of software will have multiple users or customers. So if a process can't be scaled or repeated, then you are probably doing something wrong. For example, if your web site fails with more than 100 concurrent users, you obviously haven't architected it properly.

Similarly, if you set up your Dev server, chances are you'll need to replicate the environment immediately for the QA server, Staging server, Production server, etc.

The same principle applies to developer set-up, customer support, etc., so consider how best to address these issues (documentation, training, scripts, etc.)

8. Estimation (time and money) and Scheduling 

Know how to build lead time into the software development cycle. I have never worked at a company where deadlines weren't important, and I've never worked at a company where people were good at estimation and scheduling.

This is a long discussion summarized by “Whatever your time estimate, multiply it by 5, even after taking this rule into account.” 

The truth is that most meaningful software is complex and largely unknown to the stakeholders when making estimates. Things regularly take five (5) times longer than anticipated because no on thought ahead as to the many cases that needed to be handled. This unanticipated issue could be something as simple as, “What should the software do when the user runs out of disk space?” to, “How should the software behave if the internet connection is dropped while performing a critical operation?”

This is another huge topic, which I'll cover in more depth in the future.

9. Know when (not) to Optimize

Your software shouldn't suck. It shouldn't suck CPU or other system resources, and it shouldn't suck up the user's time. That said, not everything needs to be optimized. For example, if you are streaming a 15 GB video, optimizing 3K worth of text downloading isn't going to meaningfully impact the user experience. Some people over-optimize too early. I've seen start-ups optimize for billions of transactions per day only to find they can't garner any customers or traffic.  I've seen other products “perfected” before ever getting to market. (See "Shipping is a Feature,")

10. Agile Development 

Agile development is a long topic that I'll cover in a future post.

Suffice to say that everything you've been doing your whole life is wrong, including how you've probably been doing agile development. In a properly functioning agile environment, there is a noticeable presence of unit tests, communication between dev/QA/biz people, user stories (aka appropriate level of specification), transparency, developer cross-training, and a shipping piece of software that functions well.

In a dysfunctional environment, there are blown schedules, unclear product direction, disjointed feature sets, buggy software, and various developers mumbling to themselves in the corner.

11. Refactoring

Refactoring is the ability to rewrite the internal functions of a module without affecting the external behavior. For example, if you refactor an “export” feature, it might have the same inputs and outputs, but operate 10x faster. The first rule of refactoring is something you would find in the Hippocratic Oath: “First, do no harm.” (Primum non nocere).

You should also understand how to, say, refactor a function to accept additional optional arguments without having to change (and without adversely affecting) any existing code that used the function prior to refactoring. This is another huge topic to be discussed in future blog posts. (See also "Unit Testing," "Using Abstraction," and "Know how to define an API...")

12. Migration

You must understand both the concepts and execution of migration.

For example, how are you going to migrate customers from version 1 to version 2? How are you going to migrate changes from the Dev environment to the QA environment? How are you going to migrate a code base from one technology to another?

This topic deserves at least one blog post of its own, which it shall receive in the future.

13. Know how to define an API and know how to use other APIs

You should to be able to separate your work from other people's (i.e. decoupling). Or, perhaps, you  need to create a toolkit for other developers (either internal or external) Often, the best way to do that is to create an API.

For example, if I was creating a video player, it should expose “hooks” for the common operations, such as loading, playing, and pausing the video. A good developer should know when and how to create and expose a public API.

Conversely, a good developer should be comfortable/fluent in reading the documentation of someone else's API and using it to achieve a goal.

See also "Architecture" and "Refactoring" above, and see "Abstraction" below.

14. Programming Reusable code (usually Object-Oriented)

If you have fifty popup dialog boxes in your product, how many different components should you write to implement them?

The answer is probably one or two, max. Yet, I have walked into countless software projects where the developers did not create and reuse components. A software project should have less code if done right, and it should be more maintainable.

Here is a good litmus test...If I asked you to change the style and width of every button in the application, how long would it take? 1 minute? An hour? A week? A month? A year?

15. Have a tech network on which you can rely

Your value increases exponentially if you can find answers quickly by relying on colleagues and/or bring them into your current place of business. Be part of other developers' network, and make them part of yours.

16. Ticketing or Workflow system, such as Jira

You must be fluent in at least one ticketing or bug-tracking piece of software, such as Jira. There are many such systems. Understand how to benefit from one and use one daily. Learn how to be an administrator, and configure dashboards, reports, etc., to maximize its utility.

Litmus test - Excel or a shared Google Doc is not a bug-tracking system.

17. Know “enough” about hardware

If you are a software expert, you need not be a hardware expert and vice-versa, but don't be an ignorant jerk. You should know when something can/should be solved by additional hardware (i.e., adding memory, a RAID backup, a faster network connection) and when it should be solved by some software solution, such as caching.

18. Know “enough” about other people's software tools  and technology

To someone with a hammer, everything looks like a nail. For example, if you know Flash/ActionScript, you may think that it is always superior to HTML/Javascript (or vice-versa). Neither is universally true (as always, the answer is “it depends on the situation”). So either make other developer tools your friend or at least “know thine enemy.” People say really stupid stuff all the time for lack of knowing a little bit about other development tools.

19. Know “enough” about the full-stack

A good developer will understand everything (at least superficially) from the front-end to the middle tier to the back-end. For example, if the user has to enter an email address, what sort of validation should be performed by the UI, what should be handled by the middle tier, and what should be handled by the back-end?

You need not be an expert in all aspects, but you need to understand enough to know when to say “No”. For example, if you are a front-end developer, and they ask you to store the user's password in plain text on the front-end, you should say, “no,” and know why you are saying no.

How do you gain such knowledge? By working with other qualified developers, asking questions, reading, listening, attending user group meetings, etc.

20. Know that Shipping is a Feature

Nothing is more frustrating to developers than being “piled on,” and then being blamed for the software delivery being late (i.e. feature creep, endless revisions to UI).

Nothing is more frustrating to everyone else than having to hound the developer to ask when the software will be ready.

Here are the magic words to solve this problem....Whenever anyone gives you a new requirement as a developer, state this loudly and clearly:

“This is a new, unanticipated feature that will adversely impact the original schedule. We need to adjust the delivery schedule, allocate more resources to the project, or remove some existing features and deprioritize them until the next version. Which of these three approaches do you prefer?”

If you say nothing, the person giving you the new requirement will assume the schedule will be on track even after adding the new feature and will blame you when that is not true.

Blanket statements such as “Any new feature raised will inevitably cause the schedule to slip or features to be dropped” are useless at best.

You must re-iterate the earlier statement every time that a new feature is requested. (Better yet, use Agile development). Another generic approach is to say, “That is a great request for version n,” where version n is at least +1 greater than the current version. You can cite a +3 higher version number in a matter-of-fact way, such as “That is a great request for version 4, but, for now, I'm focused on shipping version 1.”

21. Using Abstraction

"Abstraction" is the ability to create a “layer” of code that insulates the user from some underlying particulars. (Here, I am not discussing the formal concept of an abstract class in OOP).

Abstraction enables development of multiple modules to be decoupled.

For example, suppose I have implemented all my UI code to interact with an Oracle database. And then one day, I find out that the back-end developer has switched to a Microsoft DB. If I can't handle that change rapidly and easily, then I am a douche-bag unworthy of calling myself as developer.

In a good design, I shouldn't have programmed anything that is Oracle-specific, except for a small abstraction layer. And I should be able to easily swap it out for a Microsoft-specific abstraction layer, and everything should “just work.” The same principle applies to the theoretical video-player API discussed above. This is another huge topic that I'll address in a future post.

22. Clean up compiler warning and error messages

If I had five minutes to examine someone's code and wanted to judge how well it was written, I would use one single metric...and that is the number of compilation warnings/errors. A well-written project should have zero compilation warnings and zero compilation errors.

23. Know when (not) to Roll Your Own

The most frustrating developers are often senior coders who insist on re-inventing the wheel and writing everything from scratch (see defining/using an API). If you are not using other libraries and APIs, you are wasting your time and your employer's money. For example, there is a Java library that will export to Excel. If you are writing your own Excel export, you are a probably a douche-bag with an oversized ego or an undersized ability to google.

That said, don't be a foolish slave to what others have done in the past, and don't think you are a skilled programmer because you know how to cut-n-paste from a google search. Sometimes you do need to roll your own. Often the best compromise is an open source library that you can use as the base but then patch/extend as needed for your particular situation.

Conclusion

Well, we've covered a lot of technical topics in this discussion.

The key question is how you can relate this to a non-technical interviewer.

The answer is really simple...just translate it into something they care about such as money, time, flexibility, etc.

Here is a sample conversation:

Interviewer: "Please tell me how you think your current experience is relevant to this position"

You: "Well, can you tell me what you feel is the biggest gap in the current team or problem you are looking to solve?"

Interviewer: "Well, our biggest problem has been scalability."

You: <Insert your ingenious answer here, touching on the relevant technical topics above, such as...> "I find that the biggest obstacle to scalability is an over-reliance on the middle tier and front-end to do processing that could best be handled by a high-speed database or caching mechanism on the back end. Although my specialty is front-end architecture, I have extensive experience working with developers across the full-stack. I'm sure that if I spoke with them about the bottlenecks you're experiencing, we could come up with a solution that took best advantage of each tier's strengths."

Interviewer: "That's way too technical for me. I'd like you to come back for a second interview with the back-end and middle-tier teams"

You: "Sure thing.  I just meant to say that there are a lot of factors that impact scalability. I understand how all the system components can be optimized to get you the biggest bang for the buck. That is, my goal is not just to make a scalable application. My goal is to understand the both the business needs and technical problems, assess the time requirements and benefits of each approach, and work with the other engineers to design and implement a solution that will give us the biggest benefit in the shortest time while keeping the schedule on track."

Interviewer: "Sounds great. And I understood it too!"

You: "Are there any other major areas I can speak to before I leave?"

Interviewer: "Our other major problem is managing multiple versions of the software for multiple customers. It is a huge headache."

You: "I find in most organizations, that version management problems stem from several factors. Let me ask you, do you use a version control system, and have you put in place a migration procedure?"

Interviewer: "Maybe I should consider you for the technical lead. I need people who can think and not just program."

You: "I'm happy to discuss whatever role you feel can best leverage my skills to fill the company's most urgent needs."

(Curtain)

Please check out the ever-growing library of other blog posts on the right-hand side. Oh so fulfilling but with zero calories!