20+ Software Developer Tips and Skills

Software Developer Tips and Skills

Best Software Developer Tips and Skills

When a new Software Developer makes the first product he makes a lot of mistakes. In this blog, we explain 20+ best Software Developer Tips and Skills to create the best product. 


Software Developer Tip: 1

Engage Users

The software development process doesn’t end with throwing a product over a wall; it never ends, in fact. People use your product and you need to react to them, improving it over time. If you don’t learn how to master this feedback loop your creation will die.



They write software for themselves, are pleased with the end result, and then declare victory.

Unfortunately, that’s not how the real world works. “Good software” is an overly narrow definition of success. If you’re trying to pay the bills (or simply boost your résumé) you also need a lot of other people to use your software and be happy with it.


We’ll examine three general phases of user engagement in this blog. First, you need to get users to notice your work—are they even aware that it exists? How do they perceive it before they walk in the door? Then you’ll need to think about what people experience when they start using it.


Does it meet their expectations? Is it usable? Does it empower them to do great things? Finally, we’ll look at how to interact productively with them once they’re firmly engaged with your creation. All of these interactions are part of the cyclical nature of product development.


The bottom line is this: collaboration isn’t just about working with your team; to make great things, you need to actively collaborate with your users too. If you’re not on top of these things, all you’ll have is a piece of shiny software with no users. If that’s the case, maybe it’s time to question your career choice!


Software Developer Tip: 2

Managing Public Perception

When you hear the term marketing, what’s the first thing that comes to mind?


If you’re like most folks, the word probably conjures up the image of a dis-honest salesperson, all fake smile and greased-back hair: somebody who’s all about building an image for a client or product. If your product is the raw “meat” to be sold, the marketing person’s job is to add the magic “sizzle” to the steak so that more people flock to it.


Why does this idea bug us so much? Why do we shudder at the thought of the marketing person?


Because, as programmers, the marketer represents the antithesis of engineering culture. We’re obsessed with truth. Either the code compiles or it doesn’t; the software has a feature or it doesn’t; it solves a problem or it doesn’t.


We don’t “spin” our descriptions of the world; we state the facts and then work to change them. We look at the marketing guy and all we see are lies, and we don’t like being lied to. We want order, predictability, and accurate statements when it comes to making decisions.


Because we perceive marketing as something that distorts the truth, it violates the maker’s instinctive desire for meritocracy. We believe the best product should always win. And by “best” we mean the product that objectively is of the highest quality and most effective, not the one with the slickest TV advertisements.


Over and over we’re disappointed when we see superior technologies lose out: many believe that Betamax was superior to VHS, that Laserdisc was better than DVD, or that Lisp is still the best programming language. Even in the world of version control tools, Subversion has taken over the corporate world despite the technical superiority of newer systems like Git.


What’s worse is we perceive marketing folks as overpromising to customers, which in turn makes engineers look like they’re always underdelivering. It makes steam pour from our ears.


We’re here to give you both bad news and good news.

The bad news is that no, you cannot ignore marketing. It actually matters and you have to deal with it. The good news is that it’s possible to actively cooperate with marketing. It doesn’t need to be a sleazy affair when you do it right. In fact, it can be an incredibly powerful tool for success!


Programmers tend to have an overdeveloped sense of logic, but most humans are driven equally by logic and emotion. The marketing folks are masters of emotional manipulation, and that’s why they’re so effective: they mix the facts with feelings to get attention.


If you want to get new people to use your software, you have to care about their emotional perception of your software. You can not change the way people make decisions.


Apple Inc. is the undisputed master of making technology appeal to the emotions of nontechnical people. Firmly dating ourselves in the year 2015, we ask: is an iPhone objectively superior to an Android phone?


Featurewise they’re almost identical. But if a nontechnical user believes an iPhone is magical, it really is magical, at least to that user. Perception is a reality. Or as we’ve said earlier, “Perception is nine-tenths of the law.”


It’s tempting to think that the only way to win is not to play, but this is a game you’re not allowed to ignore. You need at least a minimal marketing strategy to even get your software in the ring, and if you’re smart about it then you’ll discover that marketing can be a serious force multiplier for great engineering. Here are some basic things you can do to take control, and they’re all based on HRT.


