Reading Notes: The Passionate Programmer

July 16, 2019

My notes from reading The Passionate Programmer, a book by Chad Fowler that compiles various pieces of career advice for technologists.

Each tip in this book comes with an actionable way to start implementing it. When reviewing these notes, if any of the tips seem particularly useful, refer to the corresponding section in the book.

Choosing Your Market

Most people make career decisions almost by accident - what languages and tech to learn, what domains to focus on, etc. These should instead be conscious, calculated decisions. Think of your career as a business. Your services are the product.

Lead or bleed? Make a list of technologies and rank them from bleeding-edge to moribund. Which are you proficient in? Where do they fall on the curve?

Supply and demand. Don't pick a technology that puts you in competition with millions of programmers in India. Compete on ability, not price. That requires focusing on tech that isn't mainstream.

Coding don't cut it anymore. To stay relevant and not be a code monkey, you have to master the business domain you're in.

Be the worst. Work with people who are better than you. They will make you better. Open source is good for this.

Invest in your intelligence. Work with fringe technologies. Just for the fun of it. It'll make you better, and people will see that you're passionate about programming. It can also make interesting blog posts.

Don't listen to your parents. Fear-driven advice is geared toward not losing. Take calculated risks. If you're not having fun, you're not going to be excellent.

Be a generalist. There are so many potential problems and needs that can come up. Be the guy who can solve them.

Don't just generalize in the sense of "know different languages and some design," but also along other axes like "leader / coder," "business / IT," etc.

Programmer geeks can't lead, and leaders can't hack. It's rare to find someone who's even decent at both.

Be a specialist. "Specialist" does not mean "I only know one thing" - it means having technical depth.

Don't put all your eggs in someone else's basket. Don't base your identity on another company's product / tech. Prefer open source products to proprietary ones.

Love it or leave it. If you're not passionate, you won't be great. You have to love it.

Investing In Your Product

If you just rely on ability and passive learning, you'll stagnate. You need mindful, deliberate practice. You need to make good choices in terms of what to practice.

Learn to fish. Don't take it for granted that other people on your team are experts in a certain part of the code base / domain / infrastructure, and therefore you don't need to worry about how those things work. Learn everything. Be at the mercy of no-one.

Also learn about magical / mysterious parts of your stack. Nothing "just works," especially when it breaks. Know it.

Learn how businesses really work. Most clients will be hiring you to improve their business. How can you do that if you don't know how businesses work?

Find a mentor. It's hard to know what's possible until you talk to someone who regularly goes beyond your perceived limits. Try self mentorship: pick a role model. What qualities make them great? How do you rate yourself on those same qualities? What are concrete things you could do to be better?

Be a mentor. Teaching something crystallizes our understanding of it.

Practice, practice, practice. When you practice music, it should sound like shit. If it sounds good, you're not pushing yourself. Let the ugliness happen behind closed doors.

Explore unfamiliar features of your favorite language to keep your tools sharp. Add features and fix bugs on open source projects to get used to reading code. Do code exercises in different languages.

The way that you do it. Learn the methodologies of how software gets built. What works and what doesn't? It's harder to find people who can make a team run smoothly than it is to find people who can code.

On the shoulders of giants. Study the work of the masters and break it down. Read code that solves different problems in different languages. It's like listening to Coltrane. What surprises you? What challenges you?

Read through open source projects and take notes. What did you learn from this?

Automate yourself into a job. Looks for parts of your job that you can automate and sell or use to make clients happy.

Executing

Talent only gets you so far. Be someone who gets stuff done.

Right now. Parkinson's Law works both ways. Create artificial urgency. If you had to take that task you've had on your plate forever and finish it this weekend, how would you do it?

Mind reader. Listen to stakeholders and leaders when they talk about things they wish their code / application did ("wouldn't it be cool if..."). If it's easy, implement those things before they formally ask for them.

Daily hit. Every day, have one visible accomplishment you can share that adds business value. This is a good idea in general, not just as it pertains to your job. You want people saying "Joey, man, he has a lot of hits."

Sit down and ask: "What are the small, annoying things my team deals with? How could things be better?" Make a list. Then do them.

Remember who you work for. Your job is to solve your business' problems. If you're too removed from the business to do that, focus on your team's problems or your manager's problems. Make sure your daily work is in line with the stated goals of the team.

Be where you're at. Don't do a shitty job in your current role because you're focused on your next role after you get that promotion / new contract / start that company / whatever. Paradoxically, you get ahead by focusing on being a high performer, not by focusing on getting ahead.

How good a job can I do today? Most work in software is mundane. Try to make it as challenging and interesting as the 20% that's novel, exciting, or highly visible.

How much are you worth? You work for a business. Unless you provide real value, you are a waste of money. Know how much money you're making for the company so that you will know where you stand when it comes to salary / contract negotiations.

A pebble in a bucket of water. Success breeds arrogance, which leads to blind spots. You are not irreplaceable. In fact, aim to be as replaceable as possible: share knowledge, document tasks, refactor and test complicated parts of the system that only you understand. If you're the only one who can work on a certain part of the system, then you'll be stuck doing that forever and won't get access to promotions or new projects.

Learn to love maintenance. Working on a maintenance project can come with more freedom and chances to impact the business than new projects. There's less pressure, lots of opportunities to refactor, more interaction with users, more chances to delight by making something faster or modernizing some part of the UI. You'll often get full reign because everyone else is fighting with each other to get onto new projects.

Eight hour burn. Work no more than eight hours in a day, but work your ass off and focus for those eight hours. By setting the constraint of eight hours, you can apply Parkinson's Law: there's no overtime, so what tasks am I going to accomplish in this eight hour stretch?

