Perhaps there’s an element of imposter syndrome, too; we may think that this project is beyond us. We can’t see our way through to the end; we’ll get so far and then be forced to admit that we’re lost.
If that’s not working, try externalizing the issue. Make doodles about the code you’re writing, or explain it to a coworker (preferably one who isn’t a programmer), or to your rubber duck. Expose different parts of your brain to the issue, and see if any of them have a better handle on the thing that’s troubling you. We’ve lost track of the number of conversations we’ve had where one of us was explaining a problem to the other and suddenly went “Oh! Of course!” and broke off to fix it.
We should avoid programming by coincidence—relying on luck and accidental successes—in favor of programming deliberately.
For code you write that others will call, the basic principles of good modularization and of hiding implementation behind small, well-documented interfaces can all help. A well-specified contract (see Topic 23, Design by Contract) can help eliminate misunderstandings.
Don’t code in the dark. Build an application you don’t fully grasp, or use a technology you don’t understand, and you’ll likely be bitten by coincidences. If you’re not sure why it works, you won’t know why it fails.
Rely only on reliable things. Don’t depend on assumptions. If you can’t tell if something is reliable, assume the worst.
Don’t be a slave to history. Don’t let existing code dictate future code. All code can be replaced if it is no longer appropriate. Even within one program, don’t let what you’ve already done constrain what you do next—be ready to refactor (see Topic 40, Refactoring). This decision may impact the project schedule. The assumption is that the impact will be less than the cost of not making the change.
You refactor when you’ve learned something; when you understand something better than you did last year, yesterday, or even just ten minutes ago.
In order to guarantee that the external behavior hasn’t changed, you need good, automated unit testing that validates the behavior of the code.
Don’t try to refactor and add functionality at the same time.
Make sure you have good tests before you begin refactoring. Run the tests as often as possible. That way you will know quickly if your changes have broken anything.
Testing Is Not About Finding Bugs.
We strongly believe that the only way to build software is incrementally. Build small pieces of end-to-end functionality, learning about the problem as you go.
A culture of testing means all the tests pass all the time. Ignore a spew of tests that “always fail” makes it easier to ignore all the tests, and the vicious spiral begins.
Make no mistake, testing is part of programming. It’s not something left to other departments or staff. Testing, design, coding—it’s all programming.
8. Before the Project
No One Knows Exactly What They Want.
whenever you create something, you need to pause and think “what is my motivation to create this?”.
Requirements rarely lie on the surface. Normally, they’re buried deep beneath layers of assumptions, misconceptions, and politics. Even worse, often they don’t really exist at all.
Programmers Help People Understand What They Want.
This is both an intellectual process and a creative one: you’re thinking on your feet and you’re contributing to a solution that is likely to be better than one that either you or the client would have produced alone.
Requirements are not architecture. Requirements are not design, nor are they the user interface. Requirements are need.
Create and maintain a project glossary—one place that defines all the specific terms and vocabulary used in a project.
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
Having a second developer’s full brain available during the task brings a lot more mental power to bear.
Build the code, not your ego. It’s not about who’s brightest; we all have our moments, good and bad.
Criticise the code, not the person. “Let’s look at this block” sounds much better than “you’re wrong.”
Listen and try to understand others’ viewpoints. Different isn’t wrong.
Conduct frequent retrospectives to try and improve for next time.
Don’t Go into the Code Alone
Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation.Responding to change over following a plan.
9. Pragmatic Projects
Programmers are a bit like cats: intelligent, strong willed, opinionated, independent, and often worshiped by the net.
Stay awake and aware for increased scope, decreased time scales, additional features, new environments—anything that wasn’t in the original understanding. Keep metrics on new requirements.
Great project teams have a distinct personality. People look forward to meetings with them, because they know that they’ll see a well-prepared performance that makes everyone feel good.
Maintain awareness to stay DRY.
Does it work well for you? Or was it adopted just because it was being used by the latest internet-fueled success story?
Do What Works, Not What’s Fashionable
the idea of the Pragmatic Starter Kit was born, covering these three critical and interrelated topics: Version Control, Regression Testing, Full Automation.
You deliver when the users need it, when it makes business sense to do so.
Pragmatic Programmers are different. We are driven to find our bugs now, so we don’t have to endure the shame of others finding our bugs later.
Test Early, Test Often, Test Automatically
In fact, a good project may well have more test code than production code. The time it takes to produce this test code is worth the effort. It ends up being much cheaper in the long run, and you actually stand a chance of producing a product with close to zero defects.
A bug-free system that answers the wrong question isn’t very useful.
But it’s these expectations of business value that really count—not just the software project itself. The software is only a means to these ends.
Even though your title might be some variation of “Software Developer” or “Software Engineer,” in truth it should be “Problem Solver.” That’s what we do, and that’s the essence of a Pragmatic Programmer.
The Golden Rule (“Do unto others as you would have them do unto you’’) and a foundation of mutual respect among the developers is critical to make this tip work.
It’s Your Life. Share it. Celebrate it. Build it. AND HAVE FUN!