Good Development Practices

Last Updated: January 1, 2026

Core Principles

1. Read the Reference Documentation

Go straight to the source. Before Stack Overflow, before asking an LLM, before guessing - read the official documentation.

• Read the Apache web server documentation
• Study the Python standard library
• Understand the TOML spec
• Don't guess - go to the source

Documentation is often surprisingly accessible and well-written. Understanding the reference material means you'll truly understand the tool, not just fumble through using it.

2. Read Source Code

Jump to definitions. Reading source code reveals how things actually work, often more clearly than documentation alone.

• Discover undocumented features
• Understand implementation details
• Build accurate mental models
• Find answers that may not be documented yet

Great developers understand the technologies they use on a fundamental level. It's one thing to use a tool; it's another to truly understand it.

3. Understand Your Tools Deeply

When using a tool extensively (especially in production), understand:

• Its limitations - When is the tool NOT a good fit? When does it break?
• Its ecosystem - What libraries exist? Who uses it? What plugins are available?
• Active maintenance - Who maintains it? Are they active? What's their motivation?
• How it extends - Can it be extended? How and why?

Context matters: a personal project requires less due diligence than choosing a tool for production use at a company. If you use something like Kafka extensively, understand it deeply - not just from Reddit posts.

4. Read Error Messages Carefully

Really read the error message. Don't skim - meditate on it.

The best engineers can infer significant information from very little context. Most problems can be fixed just by carefully reading what the error is telling you.

Combine this with project context. Error messages become more valuable when you understand the codebase producing them.

5. Break Down Problems

Simplify until digestible. Everyone gets stuck. The best developers know how to get unstuck by breaking problems into smaller pieces.

This is a hard skill requiring experience, but it's trainable. Some problems are too hard to solve all at once for anyone.

Breaking down problems is the bulk of professional development work. Done right, it feels like cheating - you just solve simple problems until you're done.

6. Don't Be Afraid to Get Your Hands Dirty

Code is just code. The best developers:

• Read a lot of code
• Are not afraid to touch it
• Never say "that's not for me"
• Just start and learn

You can pick up any skill with time and effort. Don't wait for permission. Don't gatekeep yourself.

Often, people become the go-to expert simply because they were the only one unafraid to touch something in the first place.

7. Help Others (Within Reason)

Being helpful is valuable, especially in corporate environments. Try not to be difficult to work with.

However, recognize that practical constraints exist - time, deadlines, and yes, organizational hierarchy all matter. Balance helpfulness with reality.

8. Never Stop Learning

Learning is a career-long journey. The best developers at 60+ years old keep learning new tools and languages.

Many people stop learning after university or their first job, treating education as a destination rather than a continuous process. Programming offers a unique opportunity: every day is a chance to learn something new and multiply your skills.

Don't get stuck thinking what you learned in school is the only "right way" to do things. Stay curious.

9. Evaluate New Technology Carefully

Don't follow trends blindly, but don't dismiss them either.

The best engineers carefully evaluate benefits of new technology. If they dismiss something, they can tell you:

• Exactly why
• When it WOULD be a good choice
• What alternatives exist

The proper mentality: Everything has tradeoffs. Evaluate thoughtfully based on your specific needs.

10. Listen to Everyone

Try to learn from everyone - principal engineers and juniors alike. Newcomers often:

• Aren't entrenched in politics yet
• Have fresh perspectives
• Don't know "why things are hard" yet
• Propose creative solutions

That said, context matters. Experience and expertise do carry weight in decision-making, and that's okay.

11. Have Patience

With computers, humans, and especially yourself.

Not everything works right away. People need time to learn. Most people aren't stupid - they just have incomplete information (and you might be the one with incomplete information).

To solve hard problems, you need:

• Incredible patience
• Focus
• Dedication
• Ability to return to the keyboard and push through

Delivering projects is hard. Pushing a project over the finish line is really, really hard.

12. Keep It Appropriately Simple

Write code that matches the problem complexity.

Sometimes problems are just hard. Complex problems may require complex solutions. Don't force oversimplification.

The goal isn't always "simple code" - it's code that appropriately addresses the problem's complexity and can be understood and maintained.

Final Thoughts

This is not a comprehensive checklist. Every situation is unique. These principles are guidelines, not rules.

Sources

This document is based on insights from:

• The Best Programmers I Know by Matthias Endler
• Video commentary and discussion on the above article

Related Documentation