According to music artists, two is better than one. When it comes to designing code that has two parts, this may not be the case. In Max Kanat-Alexander’s article, he explains how he has a personal rule of needing to know how generic his code needs to be. He describes it as if he were designing an audio decoder and started out with supporting WAV files and then later needed to add support for MP3 files. His solution was for what he only needed on its own instead of having to copy and paste the common parts for the format; he emphasizes that “it’s not just two implementations that are bad, but also two locations.” Another rule Kanat-Alexander has for helping this stay consistent is to create code well enough to ensure you would ideally never have to go back and change it if another part of the code has to be modified.
I found this information useful because I believe that developers are always striving to be the most efficient coders they can be. In order to do so, using two of Kanat-Alexander’s methods would help them plan to code more effectively. Just imagine the potential headache of realizing you have to go further back to code you thought was finished and then even further back when you notice a change on top of what you originally needed to make. This will probably affect how I will work in the future as it will make me sit back and think beyond the task at hand. It would allow me to save room for potential add-ons without them crisscrossing, which would allow me to skip out on having to do more rework.
At the end of the article, Kanat-Alexander notes that the reader does not have to take this as a “hard and fast law of the universe” and I appreciate how he tries to help the reader but does not try to push them to do it his way. In terms of the subject, I do not think my thoughts have changed too much as I do want to learn how to code better and I would like to continue finding out about people’s coding structure process.
To kick off this series, I wanted to introduce why Software Quality Assurance (SQA) testing is important not only for testers to understand, but for developers as well. From my experience, I’ve become familiar with manual testing and exploring different types of automated testing for web applications. I wanted to know a little more about how being a good developer also includes being a good tester and found an article on SimpleProgrammer which reveals the importance of knowing how to test.
John Sonmez, the founder of SimpleProgrammer, says that he “owe[s] a large amount of the success [he] ha[s] had in [his] career as a software developer to [his] background in testing.” I can see why he feels that way, as using just a little more time to double-check what you have created could save you even more time in the long-run. For instance, if something you have spent hours working on seems complete and you do not double-check it and pass it on to a QA team, you have to wait for someone in QA or a testing platform to check it. That could take anywhere between minutes to a few days or more. Once it is QA tested, maybe a bug is found and your task falls back into your hands again.
Could the scenario above been preventable? Yes and no. It is a true that “you can never find all the bugs or defects in a piece of [theoretical] software and you can never test every possible input into the [theoretical] software” but you can try your best. This doesn’t necessarily mean having to do your own end-to-end regression testing through the entire software each time you add a minuscule feature but you should thoroughly check what you have changed and the features directly connected to it.
The article continues to describe common testing forms and what they each mean for developers. Sonmez supports the Agile cycle of software development and describes it in the article as well.
Ever wondered what it was like to work for a tech company? Here’s a perspective from an entry-level/intern position at ten24 Digital Solutions!
Hi I’m Sam, a rising senior in uni! Throughout the past ~2 months I’ve been working at a company downtown and brought my camera to work one day to vlog what it’s like.
I truly appreciate how welcoming everyone at ten24 was, it makes it hard for me to believe I’ve only been a part of the team for two months so far! I didn’t even know this was possible but my love for technology grew even more through learning to use different software tools that I wouldn’t have known existed until now.
This is the 1st video of my internship series, feel free to stay tuned for more including ‘what’s in my bag’ and internship advice.
Shout out to Nina for helping me film that ending and eventually climbing into the backseat for a better shot haha!
Side note; working here has it’s perks like being in super-walking distance to city events and local coffee shops, lunch spots, and more!
Until next time, I’ll