Tired of scrambling to get your work done?

There’s always more work to do.

There’s more code to write, more features to add, more bugs to fix. There are always more issues queued up in the issue tracker, more maintenance that you just can’t get to, more ideas coming from the product manager.

There’s always more work, but there’s never enough time. Even if you worked 24 hours a day, 7 days a week, you would never be able to keep up with the backlog on your software project.

But if you were productive enough, you could:

• Take the afternoon off, confident that you’ve produced highly valuable work.
• Gain more influence on how your project or team runs.
• Have an easier time finding a new job–including jobs with a technology stack you don’t know.

How do you become more productive as a programmer? By creating more value with the fixed time you have.

This might seem a like truism, so let’s dig a little deeper and see where the value you produce really comes from.

Moving beyond churning out code

Let’s say you’ve been asked to code a specific implementation of a specific feature: it should take you five business days to implement. If you get distracted, spin your wheels, or notice a bad assumption too late, you might end up taking two weeks instead of one: you’ve cut the amount of value you produced in half.

So obviously, you want to avoid wasting time while you’re coding.

But sometimes you can come up with a better and faster implementation strategy, that will take only one day to code. You’d be producing the same amount of value in one day instead of five: you’d be operating at 5× the productivity.

Coming up with good solutions is what senior software engineers do, and that’s a big improvement in productivity over just coding what you’re told to code. But even here you’re still dependent on someone else to come up with valuable problems to solve: if you’re given a low-value problem, your productivity will be low no matter how good your solution is.

When you take the next step and start identifying problems, when you can go to your boss and say “I’ve noticed this bug that’s losing users to the tune of $3 million a year, shall I go fix it?”, now you’re even more productive. You’re creating even more value with same amount of time. So you also want to learn how to identify—before you ever start coding.

What should you work on?

Once you’re able to expand your skills beyond just coding exactly what you’re told to code, you will start noticing there are far too many things you could be working on:

• You could work on your current implementation strategy,
• or consider alternative designs,
• or look for more valuable problems,
• or maybe spend some time learning new skills,
• or maybe start looking for a newer, better job,
• and so on and so forth.

All this choice means it’s easy to get distracted, or spin your wheels, or get too overwhelmed and revert to just staying in your box and churning out code.

You want to take control over your work process, with the confidence and skill to make reasonable choices in the face of uncertainty. You can do so by learning how to prioritize based on your personal and organizational goals, and applying time management skills to help get you unstuck when necessary.

Unfortunately, most discussions of programming productivity end up focusing purely on technology and skip over these necessary problem-solving skills. That’s why they’re “secret”: unless you have a excellent manager you’re expected to somehow figure them out on your own.

Knowing these skills can be the difference between working overtime and getting a raise, between taking months to find a new job and quickly getting a job you love.

Become productive faster with this book

I’ve learned these skills over the course of 20 years, but you can learn them far faster by reading my book, The Secret Skills of Productive Programmers.

The book covers over 30 different skills and techniques, covering:

• Prioritizing based on your goals. If you don’t know your goals, how can you achieve them?
• Time management skills like timeboxing and knowing when and how to ask for help.
• Efficient implementation skills so you don’t waste time.
• Finding better solutions using techniques like the 3-solution rule, research, negotiation, designing in writing, and more.
• Identifying more valuable problems using techniques like decision critiques, joint search with solutions, and more.
• More efficient learning, from integrating learning into your work to better ways to read a book or search the web.

Donate and get the book

You’ll get:

• The fast path to learning the productivity skills you need.
• 170-page book in PDF format, and versions for Kindle (mobi) and other ebook readers (epub).
• Future updates to the book, delivered via email.
• Money-back guarantee, for any reason.

Instead of buying the book, you can get a copy by donating to a US voting rights organization. Donate any sum of money to Spread the Vote, Fair Fight, or other related organizations, and email me the receipt. Assuming it’s an organization I’m happy to support (not sure? just ask) I will email you a copy of the book.

Live in a low-income country? Send me an email to get a free copy.

About the author

Hi! I’m Itamar. I’ve been writing software since 1995 or so. As an employee I’ve worked for companies small and big, ranging from 8-person startups to a year at Google as a product manager (my previous employer got acquired). And as a consultant I’ve written software for a similarly broad range of companies.

I wrote this book in the hopes of helping you and other programmers learn the productivity skills that took me decades to learn.

Changelog

June 23, 2023

Significant restructuring of the book, hopefully making it easier to know when the skills are relevant, and providing a more useful mental map.

September 22, 2020

Added extensive example of designing in writing.

August 10, 2020

Initial versions of mobi and epub files, still very preliminary.

Complete editing pass on the whole book:

• Adjusted chapter order.
• Typo and phrasing fixes throughout.
• Rewrote part of a number of chapters.

June 24, 2020

• Added new chapters on defining the problem and learning the zeitgeist.
• Added section on searching for errors to search engine chapter.

June 1, 2020

• Greatly expanded the chapter on learning from others.
• Added an interview with Alex Gaynor.

May 18, 2020

• Expanded the chapter on close reading with an example of close reading of documentation.
• New chapters: how to use a search engine better, systems not individuals.

May 8, 2020

• New chapters: Why not The Five Whys, Walking away, Choosing which problem to work on.
• Moved close reading chapter to solutions section.

May 6, 2020

Initial release.