Software Developer Tip: 3


Don’t underestimate the emotional impact of a well-designed first experience with your product—if you’ve ever unboxed an iPad or a Nest thermostat, you know exactly what we mean here.


What is your product like to a newbie? Is it welcoming and does it encourage exploration? Conversely, for an expert who sits down to an initial session with your software, does it appear familiar and sensible? At first, glance, does your app scream instant productivity, or steep learning curve and countless tears?


More specifically, what does a user experience in the first 30 seconds after launching your software? Don’t just give an intellectual answer (“she sees a menu of choices, with a login box”) but give an emotional answer too. How does a new user feel after a minute? Empowered or just confused?


What can you do to improve that feeling? Step back a level and look at your product’s website. Does it seem professional and inviting, like a good storefront? You need to take these things seriously for your software to be taken seriously.


Software Developer Tip: 4


Don’t let your marketing people preempt you here. If users ask about upcoming features or release timelines, take the opportunity to give overly conservative estimates. If you let marketers spread rumors, you’ll end up with a Duke Nukem Forever situation—software that’s teased for shipping 15 years late.


But if your own (more accurate) message gets out first, your users will always be thrilled. Google is great at this; it has a deliberate policy of not preannouncing features for any product.


When new features roll out they’re often a delightful surprise. It also prevents internal death marches to meet unrealistic advertised launch dates. The software is released when it’s actually ready and usable.


Software Developer Tip: 5


A lot of programmers hate the media industry—it’s just marketing in another guise. When a trade magazine or research firm comes knocking on the door, a lot of companies will drop everything and kowtow to their requests.


They realize that a good (or bad) review can make or break a product’s perception. Engineers tend to resent this sort of power and deference, though.


For example, there was a time when members of the Apache Software Foundation (ASF) had problems interacting with analysts. An analyst would ask the ASF for industry-standard white papers describing their Apache HTTPD server, and the typical snarky response might be, “Go read the documentation on the website, like everyone else.”


While this satisfied the open source developers’ deep commitment to meritocracy, overall it was counterproductive to public perception—, particularly among corporate users.


Eventually, the ASF “PR person” worked to re-educate a number of community members about this attitude and deal more productively with analysts. Passive-aggressively fighting the system— no matter how irritating it is—just doesn’t make sense. It’s no different from telling the restaurant reviewer to get back at the end of the line.


Should the reviewer get preferential treatment? Probably not. But is it worth sticking it to him as a matter of principle? Definitely not. You’re only hurting yourself in the process. Choose your battles carefully.


Software Developer Tip: 6

How Usable Is Your Software?

Here’s a hard truth: unless you’re developing software tools, engineers are not the audience of your software. The corollary is that you, as an engineer, are a terrible evaluator of your software’s usability. An interface that seems totally reasonable to you may very likely make your nontechie neighbor pull out her hair in frustration.


If we assume that “successful software” means “lots of people use and love your software,” you need to pay deep attention to your users. Google has a famous motto:


Software Developer Tip: 7

Focus on the user, and all else will follow.

It sounds fairly campy, but over our careers, we’ve watched this maxim play out over and over across multiple projects. We’ve witnessed projects succeed and fail based on this truth.


One of Google’s big breakthroughs was to begin measuring the effectiveness of search ads. If users click on a particular ad, it must be useful to them; if it never gets clicks, it must be annoying or useless. Bad ads get removed from the system and feedback is given to the advertiser to improve its ads.


At first, this seems counterproductive for the short term: Google is actively rejecting revenue sources. But by making the searcher (rather than the advertiser) the focus of attention, it dramatically increases the usefulness (and usage) of Google’s search advertising system over the long term.


Software Developer Tip: 8


First things first: imagine your users fall across a spectrum of technical competence. If you were to draw a vertical line showing which set of users is best suited to your product, where would you put it?


A vertical line through the center of the bell curve means that about half of all computer users would be happy using your product (i.e., those to the right of the line).


As an example, let’s take the problem of wanting to display Internet content on your large TV screen. How has the “usability” of competing solutions widened potential audiences?


 Initially, people had to plug their laptop computers directly into their televisions. This involved understanding analog versus digital inputs and having the right sort of audio and video cables.


