More on this book
Community
Kindle Notes & Highlights
Schrödinger’s cats:
How many possible futures can your code support?
We use the term tracer bullet development to visually illustrate the need for immediate feedback under actual conditions with a moving goal.
Pragmatic Programmers, however, tend to prefer using the software equivalent of tracer bullets.
Look for the important requirements, the ones that define the system. Look for the areas where you have doubts, and where you see the biggest risks. Then prioritize your development so that these are the first areas you code.
The diagonal line shows the path that feature takes through the code.
it proved that the UI could talk to the libraries, the libraries could serialize and unserialize a query, and the server could generate SQL from the result.
Tracer code is not disposable: you write it for keeps. It contains all the error checking, structuring, documentation, and self-checking that any piece of production code has. It simply is not fully functional.
However, once you have achieved an end-to-end connection among the components of your system, you can check how close to the target you are, adjusting if necessary. Once you’re on target, adding functionality is easy.
You have an integration platform
You have a better feel for progress In a tracer code development, developers tackle use cases one by one. When one is done, they move to the next.
The tracer code approach addresses a different problem. You need to know how the application as a whole hangs together.
You want to show your users how the interactions will work in practice, and you want to give your developers an architectural skeleton on which to hang code. In this case, you might construct a tracer consisting of a trivial implementation of the container packing algorithm (maybe something like first-come, first-served) and a simple but working user interface.
Prototyping generates disposable code. Tracer code is lean but complete, and forms part of the skeleton of the final system.
we can target a prototype to test one or more specific aspects of a project.
We tend to think of prototypes as code-based, but they don’t always have to be.
Post-it notes are great for prototyping dynamic things such as workflow ...
This highlight has been truncated due to consecutive passage length restrictions.
Prototypes are designed to answer just a few questions, so they are much cheaper and faster to develop than applications that go into production.
Things to Prototype
Architecture
New functionality in an existing system Structure or contents of external data Third-party tools or components Performance issues User interface design
Prototyping is a learning experience. Its value lies not in the code produced, bu...
This highlight has been truncated due to consecutive passage length restrictions.
To prototype user interfaces, use a tool that lets you focus on the appearance and/or interactions without worrying about code or markup.
Here are some specific areas you may want to look for in the architectural prototype: Are the responsibilities of the major areas well defined and appropriate? Are the collaborations between major components well defined? Is coupling minimized? Can you identify potential sources of duplication? Are interface definitions and constraints acceptable? Does every module have an access path to the data it needs during execution? Does it have that access when it needs it?
good to keep in mind
ask someone who’s already done it. Before you get too committed to model building, cast around for someone who’s been in a similar situation in the past. See how their problem got solved.
That’s how people estimate in the real world. Not with a single number (unless you force them to give you one) but with a range of scenarios.
We find that often the only way to determine the timetable for a project is by gaining experience on that same project. This needn’t be a paradox if you practice incremental development, repeating the following steps with very thin slices of functionality: Check requirements Analyze risk (and prioritize riskiest items earlier) Design, implement, integrate Validate with the users
eat an elephant: one bite at a time.
Tools amplify your talent. The better your tools, and the better you know how to use them, the more productive you can be.
As Pragmatic Programmers, our base material isn’t wood or iron, it’s knowledge.
HTML, JSON, YAML, and so on are all plain text. So are the majority of the fundamental protocols on the net, such as HTTP, SMTP, IMAP, and so on.
Gain familiarity with the shell, and you’ll find your productivity soaring.
Once you’ve discovered a new, useful feature, you now need to get it installed into your muscle memory, so you can use it without thinking.
concentrate on fixing the problem, not the blame.
Always try to discover the root cause of a problem, not just this particular appearance of it.
So here’s the most important rule of debugging:
Read the Damn Error Message
A very simple but particularly useful technique for finding the cause of a problem is simply to explain it to someone else.
It sounds simple, but in explaining the problem to another person you must explicitly state things that you may take for granted when going through the code yourself.
So, try keeping an engineering daybook. Use paper, not a file or a wiki: there’s something special about the act of writing compared to typing. Give it a month, and see if you’re getting any benefits.
“When everybody actually is out to get you, paranoia is just good thinking.”
