39  Conclusion

Looking back

If you’ve made it here, whether by reading straight through or by landing on a dozen chapters over a semester, you’ve seen most of the hidden curriculum laid out in the open. We started with the human side of technical work: asking questions someone can answer, reading and writing documentation, debugging one change at a time, and reading a traceback from the bottom up. We walked down to your computing environment, from your operating system and file system to the terminal, your editor, and machines on the other end of an SSH connection. We untangled Python’s packages and environments, notebooks and scripts. We cleaned, checked, queried, and fetched data, and we covered the scholarly writing, talks, and LaTeX that turn that work into something other people read. Then we zoomed out to projects and teams, with Git, code review, automation, and secrets kept out of your code, and finished with the AI tools that now sit inside nearly all of it: how to use them, how they work, and how to check what they tell you.

That’s a lot. Nobody learns it all at once, and nobody is expected to.

Key takeaways

  • Hidden skills matter. The practices that live between the lines of a syllabus, like organizing files, pinning dependencies, writing a README, or filing an issue, often decide whether a project succeeds. A little time spent learning them pays off for years.

  • See before you act. Most of the disasters in this book, from a deleted folder to a doubled merge, start with acting on an assumption. Check where you are, which Python is running, and what’s really in the file before you change anything.

  • Check before you trust. A file that opens without an error isn’t necessarily right, and neither is a confident answer from a search result or an AI assistant. A few lines of checks, a quick look at the official docs, or a small experiment costs minutes; a week of wrong results costs a week.

  • Make work legible. A reproducible environment, a clear folder layout, descriptive names, small commits, and a written record of your decisions make it easier for other people, and for future you, to understand and build on your work.

  • Automate, then verify. Turn the steps you repeat into scripts, make targets, or scheduled jobs, and let continuous integration and pre-commit hooks catch mistakes before they spread. Automation saves time only when you can tell it did the right thing.

  • Collaboration is a skill. Good teamwork isn’t luck. It comes from shared documents, small pull requests, reviews that help instead of sting, and decisions written down where everyone can find them, so the project’s memory outlives any one person’s.

  • Tools have politics. Every default, format, and platform makes some things easy and others hard, for some people more than others. Asking what a tool does besides its job is part of doing the job well.

  • Stay curious, and stay humble. No one knows everything. Ask early, read the docs, experiment somewhere safe, and share what you learn. The computing community runs on people who write down their mistakes so the next person doesn’t have to repeat them.

Continuing your journey

These skills aren’t a checklist you finish; they’re habits you keep. The tools will change, and some of the commands in this book will look old in a few years, but the principles last: organize your work so it has a place, make your steps explicit and repeatable, and keep the people you work with in the loop.

When you’re ready for more, a few directions follow naturally from here. Containers, which Chapter 15 introduces, package nearly a whole environment so a project runs the same way anywhere; Docker’s getting started guide is a friendly first step. Testing, which Chapter 6 starts, grows into full test suites with tools like pytest. Infrastructure as code applies the same version-and-automate habits to servers and cloud resources. For more of the hidden curriculum, The Carpentries publish free, open lessons on many of these skills and run hands-on workshops, MIT’s Missing Semester goes deeper on the shell, editors, and Git, and Good Enough Practices in Scientific Computing is a practical paper worth rereading at the start of every project.

And remember that every frustration you work through today becomes experience you can share tomorrow. If a chapter here tripped you up, left something out, or has a command that didn’t work for you, tell us: every chapter page has a Report an issue link, and the book’s contributing guide shows how to suggest a fix yourself, right in your browser. The next student to open that chapter will be glad you did.

Acknowledgements

We’re grateful to the students and instructors whose questions and feedback shaped this handbook, and to the open-source communities and educators whose documentation and tutorials we learned from along the way.