Apple then came out with an Apple TV product—a small computer-like appliance that you left permanently plugged into your TV.


It could be controlled from a computer or smartphone, and you could stream either your private media or live Internet content. This solved the problem for a much larger (and less technical) audience: it came with the proper cables, and you plugged it in once and left it there.


Google then one-upped things by coming out with the Chromecast, a small stick that plugs directly into a TV’s HDMI port. It was even easier to install and allowed people to “cast” their screen from a wider array of both Apple and non-Apple devices.


At the time of writing, we’re now seeing new TVs being shipped with built-in WiFi and Internet streaming. It’s likely that Ben’s kids will never remember a time when TVs didn’t have Netflix built in!


The point here is that good product development aims to move the vertical line to the left as much as possible. In general, the more users you have, the more successful you are (and the more money your company makes!).


The moral here is that when you’re considering your users, think hard about who your audience is. Is your work usable by the biggest group possible? This is why simple and thoughtful user interfaces matter so much—as well as things like polished documentation and accessible tutorials.


Software Developer Tip: 9


Now think about the first-time users of your software. How hard is it to get going for the first time? If your users can’t easily try it out, you won’t have any. A first-time user usually isn’t thinking about whether your software is more or less powerful than a competitor’s; she just wants to get something done. Quickly.


To illustrate, take a look at popular scripting languages. A majority of programmers will espouse that Perl or Python is a “better” language than PHP. They’ll claim that Perl/Python/Ruby programs are easier to read and maintain over the long run, have more mature libraries, and are inherently safer and more secure when exposed to the open Web.


Yet PHP is far more popular—at least for web development. Why? Because any high school student can just pick it up through osmosis by copying his buddy’s website.


There’s no need to read blogs, do extensive tutorials, or learn serious programming patterns. It’s conducive to tinkering: just start hacking on your site and figure out different PHP tricks from your peers.


Another example can be found in text editors. Should programmers use Emacs or vi? Does it matter? Not really, but why would a person choose one over the other? Here’s a true anecdote: when Ben first started learning Unix (during an internship in 1990) he was looking for a text editor to launch.


He opened an existing file by launching vi for the first time, and was utterly frustrated within 20 seconds—he could move around within the file, but couldn’t type anything!


Of course, vi users know that one has to enter “edit” mode to change the file, but it was still a horrible first experience for a newbie. When Ben launched Emacs instead, he could immediately begin editing a file just like he would do on his familiar home word processor.


Because the initial behavior of Emacs was identical to his previous experiences, Ben decided to become an Emacs user within his first minute. It’s a silly reason to choose one product over another, but this sort of thing happens all the time! That first minute with a product is critical.


Of course, there are other ways to destroy the first impression. The first time your software runs, don’t present the user with a giant form to fill out or a giant panel of mandatory preferences to set.


Forcing the user to create some sort of new account is pretty off-putting as well; it implies long-term commitment before the user has even done anything.


Another personal pet peeve is a website instantly blasting a visitor with a modal “Subscribe to us!” dialog box within the first two seconds. All these things send the user screaming in the other direction.


A great example of a nearly invisible barrier to entry is the TripIt web service, which is designed to manage travel itineraries. To start using the service simply forward your existing travel-confirmation emails (airplane, hotel, rental car, etc.) to plans@tripit.com. Poof, you’re now using TripIt.


The service creates a temporary account for you, parses your emails, creates a gorgeous itinerary page, and then sends an email to tell you it’s ready. It’s like a personal assistant instantly showing up, and all you did was forward a few messages!


With almost no effort on your part, you’ve been sucked in and are browsing the website as an involved user. At this point, you’re willing to create a real service account.


If you’re skeptical about your own product’s barrier to entry, try doing some simple tests. Give your software to ordinary humans—both technical and non-technical—and observe their first minute or two. You may be surprised at what you discover.


Software Developer Tip: 10


In pondering the size of your user base and whether it’s easy to get started, you should also consider how you measure usage. Notice that we said “usage,” not “number of installs”—you want a high number of users who use your product, not a high number of times people download your product.


