Ask HN: What's a mnemonic or concept that's helped your engineering career?
What are some mental models, mnemonic or memory tricks that you've developed to help you through your software engineering career/journey? I'll start first:
When I'm working in javaScript and trying to figure out whether to use `for...in` vs `for...of` I think about this trick I found and modified (https://maximorlov.com/forof-vs-forin-memory-trick). The author uses UFOs (unidentified flying objects) but I use foreign objects for mine. If I'm looping over objects, I say they are foreign objects so I grab the `for...in` loop for objects. That means the only thing left is `for...of` for arrays.
This other one is less of a mnemonic and more of a concept that was like an "ah-ha" moment in my software engineering career. (I can't remember if I came up with it or read/heard it somewhere so I apologize for not being able to give credit if credit is due.) A large percentage of apps that we create as software engineers are mostly glorified forms and/or spreadsheet. You are submitting some data to a database. We are then outputting that data in some UI. That means everything we do - from design all the way to DevOps - is to support or "dress up" a form and/or a spreadsheet of data. It helped make things a little less daunting for me.
Curious what other's may have conjured up. The "ABC Principle". Always Analyse (A) the problem first, only then start Building (B). Finally, don't move onto the next thing until you have Checked (C) that whatever you've built matches up with your analysis. Applies to more than engineering as well. Interfaces are like Legos The concept of a n-dimensional “room” helps inform how much testing is “enough” Everything in software is an abstraction for another concept Could you expand on the first two please? Legos interact with each other in a very well-defined manner. The circular interlocking portions must be manufactured to a tolerance of 10 micrometers so that the bricks lock as expected, but can be removed easily. In a good interface (e.g. an API), the parameters passed around can be defined and characterized precisely, perhaps using input validation and strong typing. The designer of an interface should know and handle all the permutations of data in and data out. If a surface-level function can't handle negative values, then the designer must know how the function will respond. Back to Legos. despite their extraordinarily tight specifications, there is practically nothing that can't be built with Legos, in the precisely-defined Lego universe. Six 2x4 bricks fit together in 915,103,765 ways. It's unlikely any particular design decision by Lego enabled this, but it's almost like they built a Turing-complete construction language. Similarly, good interfaces shouldn't unreasonably constrain the user. Finally, and this may be stretching the analogy, Legos interfaces sort of act like a "black box". One can attach a Lego to any interface of an existing Lego project without concern for what color the bricks are, how many bricks are connected, even the types of all the other bricks involved. The interface is all that matters. Likewise, a good interface doesn't require the user to dig into the source code to understand how to use the surface level connections. Reference: https://en.wikipedia.org/wiki/Lego Separate reply for the n-dimensional testing space: This goes back to the scientific method and hypothesis-testing. When conducting experiments in school, we learned to have only one independent variable at a time, and measure its singular effect on the dependent variable. It's possible to test more variables at once - it's just hard to visualize, more time-consuming, and more difficult to plot nicely in a school report. Using an idea from statistics called Design of Experiments, one can change two variables at once, creating a 3-dimensional space with a 3-dimensional functions. Anyway, what's this have to do with programming? A program is effectively a transformation of inputs into outputs. It's easier to think about this for an individual function fun (a int, b int) -> int { ...stuff... } There are a few ways to test this function. The first is think really hard about common inputs, and make sure the outputs are correct. The next level is to figure out all the edge cases and test those as well. At that point, that function would be considered reasonably well-tested. But why is that? Why doesn't 100% test coverage mean someone tested EVERY SINGLE POSSIBLE INPUT? Because that style of testing has produced a series of points of data through which a 2d curve can be traced through the 3d test space (because there are 2 independent variables (a and b) and the dependent output). As a result, one can interpolate any value within that curve and know what the output is. This example is clearly very simplified, but the concept can be extrapolated to functions with more complicated inputs and entire programs. Reference: https://en.wikipedia.org/wiki/Design_of_experiments