Skip To Content
Pragmatic Programmer

A Pragmatic Philosophy

The attitudes, styles, and philosophies of a pragmatic programmer.

Take Responsibility #

Don't make excuses for your mistakes. Be honest and direct about shortcomings like late deliverables or unforeseen problems.

Taking responsibility for them means balancing doing your personal best against any risks you see that are beyond your control. Take these into account when making a call, and take responsibility for the result.

The best way to own up to a shortcoming is to provide options and solutions, not lame excuses. Find the risks and make backup plans in case things go bad.

If you need to approach someone about a mistake, play out how you think the conversation will go. Answer the questions you expect them to ask, and go from there. You may not need to talk to them at all. At the very least, have your answers for them ready.

Some common options for salvaging situations are:

Avoid Broken Windows #

The amount of disorder in a code system gradually increases like a force of gravity, and is known as "software rot." Just a little software rot can be bad because of the "broken window theory."

If a building has a broken window too long, people assume no one cares about fixing it, people don't care about maintaining the building, and it soon gets damaged beyond repair or care. Small signs of software rot are like broken windows - if you don't fix them fast, the entire program will start falling apart. Neglect accelerates rot worse than anything else.

Fix each broken window as soon as you see it. If you can't, at least acknowledge it in a way that shows you care and will fix it as soon as possible. It is always worth the time to do so. Even during code disasters and urgent fires, don't use them as an excuse to create more broken windows and let them pile up.

Instigate Positive Change #

Making a positive change in a codebase can be time-consuming and frustrating. A better approach is starting with what you can reasonably ask for and develop, make it well, and let others in the company marvel at it. Showing it as an "ongoing success" makes it easier to get them involved, contributing, and making the larger change a reality. Show a glimpse of the future others can rally around.

Fight Creeping Change #

On the flipside to gradual positive change, fight against gradual negative change. Extra requirements and specs can slowly get added to a project until it's so derailed from the original goal it breaks down. Always remember the bigger picture and watch what happens around you, to ensure creeping change won't derail your goals.

Know What Good-Enough Software Looks Like #

Perfect software is impossible. Do research to find out "good enough" is, which will meet all the needed requirements (from employees and users) to be successful. Aim for this over perfect or overpolished code. This also lets you know when to stop so the program doesn't get lost in the code itself.

The scope and quality of the system you produce should be specified as part of that system's requirements.

Maintain a Knowledge Portfolio #

Knowledge and experience are a coder's top asset, so invest in them. Good knowledge portfolio maintenance includes:

Some tips for what to invest in are:

All this expands your thinking and lets all this info cross-pollinate for creative thinking for projects.

To find the best opportunities for learning:

Communicate Well with Others #

Great ideas are useless if they're not communicated well. Coders work with ideas, so communicating those ideas effectively matters a lot.

Plan Ahead #

Write outlines of what you want to say with key points. Make sure it gets across what you want to say. This applies to any form of big communication.

Know Your Audience #

Remember the what (what's important to them) and the how (how to keep their interest) of what matters to your audience. Get to the point of what matters most to them so you're not just talking at your audience.

Pick a Good Time #

Know your audience's priorities and when they're most likely to listen. Don't choose a time where they want to leave or have more important issues to cover. You may just need to simply ask if it's a good time to talk about something.

Presentation #

Some audiences want bare-bones, others want some conversation first. If they need it in a format that's not realistic, like condensing the info too much, don't be afraid to give that feedback.

Also, make sure documents look presentable. Use modern documentation software to add basic styling, check other docs for inspiration, and don't make them look dull. Check your spelling thoroughly.

Be Interactive #

Get early feedback on what you're presenting or communicating. It builds a better document and a better relationship with who you get help from.

Listen and Respond to Others #

If you don't listen to others, they don't listen to you. Don't glaze over others' words, seriously listen to them. Encourage questions or conversation, to turn the meeting into a dialog.

When questions are asked, either during a presentation or in an email afterward, actually respond. Any response is good, even if it's that you'll respond later when free. Keeping others informed and in touch matters most.