You’ll often hear someone say, “Hey, my product has had 3 million downloads—that’s 3 million happy users!” Wait; back up. How many of those 3 million users are actually using your software? That’s what we mean by “usage.”


As an extreme example, how many machines is the Unix archive utility “ar” installed on? Answer: just about every Unix-based OS out there, including all versions of Linux, Mac OS X, BSD, and so on. And how many people use that program? How many even know what it is? Here we have a piece of software with millions of installs but near-zero usage.


Usage is something that many companies (including Google) spend a lot of time measuring. Common metrics include “7-day actives” and “30-day actives”— that is, how many users have used the software in the past week or month.


These are the important numbers that actually tell you how well your software is doing. Ignore the download counts. Figure out a way to measure ongoing activity instead.


For example, if your product is a website or web app, try a product like Google Analytics; it not only gives you these metrics, but also gives you insight into where your users came from, how long they stayed, and so on. These are incredibly useful indicators of product uptake.


Software Developer Tip: 11

Design Matters

Before the Internet came into prominence, the biggest challenge to getting any product to market was one of distribution. Few companies had the wherewithal to write a product and get it into thousands of stores across the world, so when a company put a product out there, they would then market the hell out of it.


This typically resulted in one or two “winners” in each software category (e.g., Micro-soft Word versus WordPerfect, Excel vs. Lotus 1-2-3, etc.). The primary criteria you used when choosing a product were features and cost, no matter how ugly or unintuitive the software was.


That, however, has changed.

The Internet is a global distribution network where it costs almost nothing to find and download software. And social media makes it easy for people to share their feelings about various products across the globe in seconds.


The result of these two massive changes (and a host of other, smaller factors) means that consumers today have a choice of what product to use.


In this highly competitive environment, it’s no longer enough to just get a product out there with the necessary features—your product needs to be beautiful and easy to use.


These days, no amount of marketing will rescue a crappy product, but a well-designed product that delights the people that use it will turn these same people into evangelists that market the product for you.


So good design is key, but a big part of good design is putting the user first, hiding complexity, making your product fast, and, most importantly, not being all things to all people.


Software Developer Tip: 12


When we say to “put the user first,” we’re suggesting that you and your team should take on whatever hard product work you can to make using your product easier for your users.


This may mean some hard engineering work, but more frequently it means making hard design decisions instead of letting your users make these decisions every time they use your product.


We refer to this as product laziness. Some would argue that laziness is a virtue for engineers because it leads to efficient automation of work. On the other hand, it can be easy to create something that results in great pain for users. Making software easy for users is one of the greatest challenges in product development.


A classic example of this kind of laziness is to present too many options to your users. People love to make fun of the late-1990s generation of Microsoft Office products: button bars! They make every possible menu item instantly available…for great convenience! User interface designers love to make fun of this idea, especially when taken to an extreme:


Having too many options is overwhelming. It’s intimidating and off-putting. There have even been blogs written about how too many choices create anxiety and misery. You even need to be careful with your software’s Preferences dialog. 


And if you’re making someone fill out a form, be lenient in what you accept: deal with extra whitespace, punctuation, or dashes. Don’t make the user do the parsing! It’s about respecting the user’s time. It’s really obvious (and infuriating) when a programmer could have made something friendly and easy for the end user but didn’t bother.


Software Developer Tip: 13


Most programmers vastly underestimate the importance of application speed (or latency, which sounds more scientific). Its effects are both fundamental and profound.


First, latency is another type of “barrier to entry.” We’ve become spoiled about web page speed. When told to check out a new website, if it doesn’t load within three or four seconds, people often abort and lose interest.


There’s simply no excuse here. The web browser makes it easy to walk away and redirect our attention to 12 other places. We have better things to do than wait for a page to load.


Second, when a program responds quickly, it has a deep subliminal effect on users. They start using it more and more because it feels frictionless. It becomes an unconscious extension of their abilities.


On the other hand, a slow application becomes increasingly frustrating over time. Users start using the software less and less, often without even realizing it.


After a product launch, it’s exciting to see usage grow over time. But after a while the usage often hits a limit—it just sort of flatlines. This is the point where the marketing folks often step in and scream about needing more features, prettier colors, nicer fonts, or more animations that “pop.”


