I hear this a lot: getting into tech, and specifically software engineering, because of money. It certainly seems to be the case that many people since maybe the 2010s have worked on Computer Science degrees solely because of the income and luxury of it, rather than an actual enjoyment of it.

I always found myself good with technology. When I took my first Computer Science course in high school, I always ended up completing assignments in 10-15 minutes when the allotted time was around two class periods. This is what I’m good at, as far as I can tell, but that’s not necessarily enough for me to make a career off of. If I don’t care about it, then I’m stagnating. If my motivation is simply that I’m good at it, it doesn’t necessarily inspire growth.

These are two examples of unsustainable motivations. The idea is that we can get trapped in the motivations we set up for what we do, and they lock us into a (most of the time, negative) mindset. Instead of enjoying my day to day work, I’ll see it as just work, and want the day to be over as soon as it starts, without actually growing as a person or in my skill level.

While the solution given tries to offer a practical approach (writing down your motivations and how much they factor in to your decision to stay a software developer), I don’t necessarily think this is a strong solution. I’m inclined to say that you have to have a more inquisitive investigation to why you care about this career, and what is really motivating you. Ultimately, you yourself create this motivation, it’s not out there waiting to be found. You can either construct for yourself an enjoyment of the journey, or you can only care about the outcomes.

From this, I would say solely caring about outcomes is unhealthy, and that mindset lends itself to motivations like reputation and money. As such, you have to ultimately figure out how to care about the journey if you actually want to have some level of enjoyment in your career. Otherwise every day genuinely will be a soulless repetition of the last.

There’s a reason why Camus wrote that one must imagine Sisyphus happy. If Sisyphus were to redefine the pushing of that boulder as a journey, and the rolling down of that boulder as a satisfying conclusion and new beginning, then this punishment is not as severe. Of course, this requires a lot of mental effort, but I think it’s necessary to live a life that you can actually be happy with.

From the blog CS@Worcester – V's CompSCi Blog by V and used with permission of the author. All other rights reserved by the author.

As we move onto more code-based testing in class, I wanted to review some of the black box testing techniques we’ve gone over in class, especially since the most recent homework was somewhat confusing for me.

I’ll start off with boundary value testing. According to a blog post on SDET Unicorns, boundary value testing tests valid inputs in the domain (minimum, maximum, and one below and above them respectively), invalid inputs that are close to the domain, and any special inputs, such as empty strings or null pointers. This technique’s main use is testing boundaries, that is, it’s mostly concerned with whether or not invalid inputs are properly dealt with, and valid inputs are processed as valid. The drawback, as we discussed in class, is that it doesn’t really describe the different cases of valid inputs if there is branching taking place.

Equivalence class testing addresses this issue. From the same post above, equivalence class tests (or partitions, in the author’s words) divide inputs into, well, equivalence classes, or groups of input where behavior is expected to be the same. This also means that there are multiple groups of valid inputs, meaning this approach can effectively test different cases of valid inputs based on the specifications, rather than just testing if valid and invalid inputs behave as expected.

The reason why I wanted to look at these two specifically is because they are vital to understanding the decision table-based approach. I’m fairly confident in this approach because I found it fun to work with in class. It’s essentially a visualization and simplification of both boundary value and equivalence class testing, mostly equivalence class testing though, at least in my interpretation. The reason why I find it easier to work with decision tables is because they are much more efficient with regards to the space you use, even if the amount of mental work you have to do is larger.

It’s interesting because I found, in the homework at least, writing out test cases and the like for the non-table based approaches was somewhat frustrating because you have to consider each case even if they do the same thing, and write them out. With decision tables, you can optimize values into ‘dont cares,’ meaning that if the output is solely dependent on one of multiple inputs in this specific equivalence class, so you don’t have to care about what class the other values are. I really enjoy how this cleans up the entire process of black box testing. That being said, I understand that this can become very difficult to test as the complexity of a project increases.

From the blog CS@Worcester – V's CompSCi Blog by V and used with permission of the author. All other rights reserved by the author.

This is one of those patterns that I feels important to apply to everything in your life, honestly. It’s a well-known phenomena that the more you learn in a field, the more you know that you don’t know much. It’s a sort of complicated sentence, but it rings true: You realize the gaps in your knowledge the more you progress. I find it interesting to approach this problem by doing something you know well, but limiting yourself in doing that in order to not stay stuck and comfortable with what you know already. It makes sense as a solution in that you sort of look back and realize all the progress you’ve made, but don’t stay in that mindstate for too long because it will end in the stagnation of your learning.

I personally feel the imposter syndrome very strongly, not just in programming but also in music and other hobbies that I enjoy. I think this pattern would really help with those who, like me, have a tendency to notice the things we don’t know. The one thing is that I don’t necessarily think that this solution is a “one size fits all.”

I usually take breaks when I feel like this, or just brute force through it. The reason I do this is because, in all honesty, I don’t really like assigning myself work that doesn’t need to be done. It feels as though I’m repeating myself if I go back and do something that I already know how to do when it’s not even an important job. Granted, if I were allotted an opportunity where there is work that needs to be done with something I’m very comfortable with, I’m obviously ready and willing to do it, especially in that mindstate.

That being said, if I weren’t so stubborn about spending my time the way I do, I think this would be a great way to ease that sort of dread regarding the possibility that you don’t know very much despite all the time that you’ve spent. I think it’s definitely a good thing to look back at the work you’ve done and say “you know what, I have gotten better over time,” comparing past self to your current self feels a lot better and more productive than comparing yourself to others, because you can actually see where you’ve grown and what that you are, in some sense, competent.

From the blog CS@Worcester – V's CompSCi Blog by V and used with permission of the author. All other rights reserved by the author.

