Effective Programming — Jeff Atwood

The book is very well structured with advice on how to improve as a programmer in several different aspects; writing better code, treating your customers better, and improving your communicating. It explains everything with examples and solid advices.

My rating: 4/5. I really liked it. My notes length: 5 min.
Date read: November 10, 2016. More information on Amazon.

My Notes

Being a Programmer

Don’t become a programmer only because someone tells you to. Become a programmer because you want to solve problems, you want to write your own rules, and you enjoy doing it.

The most important skill for a programmer is the ability to effectively communicate ideas. This leads to code that communicates intention. The only work that’s reusable is the one that you understand what it communicates.

Always keep on studying and practicing on how to write. Create a blog. Write open source code. Never stop getting your writing out there for others to criticize it.

Use StackOverflow to improve your writing. If your answer doesn’t end at the top, figure out how to improve it. Maybe your answer was too verbose, maybe there was something missing.

Use writing as a tool to figure out what you don’t truly understand.

Always leave time in your coding for discussion, introspection, and to study. That’s how you stop doing always the same thing, improve your solutions, and move forward.

Incessant and obsessive practice and desire for improvement is another form of procrastination.

You have to strike a mindful balance between practicing your craft and thinking about how you practice your craft. — Jeff Atwood

Never stop reading. Even if most of what you read is not new, try to find that one thing that will help you improve.

If you have an idea that someone copied, be proud to have something worth copying.

Take full responsibility for the failures produced by your software. It will earn you respect and credibility.

Your job as a programmer is to solve the customer’s problem. Focus on creating value, and don’t drift away from that value proposition.

Writing Code

Be reluctant to write any new code. It must be your last option.

Don’t start by thinking what code you need to write, but with how you’ll know that you’ve finished. Try to make it explicit in an automated test.

Whenever you’re about to write a print or debug statement, think on what needs to happen, and convert it into an automated test.

Start small and increase in complexity and other dimensions as needed by testing.

Always write your code as if comments doesn’t exist. Strive for the simplest and most self-documenting way you can come up with.

Writing good, meaningful comments is hard. It’s as much an art as writing the code itself; maybe even more so. — Jeff Atwood

Rewrite code that is too hard to understand without comments.

Learn to read code, it’s always the most up-to-date documentation.

When you have a problem in your dependencies, download the code and study it. Follow the trail of what you need to understand.

Always stay on top of every little detail of your software. Constantly polish and improve every aspect of it, no matter how trivial.

Speed is a highly appreciated feature; make your software fast.

Constantly test failure scenarios, otherwise your mitigation systems won’t work when you need them the most.

The best way to avoid failure is to fail constantly. — Jeff Atwood

Development Process

Accept that we usually overestimate how much we can get done.

Don’t let your email, phone, chats, or browsing impulses interrupt you from your task at hand.

Prefer speed of iteration over quality of iteration. By having faster iterations, you build momentum, engage your users, and make them feel part of what you’re building.

Don’t wait until your software is perfect to ship it. You don’t know what “perfect” looks like until you ship it. Launch soon so you know what matters to your users, and then improve your software best on the feedback.

How fast you improve upon feedback is far more important than any single release.

Your Users

Consider your anonymous users as much as your registered users. Remember that your registered users were anonymous at some point.

Don’t forget the details. Your software is only a collection of tiny little details.

Start designing the UI. Your users will only care about the UI, it’s one of the most important details.

Prototype the UI with anything you want except development tools.

Pagination works when there are a few pages. When you have thousands of pages, you need to have search and filters, not pagination.

User experience is important. Study about it and work towards user friendly and usable software.

The ultimate unit test is whether or not users want to use your application. — Jeff Atwood

Be close to your users. Talk to them, get feedback from them, learn from them, and share their pains.

When receiving feedback, prefer watching what they do rather than listening what they have to say. Confirm the feedback by analyzing the behavior of other users.

About 10% of your feedback will be very good. Be honest and respectful when asked about something you’re not planning on doing.

Think how to measure user behavior in a meaningful way that it’s both unobtrusive and useful for you to improve your software.

Work on bugs that bothers your users. Extremely rare bugs that nobody ever encounters are not worth fixing.

Leverage gamification to increase engagement and reinforce learning about your software.

Teams

Never leave aside the personal aspect of work. Processes, people issues, and the day-to-day is what will make your project successful or fail.

Always first presume that you’re the one who’s wrong.

Ensure that you’re certain of your observations before sharing it to the team.

Work hard and focus on your actions and results; it’s the best way to earn credibility.

Care for your team.

Try to avoid meetings. If you can’t, be sure the scope of the meeting is clear and narrow, and that it has the necessary people and nobody else.

Make sure the scope of your meeting is to make things happen as a direct result of the decisions made in the meeting.

Ask questions to engage the team and diffuse conflicts.

Working remotely works when your team likes to code as much as you do and gets things done.

Agree on a unique channel to post announcements, weekly reports, and meeting summaries. Every message on this channel has to be useful and meaningful, otherwise it will harm more than help.

It’s still important to interact with people. Never work more than one week without video chatting with your team.

Protect your environment from interruptions. Deep work requires focused mental concentration.