Learn how to fail. When a mistake inevitably happens, 1) bring it to the team's attention immediately; 2) take the blame; own it; 3) offer a solution (or a plan for finding one); 4) ask for help; swallow your pride and don't make it worse by going alone if you're over your head.

Say "no". "Yes" is usually a lie. If you say "no" when you need to, people will come to trust your "yes"es more. "I don't know" is another good one, and takes some bravery to admit. The key is to be honest and humble.

Don't panic. We panic because we lose perspective. When you feel yourself panicking, step back and observe the situation from a third-person point of view.

Say it, do it, show it. Make daily, 30-day, and 90-day plans (use one Trello board for all three?). List out items and prioritize them. Mark them DONE before clearing them out, so you can admire your accomplishments. Think both tactically and strategically about what you want to accomplish. Make planning a ritual.

Share your plans with your boss. Someone who creates and executes plans and is constantly thinking big picture is a leader. Ask for feedback, especially on larger items, to make sure you're working on the right things.

A proven track record of making and executing plans makes you a do-er. With credibility comes influence.

Marketing: Not Just For Suits

Most programmers think they're great, and that they don't need to do any self-promotion: their abilities will speak for themselves. Self-promoting is equivalent to brown-nosing, and is beneath them. The truth is they're afraid.

If you do something great and no-one hears about it, it didn't happen.

When marketing yourself, you have two goals: let people know you exist, and let people know that you can solve their problems.

Perceptions. Perception is reality. You should care what others think of you. The measure of how good you are or your product is is 100% subjective. Subjective means "perceptions."

Different people evaluate you with different metrics. Your CEO doesn't care how clean your code is.

Perceptions keep you employed, get you promoted, and make your products succeed or fail.

Adventure tour guide. Managers value communication. They want employees that make them feel comfortable about the project and its progress. Don't talk down to anyone, or assume they're less intelligent because they can't program.

Me write real good. Good writing skills are necessary and in short supply. Perceptions of you will be formed based on your writing ability. You are what you can explain.

Being present. Humans are biased towards others that they have face-to-face communication with. If you want to be seen as important to the team, you have to be there (at least sometimes).

Suit speak. When marketing your accomplishments, use the language of your audience. What do they care about? Can you frame your current project in terms of business benefits?

Change the world. To stand out, you have to come to work with your own mission, one that creates visible change. People should know who you are and the work you've done. "What does he do?" means you're not having an impact. Could be something simple like driving the adoption of test practices. Have a crusade.

Let your voice be heard. Think of yourself as a participating member of the industry. You need to make connections to different parts of the network. When you interview somewhere, you want your interviewer to have heard of you already. Publishing and speaking are the best ways to achieve this. Blogs -> books, speaking at user groups -> conferences. Start small and build momentum.

Build your brand. A brand should be two things: recognition and respect. The person most likely to fuck up your brand is yourself.

Release your code. Basically, do open source. On projects that potential clients / employers might use. "Top 100 Rails contributor" looks good on a resume.

Remarkability. There's a difference between being incrementally better than your peers and being truly remarkable. Find ways to stand out and create reasons for people to talk about you.

Making the hang. Really good people may be intimidating to approach, but they want to talk to you. They like being appreciated. Hanging out with top performers makes you better. These connections can be online, too - open source collabs are a great way to get on someone's radar.

Maintaining Your Edge

The first four sections are a loop: research, invest, execute, market, then repeat. Get stuck in any part of the loop for too long and you become obsolete.

Already obsolete. Success breeds hubris, complacency and blind spots. Always be playing with tech on the bleeding edge, because what you're making money with today will be obsolete in a few years.

You've already lost your job. Jobs change quickly. Don't identify too closely with a job title or company.

Path with no destination. Make the journey a good one. Don't just focus on the outcome (shipping a product, for instance), but focus on the process too (putting in the thought to make an amazing product).

Make yourself a map. Have a "product roadmap" for yourself and your career. Have milestones ahead that you can work towards. It's real easy to be in "maintenance mode", until you realize that you're obsolete and boring.

What bigger picture do all the individual items in your roadmap add up to? What's your story?

Watch the market. Think of your investments in personal development like investments in the stock market. Do you know how your skills are moving in comparison to others? Are you in a conservative or high risk / high reward market? What are the rising stocks of today? The next three years? What are the alpha geeks into?

Anything that is a good investment today will not be a good investment in a few years.

That fat man in the mirror. Having your skills go obsolete is like getting fat: you don't notice it happening, and then suddenly your pants don't fit. You have to do honest self and peer-reviews constantly to get a picture of where you are. Get on the scale every day.

South Indian monkey trap. A monkey sticks his arm in a narrow spot, grabs food, and can't get his hand back out. He dies instead of just letting go of the food. Don't be like that monkey. What values are you holding onto without questioning? Some technology that is fading into obsolescence? Wanting to be promoted to manager? Identify your monkey traps.

Avoid waterfall career planning. It's easy to make small changes to your career: new company, new city, different role, different domain, different technology. Make sure you're not executing a plan that leads somewhere you no longer want to go.

Better than yesterday. Big changes (like getting in shape) often proceed in ways that are difficult to observe. "I worked out for three hours yesterday, why am I not huge?" Just focus on getting a little bit better each day. Don't let big goals be demotivating.

Go independent. At a lot of companies, you can get by without doing much. This makes you slow, though, and you have no motivation to become excellent. Being an independent contractor instead of an employee tests you more and forces you to be sharp, to think about marketing yourself, and to clearly define the value you're providing.