Have you ever been attempting to write an application and struggled to get your data from point a to point b? You already know how the feature should be structured and you’ve maybe even developed multiple variations of the same one many times. But it…. just..won’t…render…on the page! If you haven’t guessed this happens to me quite often. In fact it reminds me of something that happened often before I got into software engineering.
How does that relate you ask? My previous career path involved a mechanical engineering degree and a quite a few jobs with fire protection engineering. It required doing a lot of hydraulic calculation in computer programs to help design building systems. Troubleshooting was needed almost constantly.
The fire sprinkler systems deliver water to the sprinkler heads and there has to be a certain flow and pressure to spray enough water to put out the fire as intended. The software that exists is not the most polished or user friendly. There were only a handful of platforms on the market and they each had their own issues. They had a plethora of common bugs or unnecessarily difficult to navigate challenges in my opinion.
For example, when connecting the pipes in the drawing to flow water from the source to the sprinkler head, the software was incredibly particular with place the ends of the pipe in the exact location on the screen. More simply put, if you clicked the tiniest fraction away from where the program needed you to click the water would not flow in the simulation. If you were designing a giant building and not paying very exact attention it would be likely that you would have multiple instances where the water would not be flowing where you needed it to to prove your calculations.
You might be thinking, why don’t you just be extra careful when placing the pipe? There were so many other possible ways that the program would have strange glitches that would have the same effect. For example if you move a fitting one foot to the right and then move it right back to the left it would randomly not allow water to flow through it. I could name at least a half dozen other strange issues that would unexpectedly cause one issue or another that prevent you from getting the data you needed to submit a complete your engineered product from getting completed and to move forward with construction.
So what does this have to do with software engineering? I could summarize it with 2 words: debugging and troubleshooting. Similar to a console log or binding pry or breakpoints (whatever you want to call them) I learned long ago a pretty good way to approach this. Find a way to inspect the data incrementally along the way. Much like a debugger I would have to move the source as close to the sprinkler head as possible while the water was still flowing to find the nearest issue and fix it. And then continue down the line until the source was simulated at the further point where it needed to be and have the full simulated calculation be accurate.
Software engineering so far has required me to do much the same when my data is not rendering how I expect it to be coming (if at all) from the back end to the front end. Placing console logs or breakpoints in at various points helps to tremendously to see what the data looks like along its course to the end of its pathway. For instance you can see that what you though was a single array is actually a deeply nested array inside of a nested object. Or that the object is actually making it to your if statement but not the nested if statement inside of it. It was one semi-colon you left in the nested if statement. I’ll leave you with this phrase as a bit of joke but also in all seriousness: “Hello, World!”
Top comments (0)