In class, we’ve been going over unit testing utilizing the JUnit Java testing framework. In the process of this, I’ve come across a couple of issues regarding classes that increment a “key” attribute, that is an class where an attribute’s value is based on the amount of previously built instances of that class. When testing to see if the attribute is assigned correctly, it isn’t consistent because of the compiler optimizations that JUnit uses. Tests run in an order which is most efficient, so the number of instances of the class may be different depending on the order the compiler goes through the tests (from what I’ve heard, at least).

I wanted to research a bit more into JUnit’s capabilities to see if I could figure out a solution to this problem, although I’ve already submitted the assignment that is relevant to this predicament. I found this blog post / guide to JUnit from Baeldung that goes through additional features from what I’ve learned in class. Perhaps here I can get some ideas as to address this issue.

What I first found interesting in this guide was the @DisplayName and @Disabled annotations. This is actually incredibly helpful, specifically @Disabled. In the assignment, I found that there were tests that weren’t possible because the functionality was not added to the classes we were working with. As a way to address it, I simply did this:

@Test
void test() {
 // Functionality has not been added!
 assertTrue(true);
}

This obviously isn’t the best approach to testing. With the @Disabled annotation, you can make a much better implementation of this test.

@Disabled
@Test
void test() {
  assertTrue(method());
}

This is a much better way of testing functionality that hasn’t been added yet.

With regards to the previous problem, I had considered having a @BeforeAll method to create a two instances of a class so that I know exactly what the keys for both instances should be (1 and 2). The problem is that if the constructor for the class isn’t set up correctly, this could result in an error. This isn’t that big of a deal for a small program, but I could imagine it’s not really best practice.

However, JUnit has an Assumptions feature. This means that the desired method will only continue if the assumption is true. With this, we could theoretically run an assumption in a @BeforeAll method, and if it passes the assumption, we create instances with keys that are more easily testable.

@BeforeAll
void setUp() {
  assumeNoException(() -> new Obj());
  Obj obj1 = new Obj();
  Obj obj2 = new Obj();
}

This way, we don’t have to worry about the test class not running all the way through due to an exception, and it’s also fairly elegant. Reminds me of why I like to code.

From the blog CS@Worcester – V's CompSCi Blog by V and used with permission of the author. All other rights reserved by the author.

When working with a project that has already been built up to a certain point, one can find themselves lost in where to look first, how to accomplish their job within that project, how the program even works as a whole. I’ve had firsthand experience with this already working with the Thea’s Pantry system. Ultimately, the only way to really learn what is going on in the system is by looking at the code and trying to make sense of it.

This pattern is very important within the context of working in the Software Development field. The quote at the end is a synopsis of it: if a programmer can learn a codebase quickly after being hired, then they can more quickly be productive and add value to the project for the employer they are writing code for. Otherwise, you’re spending a lot of time just trying to get an understanding of things while you have deadlines coming soon.

The one thing is that obviously getting an understanding of a codebase is incredibly difficult depending on your level of knowledge in various languages and programming as a whole. Of course, this is one of the later patterns (chapter 5), but regardless if I don’t have much experience with JavaScript, trying to read a project that operates on JavaScript at a high level will be a bit more difficult than reading a project that uses C given that I have worked with C for a year, let’s say.

There’s also the consideration of documentation. Documentation can be very helpful, but there will always be cases where the code was changed and the documentation was forgotten about. This leads to additional confusion, and it only compounds when there are comments in the actual code that are misleading, or functions that weren’t written with clean code principles in mind. Everyone makes mistakes, and sometimes those mistakes lead to tech debt that has been compounded upon to the point where that bit of code that’s hard to understand cannot be changed without a whole refactor.

Of course, this is dependent on the project. I’m sure that projects like version control systems that were mentioned in the reading are fairly consistent because they need to be, and having the experience of learning a codebase like that is definitely useful and builds on adaptation skills that are somewhat of a necessity in the tech field. It’s an interesting thought, and I can see how it can lead to better code.

From the blog CS@Worcester – V's CompSCi Blog by V and used with permission of the author. All other rights reserved by the author.

Essentially, be willing to admit that you have gaps in your knowledge when you do, and be able to ask those around you for help when you really need it. The authors make a point to mention that this is relatively difficult for many people because of the self-imposed expectation of being omni-competent (that is, always competent) and when you aren’t competent, considering it a failure. This is definitely a difficult mindset to get past, but it is necessary for growth. Otherwise you remain stagnant in the things that you know and never challenge yourself.

This pattern is good. It’s true that in order to learn things, we often have to turn to those who have more experience and learn from them. It also gives a good way of asking productive questions rather than the common (and not very useful at all) “how do I make this work?” I find that in order to really understand what’s going on, you have to go to the root of the thing you’re having an issue with and work up from there. Otherwise, for example, you’re just writing code and you don’t even know what it really does, just that it works. This is one of the main reasons I get bothered whenever anyone has asked me to just show them my code in the past, not only does it not really help them learn anything most of them time, there’s a good chance the code I wrote ends up being copied directly. I don’t really care about getting credit for the stuff I wrote all that much, but it’s moreso about the precedent it sets.

Another interesting thing about this pattern is the idea of being willing to step out of your comfort zone to other fields and technology to better your versatiliy. I think this is truly important, especially when working in the tech sphere. Things change very quickly, and to not adapt means to remain with legacy components which are less efficient and less secure as a whole. This stagnation spreads to everything in the ‘system’ so to speak, and the results affect everyone who holds a stake in what your group does.

From the blog CS@Worcester – V's CompSCi Blog by V and used with permission of the author. All other rights reserved by the author.