Sometimes, however, the actual reason for the stall is latency. The program has become laggy and frustrating. As the next graph shows, user engagement decreases as latency increases.


A true story from Google: an engineering team one day released some dramatic latency improvements to Google Maps. There was no announcement, no blog post; the launch was completely secret and silent. Yet the activity graph showed a huge (and permanent) jump in usage within the first couple of days. There’s some powerful psychology going on there!


Even small improvements in latency matter when you’re serving a web-based application. Suppose it takes 750 milliseconds for your main application screen to load. That seems fast enough, right? Not too frustrating for any given user. But if you could slash your load times to 250 milliseconds, that extra half of a second makes a huge difference in aggregate.


If you have a million users each doing 20 requests per day, that amounts to 116 years of saved user time—stop killing your users! Improving latency is one of the best ways to increase usage and make your users happy. As Google’s founders like to say, “Speed is a feature.”


Software Developer Tip: 14


“But my software is complex,” you may think, “and it’s solving a complex problem. So why should I try to hide that?” That’s a reasonable concern, but it’s also one of the central challenges of good product design.


Elegant design makes easy things easy and hard things possible. Even when doing complex things your software should feel seamless and easy. (Again, we’re focusing on the user’s emotions.)


This is what we like to call “hiding the complexity.” You take a complex problem and break it up, cover it, or do something to make the software seem simple anyway.


Look at Apple again. Apple’s product design is legendary, and one of the cleverest things it did was to creatively tackle the problem of managing MP3 music collections. Before iPods came along, there were a handful of awkward gizmos that tried to manage music right on the portable device.


Apple’s genius was to realize that MP3 management was too difficult a problem to solve on a tiny screen, so it moved the solution to a big computer. iTunes was the answer.


You use your computer (with a big screen, keyboard, and mouse) to manage your music collection, and then use the iPod only for playback. The iPod can then be simple and elegant, and organizing your music is no longer frustrating.


Google Search is another well-known example of hiding complexity. Google's interface (and a barrier to entry) is almost nonexistent: it’s just a magic box to type in. Yet behind that box, there are thousands of machines across the planet responding in parallel and doing a search after every keystroke you type.


By the time you hit Enter, the search results have already rendered on your screen. The amount of technology behind that text box is jaw-dropping, and yet the complexity of the problem is hidden from the user. It behaves like Magic. This is a great goal for a creative team to pursue since it’s essentially the epitome of product usability.


Finally, we should mention a caveat about complexity. While masking complexity is laudable, it is not a goal to seal the software so tight that it ends up handcuffing all your users. Hiding complexity almost always involves creating clever abstractions, and as a programmer, you need to assume that the abstractions will eventually “leak.”


When a web browser prints a 404 error, that’s a leaked abstraction; the illusion is cracked. Don’t panic, though—it’s better to assume that abstractions are leaky and simply embrace them by providing deliberate ways to lift the curtain.


A great way to do this is to provide APIs to other programmers. Or for really advanced users, create an “expert mode” that provides more options and choices for those who want to bypass the abstractions.


Not only is it important to keep the interface flexible and circumventable, but the user’s data needs to be accessible as well.


Fitz put a great deal of passion into making sure Google products offer “data liberation”—that it’s trivial for a user to export his data from an application and walk away.


Software shouldn’t lock users in, no matter how elegant the interface is. Allowing users to open the hood and do whatever they want with their data forces you to compete honestly: people use your software because they want to, not because they’re trapped. It’s about engendering trust, which (as we’ll mention) is your most sacred resource.


Software Developer Tip: 15

Managing Your Relationship with Users

OK, so your product is appealing on first sight. It’s easy to get started. And once people begin, it’s really pleasant. What happens months down the line? How do you interact with people who use your product every day, for years at a time?


Believe it or not, many users want to have a relationship with your company or team. Happy users want to know what’s going on with your software’s evolution; angry users want a place to complain.


One of the biggest mistakes programmers make is to toss software over a wall and then stop listening to feedback.


Like marketing, the term customer service also typically has a negative connotation. A career in “customer service” often conjures up an image of a barista working at a coffee shop or a room full of robotic people answering support calls. But in reality, customer service isn’t a nasty, soul-draining task; nor is it something that other people (with lesser job descriptions) do.


