Lessons Learned: The Passionate Programmer
Below are 5 of my favorite lessons from the book The Passionate Programmer by Chad Fowler.
Learn How to Fail
Everyone makes mistakes so it’s important to learn how to react when we do make a mistake:
- We shouldn’t hide our mistakes and instead, we should let our team know as soon as possible. Mistakes that we catch early are easier to fix and will likely have a lesser negative impact.
- We need to find a solution as quickly as possible. That means we should take responsibility for the issue (even if we are not 100% at fault) and start searching for a solution instead of searching for who to blame.
- We should propose a specific plan (step-by-step, goals) on how to fix the issue. This is especially important if the issue affects others on our team.
- We shouldn’t be afraid to ask for help, especially if we are unsure with our proposed solution.
- We shouldn’t panic. Panicking will not give us an advantage but will instead cause us to underperform in a situation when we need to perform our best.
Step off of the Hedonic Treadmill
We all want to progress in our careers. Be it a bigger salary, a shinier title, or more responsibilities. While we should be ambitious and have goals, being too ambitious can sometimes produce negative results.
When we constantly want more, we become more focused on our next job rather than our current one. And while we fantasize about our future job, we may start to produce mediocre work at our current one.
When we compare our current job with a fantasized future job, our current job will always appear worse. It makes us ignore the good parts and amplify the bad parts of our current job.
While it seems counterintuitive, we may produce better results by focusing on the present. With our focus on our current job, we enjoy it more. We start noticing the small (daily) wins that we would otherwise miss and feel more of an essential part of the team. As we enjoy our job more, we become more motivated and productive, which makes it more likely for us to succeed.
Make Borings Tasks Fun
We do our best work when the task is fun, exciting, or interesting. But when a task is boring, we drag our feet and as a result, produce mediocre results. Almost every job has tasks that few enjoy doing but still need to get done. These are usually tasks where we don’t get to flex our creative muscles or test our skills. But what if we could make those boring tasks more fun?
One way to do so is to make the boring tasks more challenging. How would we do a task if we wanted to do it “perfectly” or what if we imposed a very tight deadline?
Another way to make boring tasks more fun is to turn them into a competition with our coworkers to see who can do them better.
Improve Your Writing
We write a lot during our workdays so it’s a good idea to become good at it. This is especially important for distributed teams where we won’t be effective team members if we are unable to express ourselves.
Improving our writing will also make us better programmers. The ability to explain an idea and lead the reader to a logical conclusion is very similar to the ability to design a maintainable system that future developers will be able to understand.
Improving our writing also saves time (and patience) as our team members don’t need to guess what we meant or have to reimplement a feature because of a misunderstood of our writing.
Take One Small Step at a Time
When we are facing large, complex projects we quickly become demotivated. We become farsighted and only see the amount of work and time that it will take to fully complete the project instead of seeing all the small (easy) steps that will get us closer to finishing it.
On larger projects, we don’t make a lot of progress in the short term. This can make it seem like our efforts are for nothing and can lead us to abandon the project completely.
The key to completing large projects is to focus on making our project better today than it was yesterday.
If we work on an application with poor codebase health, the task of improving it will look daunting. Instead of focusing on the end state where the codebase is in “perfect” health, we should instead focus on making it just a tiny bit better. We should look for easy wins in the parts of the codebase we are currently working on. See a poorly named function? Rename it. See a large section of commented-out code? Remove it. See a long class method? Refactor it into smaller, well-named methods.
Do you find these lessons interesting? Well, I’ve got good news for you. The book contains many more such lessons (53 to be exact). It also features a couple of amazing essays by successful people from our industry, my favorite one being from the founder of GitHub. So if you are looking for a book to improve your career, this is a great choice.