All technical workers need to be expert at their tools. Pilots go to flight school, carpenters may even build their own tools.

When studying optics, Newton learned to create his own lenses. Here is an image from newton’s notebook on grinding lenses.

https://cudl.lib.cam.ac.uk/view/MS-ADD-04000/56

All languages have many things in common. Learning how they are implemented gives you insight into how other languages works.

https://spectrum.ieee.html/the-top-programming-languages-2023

• Need to learn why the tools are useful to be effective
• Don’t just use a tool b/c you think it will magically make you do a better job
• Modify your tools! We’ll use open-source, configurable tools in this class

The command-line opens you up to the full power of the operating system.

You can download and run many more applications that lack a GUI.

You can perform powerful automation, for instance, in our lab we script experiments so that others can replicate for themselves our results.

The Linux kernel is over 20 million lines of code, has thousands of developers and maintainers and is used in billions of devices.

You can develop for it, including submitting patches, entirely on the command-line, and many do.

Among other things, allows you to build up sophisticated automation from simple tools. There are tons of tools, many of which are standard, that you have access to on a *nix system that make it so you don’t have to reinvent the wheel.

Examples:

• Terminal file browser: ranger ~/Documents/teaching/cop3402/sum2026
• Terminal web browser: lynx https://www.cs.ucf.edu/~pappas/teaching/cop3402/fal2026/introduction.html
• Terminal coffee shop: ssh terminal.shop

If you are doing software development, you will almost certainly be using version control.

Version control not only makes large-scale collaboration on a single codebase possible, but it helps you as an individual organize your code, debug, focus, and more.

Find out where and what your files actually are.

Many students go through the CS curriculum without a basic understanding of hierarchical file systems.

Modern graphical OSes hide much of it for convenience. But nearly all devices have some sort of file system.

The hierarchical file system was designed by people (you can see an explanation in the reading for next time), so don’t take for granted everyone just knows how it works. You need to learn it.

• Working with the file abstraction
• Manipulating the file system
• Reading/writing files

• Creating processes
• Executing programs
• Manipulating I/O

• Working with language processors
• Generating machine code
• Interoperating with existing machine code standards

Learning systems software helps you understand how:

• Programming languages are implemented.
• The programming environment works.
• Programming theory makes programming easier.

• The hare starts coding immediately.
  • After all, finishing the coding is done, so the faster we write code, the faster we finish.
• The hare finishes coding before the tortoise even starts.
• But now the real work begins….
• The hare runs a large test given by the professor.
• It breaks the program of course.
• The hare starts guessing and changing code that might be broken.
• But now another test is breaking.
• Fixing that bug breaks the first test.
• If the hare is lucky, all given tests work eventually.
• But the hare is surprised at a bad grade, because new tests written for grading also break.

• The tortoise starts with comments, planning, and tests before even a single line of code gets written.
• The tortoise divides the problem down into simpler pieces.
• The tortoise writes some simple examples to illustrate the problem.
• The tortoise takes an easy piece of the problem and writes comments about what the code should do.
• Only then does the tortoise code, little by little, testing along the way.
• The tortoise makes sure simple things work properly before moving on.
• The tortoise doesn’t take for granted that the code just works.
• The tortoise knows debugging is really hard, especially when there are lots of bugs together.
• This is what the hare found out the hard way when new fixes broke old tests.

The tortoise took way longer to get a line of code written. But when they got there, the code was much easier to write and write correctly.

While the hare felt like they were “coding” fast, the tortoise was calmly - writing tests - writing comments on what he was doing, and - writing a few lines of carefully-thought-through code at a time.

When the tortoise runs all the tests from the professor, they almost all work. For the ones that don’t, the tortoise just isolates the problem with a minimized test.

The tortoise’s code is well-commented, simple, and organized, so they have no issue finding and fixing problems in their code.

The tortoise obtains good grade, because even unseen tests are likely to work.

To be clear there are absolutely times to be the hare. Hacking a simple Bash script, getting something done fast, writing a small or inconsequential program. But to solve really hard problems, to write correct code, you need to be the tortoise.

Being the tortoise can also save lives; for instance, consider these cases where programming bug caused fatalities:

• 2025 Boeing plane crash
• Therac-25 radiation therapy machine glitch

• Don’t “guess” about how something works.
• Develop fast workflows.
• Develop good debugging skills: minimize the test, identify the bug’s location, understand the reason for the bug before trying a fix (just like good coding practices in the first place!)
• Do not overwrite old test files!

We’ll have many opportunities to practice these principles during this class.

What do you think?

The program almost always does exactly what you wrote it to do.

Don’t start hacking code! First understand the problem.

Once you see the discrepancy between actual code behavior and what you want the code to do, the fix will likely be readily apparent (at least in this class’s projects).

Diagram: Specification -> Programmer -> Implementation - (Green highlight entire spec, green highlight part of implementation, but mostly red.) - If I try to tackle the whole problem at once, my program is always wrong until I’ve finished coding the entire specification.

• Think back to what Brian Kernighan said about debugging.

• Start with a “Hello, World!” program.
• Take a top-down approach to programming, not a bottom-up one.
• Be “constructively lazy.”

Diagram: Specification -> Programmer -> Implementation - (Divide and green highlight part of spec, divide and green highlight part of impl; then take one more piece of spec, green highlight corresponding impl, with a small part being red) - But if I divide up the specification, I can focus on getting a simpler, smaller (sub)program done, making debugging easier and it more likely to be correct once I move onto to another part of the specification.

Debugging is made simpler, since there are fewer (likely) things that could be wrong

Instead of using cognitive energy to keep the whole program in your head and debug the whole program each time there is an issue, use cognitive energy to break the problem down into simpler parts and reason about how to combine them correctly.

Within each phase, try to break the problem down further yourself, and make each piece work on its own, then work with other pieces gradually.

Biggest takeaways: - Real definition of what a bug is - Revisit your code - Refactor to match specifications (usually easier to refactor than starting from scratch). - Take time to make good interfaces. - Less stressful if breaking down the problem first.

Original link.