It’s a philosophy to live by—a way of thinking about your ongoing connection to users. It’s something you need to do proactively as a creative team, not as a mere reaction to external complaints.


Engineers often dread direct interactions with users. “Users are clueless,” they think. “They’re annoying and impossible to talk to.” And while nobody’s requiring you to shower every user with love, the simple fact is that users want to be heard.


Even if they make inane suggestions or clueless complaints, the most important thing you can possibly do is acknowledge them.


The more you allow them to participate in the discussion and development process, the more loyal and happy they’ll be. You don’t have to agree with them, but you still need to listen. This is the “Respect” in HRT!


Companies are rapidly learning this in the age of social media—just reaching out to someone as a human and not as a giant, faceless corporation is often enough to alleviate that person’s concerns. People love it when corporations openly display HRT.


We like to illustrate the importance of managing users over time by drawing another simple (slightly unscientific) graph. As time goes on, your software gains more and more users. Of course, as you “improve” the product, it also gains more and more complexity:


The problem here is that as the number of users increases, their average level of technical ability decreases because you’re covering more and more of the general population.


Pair this up with ever-increasing complexity and you’ve got a serious issue with users’ despair. More despair means more complaints, angrier users, and an ever-increasing need for open communication with the software developers!


What can you do to avoid this trend?

To begin, don’t be in denial about the problem. Many corporations instinctively do everything they can to put up walls of bureaucracy between programmers and users. They create voicemail trees to navigate through or file complaints as “help tickets” that are tracked by layers of people who aren’t actually writing the software. 


Messages are relayed only indirectly through these layers, as though direct contact with the dangerous rabble might endanger developers (or pointlessly distract them). This is how users end up feeling ignored and disempowered and how developers end up completely disconnected.


A much better mode of interaction is to directly acknowledge users. Give them a public bug tracker to complain in and respond to them directly. Create an email list for them to help one another. Interact directly with users in social media. If your product can be open source, that’s a huge help as well.


The more “human” you appear to users, the more they trust in the product, and despair begins to lessen. Be on the lookout for people using your products in unexpected (and awesome) ways. Only through true dialogue can you discover what they’re really doing with your software, possibly something clever or thrilling.


Software Developer Tip: 16


Whether you’re a manager or an individual contributor, you need to spend some of your time managing upward. By this we mean you need to try to ensure that both your manager and the people outside your team are not only aware of what you’re doing but are aware that you’re doing it well.


Some people find this mode of “selling yourself” distasteful, and it may remain so, but the benefits of doing this are huge.


We’re not advocating that you sandbag all your estimates and pad out your deadlines, but wherever you can, try to avoid promising things that you can’t deliver, even if it means saying “no” more often than you’d like.


If you constantly miss deadlines or drop features, other people in the company will have less of a reason to trust you and will most likely pass over you when they’re looking for someone to get something done.


We recommend that you focus your energies on launching products over just about everything else. Shipping things give you credibility, reputation, and political capital more than just about anything else in a company. Launching your product is a high-visibility event that shows you’re accomplishing something.


As tempting as it might be to spend a ton of time cleaning up your code base and refactoring things, we’ve learned from experience that if you dedicate more than half of your time to this kind of defensive work, it’s hardly valued at all by anyone outside of your team, including your superiors.


You will then find yourself in the somewhat embarrassing position of having almost nothing (politically) important to show for your time. This is not only a good way to get no recognition, but also a good way to get your product canceled.


Software Developer Tip: 17

“Offensive” Versus “Defensive” Work

When Ben first became a manager, it seemed like his team’s productivity was being crushed under a mountain of accrued technical debt. He decided that the team’s top priority was to spend a long time doing nothing but paying back this debt. His superiors gave a cursory nod to this plan and the work began.


Things didn’t go well. Despite the prior approval, Ben’s manager began to get annoyed and impatient after a few months— why was the team getting “nothing done”?


Ben’s team was actually quite productive and he tried to show the enormous amount of debt that had been paid back. But it turns out there’s just no way this sort of work can impress someone; at an emotional level, it’s just fundamentally boring.


