I’ve been thinking a lot during week 2 about similarities between building big electromechanical devices and big software projects. The former is something I’ve done for over 10 years and I feel pretty good about. I’m getting “dramatically better” with the latter and here are some things I’m noticing:
- Test early and often: It’s so much easier to write the smallest viable software change and then test it prior to moving on to the next.
- Think top to bottom and bottom to top: Systems engineering is a critical phase of building a mechanical project where functions are decomposed from “the big picture”, common interfaces are defined, and test plans are made. On the other hand, you have to “swallow the elephant one bite at at time” and think about how to build in small components that come together to make something larger. This week I worked on a project, making an interactive sudoku board, and I only worried about building a single square of the board first. That was a good starting point, but later on I kept having to revisit code to get that square to be part of a larger board and game system. If I had spent a little time at the beginning thinking “top to bottom” too I may have had to rewrite less code.
- Everything you think will be a problem will be a problem: This is one of my favorite mantras to teach early career mechanical engineers. I’m realizing the same thing happens in software. Every state bug, every memory issue, every render loop will probably happen and you need to actively Not make it happen. “I hope this works” is never a good plan.
- Make it so complex, the complexity hides the deficiencies: Ok don’t actually do this. But I heard it being thrown around RC this week and it definitely conjured one or two past mechanical projects I’ve worked on.
It makes sense most of these things are universal to projects of any type. When you have to build something bigger than what one person can fit into their brain, you have to take a structured approach. One of my goals at RC is to build something that big in order to learn some of these philosophies. And maybe it’s not a matter of learning them, but seeing how the philosophies I already know apply to software!