The Pragmatic Programmer [Copyright 2000, Addison Wesley] is a great book and a reliable reference on software engineering that I find myself going back to regularly. The authors, Hunt & Thomas, conclude the book with a List of Tips that summarizes its key ideas https://pragprog.com/the-pragmatic-programmer/extracts/tips.
During a recent* trip to the book, I realized that many of the tips in this list have general counterparts that go beyond software development in being valuable lessons for doing science, in general, and computational science, in particular.
So, I have picked, adapted, and generalized those practical tips here (below). I hope for this to be useful to graduate students, postdocs, & other budding scientists.
You and your science
Care About Your Craft: Why spend your life doing your project(s) unless you care about doing it well?
Think! About Your Work: Turn off the autopilot and take control. Constantly critique and appraise your work.
Remember the Big Picture: Don't get so engrossed in the details that you forget to check what's the goals and impact of your whole project/endeavor.
You and your learning
Invest Regularly in Your Knowledge Portfolio: Make learning a habit.
Critically Analyze What You Read and Hear: Don't be swayed by high-profile papers, media hype, or current dogma. Analyze information in terms of you and your project.
Don't Repeat Yourself: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
Create and Use a Project Glossary: Create and maintain a single source of all the specific terms and vocabulary for a project.
You and your (computational) scientific practice
Explore & Prototype to Fail Fast and Learn: Exploration-and-prototyping is a learning experience. Its value lies not in the code/plots you produce, but in the lessons you learn.
Don't Just Think It – Prove It: Don't wring your hand and speculate. Work a small example that reveals, confirms, or eliminates something.
Estimate to Avoid Surprises: Plan and estimate before you start. You'll spot potential problems up front. Update your plan frequently as you go.
Provide Options, Don't Make Excuses: Instead of excuses, provide options. Don't say it can't be done; explain what can be done.
Fix the Problem, Not the Blame: It doesn't really matter whether the mistake is your fault or someone else's. It's still your problem, and it still needs fixing.
Design to be Continuously Functional and Testable: Write code that is tractable and testable every step along the way instead of once at the end.
Eliminate Effects Between Unrelated Things: Design code and analysis that are self-contained, independent, and have a single, well-defined purpose.
Don't Live with Broken Windows: Fix bad designs, wrong decisions, and poor code when you see them.
Don't Use Wizard Code You Don't Understand: Wizards can generate reams of code. Make sure you understand all of it before you incorporate it into your project.
Don't Think Outside the Box – Find the Box: When faced with an impossible problem, identify the real constraints. Ask yourself: "Does it have to be done this way? Does it have to be done at all?"
Don't Be a Slave to Formal Methods: Don't blindly adopt any technique without putting it into the context of your project and your capabilities.
You and your community
Be a Catalyst for Change: Share with your peers & colleagues about new ideas, concepts, and software, and help in sustained growth.
It's Both What You Say and the Way You Say It: There's no point in having great ideas if you don't communicate them effectively.
Make It Easy to Reuse: If your approaches, methods, and code are easy to reuse, people will, both within and beyond the lab.
* Since this is a post about something I wrote last year, the "recent trip" happened in 2018.
** Image credit: https://www.flickr.com/photos/mistergesl/6110718424
Comments