After this bad experience, Ben began to categorize all work as either “offensive” or “defensive.” Offensive work is typically effort toward new user-visible features—shiny things that are easy to show outsiders and get them excited about, or things that noticeably advance the appeal of a product (e.g., improved UI, faster response times).


Defensive work is an effort aimed at the long-term health of a product (e.g., code refactoring, feature rewrites, schema changes, data migration, or improved emergency monitoring).


Defensive activities make the product more maintainable, stable, and reliable. And yet, despite the fact that they’re absolutely critical, you get no political credit for doing them.


If you spend all your time on them, people perceive your product as holding still. And to make wordplay on an old maxim: “Perception is nine-tenths of the law.”


We now have a handy rule we live by a team should never spend more than one-third to one-half of its time and energy on defensive work, no matter how much technical debt there is. Any more time spent is a recipe for political suicide.


Software Developer Tip: 18


Regardless of the kind of company you work in, believe it or not, it’s not that hard to create a sort of luck for yourself. Richard Wiseman, the author of The Luck Factor, wrote that lucky people “are skilled at creating and noticing chance opportunities.”


We think the same tenet applies to create opportunities in companies: if you perform your job to the letter of the law and focus only on getting your own work done to the exclusion of all else, there will be few chance opportunities for you.


If you help others get their jobs done when given the chance, even when it’s not part of your job, there’s no guarantee (nor should there be a “tit for tat” expectation) that they’ll return the favor, but many people will gladly repay the favor in the future if given the chance.


Software Developer Tip: 19


If you’re like most engineers, you expect a logical promotion process where all it should take to get promoted is to excel at your job. Unfortunately, this world exists only in the most enlightened companies.


In most companies, you need to put some amount of effort into “playing the promotion game” to get yourself promoted (usually in addition to excelling at your job).


If you’re happy with your job, your salary, and your team, you might choose to not play the promotion game and settle into your job at whatever title and job level you’re already at.


This can leave you vulnerable in many situations—for example, your company reorganizes and you get shuttled to a new team, you get a bad manager, or you wind up under the thumb of the office politician.


The higher in the organization you can get (either as an individual contributor or as a manager), the more control you’ll have over your destiny inside the company. Putting a modicum of effort toward getting promoted when you’re comfortable in your position is a great way to invest in your security and happiness when something bad happens to your company or team.


Keep track of your accomplishments and use them in your self-assessment. Update your résumé and share it with your manager or promotion committee.


Read up on the promotion process and talk to your manager about what boxes you need to tick off to get promoted, and methodically work to tick off every box. Even if getting promoted is subjective and nondeterministic, there’s a lot you can do to increase the odds in your favor.


Software Developer Tip: 20


Every company has a “shadow” org chart that is unwritten but through which power and influence flow. There are only a few different types of people who make up the nodes in this graph.


Connectors are people who know people in every corner of the organization, and if they don’t know someone on a team, they can find the right person for you. Sometimes getting something done is just a matter of finding the right person to speak to, and the connector can help you find that person.


Old-timers may not have a high rank or fancy title, but they typically carry a lot of institutional knowledge and wield a lot of influence just because they’ve been around for a long time.


These are great people to go to when you’re trying to understand why the organization works in a certain way, or if you need a supporter that a lot of people respect.


People most often talk about this in jest, but administrative assistants wield an enormous amount of power and influence in an organization because they are agents of the executives they work for.


More importantly, they usually do an incredible amount of work to keep things running smoothly, so anger them at your own (and your career’s) peril. And never pass up a chance to be nice to an administrative assistant—they are the cornerstone of the Favor Economy.


Software Developer Tip: 22


How to Ask a Busy Executive For Anything…via Email?

Work in any big company long enough, and you’ll find yourself in a position where you need to email an executive (or any busy person you don’t know) to ask him for something.


Perhaps you need something for your product or team, or you are looking to right a wrong. Whatever the case, this is likely the first time you’ve ever communicated with this person. In this situation, almost everyone makes the same rookie mistake: they ramble, rant, and rave.


Fitz (while working at Apple) bought his mom a lemon of an iMac more than 14 years ago, and on the advice of a coworker sent a “short” email to Steve Jobs. This email served as a rough prototype of how to effectively ask an executive for help:


