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...