Less than 20 hours later Fitz received a call from someone who worked for Steve, and two weeks later his mom had a new (non-lemon-flavored) iMac.


Here’s the big secret: when given a chance to help right a wrong, more often than not people in positions of power would love to do the right thing—even busy executives (many of them enjoy righting a wrong, and absolutely all of them understand the value of gaining a little extra political capital).


Unfortunately, the email inbox of these people looks like a never-ending distributed-denial-of-service attack, and if they encounter an email from someone they’ve never met before that is 3,000 words of solid text with no paragraph breaks, the odds are good that they’re going to read 15 words in, press the Delete key, and then move on to the next email.


If, however, they can fix something by reading an email in 10 seconds and waving a magic wand (i.e., mailing one of their minions to Make It Happen), they’ll likely do it. They spend a few seconds delegating and get a big pile of political capital from you in return.


After years of trial and error, we’ve found that shorter emails are even more likely to get a response.

We call this the “Three Bullets and a Call to Action” technique, and it will drastically increase your chances of getting action—or at the very least, a response—from just about anyone you email out of the blue asking for something, not just an executive.


A good Three Bullets and a Call to Action email contain (at most) three bullet points detailing the issue at hand, and one—and only one—call to action. That’s it, nothing more—you need to write an email that can be easily forwarded along.


If you ramble or put four completely different things in the email, you can be certain that they’ll pick only one thing to respond to, and it will be the item that you care least about. Or worse, the mental overhead is high enough that your mail will get dropped entirely.


The bullet points should be short sentences (each one should fit on a single line without wrapping), and the call to action should be as short as possible.


If you want a reply from anyone, make it easier for the person to reply inline, preferably with a one (or two) word answer. Don’t ask half a dozen questions in one paragraph—limit yourself to a single question per paragraph, or ideally, a single question per email.


Lastly, your email should be loaded with HRT: polite, respectful, and devoid of grammar mistakes and spelling errors. If you positively cannot help yourself and simply must include more background or information, put it at the very end of your email (even after your signature), and label it clearly as “More details” or “Background.”


Get Out

In all the years that we’ve spoken about getting things done inside bad organizations and working with bad people, we always get people who come up to us after our talks and, exasperated, tell us they’ve tried everything and just can’t make any improvements or get anything done, so what can they do?


The unfortunate answer here is a simple one: there’s probably nothing else you can do. Don’t be a victim. Get the heck out of there.


If you can’t change the system, there’s no point in continuing to put energy into changing it. Instead, put energy into leaving it: update your résumé, and start asking your close friends if they know of any openings for you at other companies.


Train yourself in new things. One of the great things about being a knowledge worker in this day and age is that good one are in high demand, and that gives you the ability to control your own future.


Once you realize you have this control, it’s incredibly liberating. If you poke around and discover that you have other job options available to you, you may discover that you suddenly get a lot more things done at your work (under a lot less stress) because it’s not the end of the world if your current employer fires you! 


Software Developer Tip: 23

Do the right thing, wait to get fired

New Google employees often ask me what makes me effective at what I do. I tell them only half-jokingly that it’s very simple: I do the Right Thing for Google and the world, and then I sit back and wait to get fired.


If I don’t get fired, I’ve done the Right Thing for everyone. If I do get fired, this is the wrong employer to work for in the first place. So, either way, I win. That is my career strategy.


If you’re prepared and know your options, you’re the most liberated person in the world. Don’t be afraid to get out. We’ve been giving this advice after our talks for over five years now, and are happy to report that several people have emailed us to let us know that they heeded our advice and are now doing jobs that they love. And these emails are some of the best we’ve ever gotten—here’s one of our favorites:


Software Developer Tip: 24

All Is Not Lost

All this talk about quitting or waiting to get fired doesn’t mean that if you’re unhappy in your job you should dust off your résumé and hit the streets.


On the contrary, your first objective should be to make the changes necessary to be happy and accomplish your goals at your job, and this blog has given you a lot of the tools you’ll need to do that. If you don’t put the effort into understanding how to navigate your organization, you’re leaving a huge part of your destiny to chance.