Author: Carter Hawthorne

Theory:

We develop a perfect sprint plan and follow it to the letter. Our project comes together smoothly as we complete each step, and we gently glide across the finish line without a worry.

Reality:

We develop a sprint plan to the best of our abilities, but have to divert as we learn more about the project. Schedules don’t line up perfectly, and some deadlines are quite tight, but we do get there in the end.

So what changed?

“The best laid plans of mice and men often go awry,” as the saying goes. Unfortunately, it is impossible to account for everything, especially in the realms of college education and general life. Sometimes, team members (myself included, of course) have been very busy with other obligations, which has pushed back development of the project. Other times, we have misjudged how complex a particular component would be to implement, which has required deviation from the original plan.

Despite all of this, I feel that our actual project management ability is very good overall. Our plans initial plans weren’t perfect, but we have been able to recognize when we needed to change directions in time to do so. It’s like an intense table tennis match, with the ball (our project) whizzing by unpredictably. All we can do is try to guide it back onto the table and prepare for the next rally.

If I could change anything, I would like to do a little more research beforehand to try and understand the requirements of the project better. This knowledge would hopefully result in a more informed sprint plan that needs less on-the-fly alterations.

Since creating an emulator requires relatively low-level programming, there’s very few technologies required besides one’s choice of language (I haven’t even been using an IDE, just my system’s standard text editor!). In the case of our project, that language is C++, which is a new one for me. I’ve definitely had some difficulties learning it, but I’ve come to appreciate it as a powerful and useful tool.

I am familiar with C++’s parent, the (in?)famous C language. In many ways, these languages are quite similar. A programmer can happily write C-like syntax in a .cpp file and probably get something working. This compatibility makes sense, given C++’s origin as being “C with classes”.

Of course, modern C++ is quite different from its humble beginnings. While I am used to using classes (Java-based introductory programming courses have made sure of that), C++ has plenty of other features that make it unique. There are many “C++-isms” that I was not used to (I’m looking at you, “std::cout<<” syntax), which gave it quite a learning curve. After some time, however, I have come to appreciate what this language can do, and I’m enjoying using it and learning more.

Despite its name, computer “code” should ideally be as readable as possible, and not just by those with the secret key. Naturally, there is plenty of discussion on this subject to be found on the Internet, including plenty of examples of both good and bad practices.

According to the Codacy blog, there are many recommended practices to follow when creating clean, readable code. One of these is adhering to the “single responsibility principle” (SRP), meaning that functions should only do one thing each. This directly relates to The Power of 10 Rules from NASA, which includes a declaration that functions should fit within a single printed page or terminal window. A long function with many responsibilities is not only difficult to understand, but hard to update and debug without affecting other portions of the code.

I have found that it is often easy to get caught up while programming and accidentally create overly complex functions that really should be split into several smaller ones. This impacts my ability to understand and refactor my code, let alone others, so I would like to try and focus on following the SRP more often.

On the flip side of things, there are plenty of code “smells” to avoid. Attila Fejér (via Baeldung) writes about several common groups, including a type of smells called “bloaters”. These are constructs in a program that are too large to be effectively worked with, such as a function or class that goes on for far too many lines (like the issue described above). Fixing this smell often includes grouping together related elements, such as commonly-used pieces of data or functions. In other words, it’s best to refactor your code so that you don’t have to repeat yourself (which happens to be another clean coding practice!). I would like to try and consciously avoid this smell more often, as it affects many different areas within a program, making it a potentially very efficient way to ensure my code stays readable.*

_{*Except, of course, when I’m writing a secret message.}

As I am writing this post, my team is working on the final assignment for our capstone project this quarter. I’m happy to be finishing with my Fall course load, and almost more excited to start again in the Winter. Alongside the capstone, I’ll be working on a personal project under CS 406, which will allow me a lot of freedom (but also responsibility!) to work on something I’m interested in. Most importantly, I’ll get the chance to complete a full program from start to finish entirely by myself; the excitement is certainly at least half nerves (but isn’t that the point, sometimes?).

Winter also brings competitions, making it my peak busy season. Equipment moves, fundraising, out of state meets, and my regular job take up the vast majority of my time outside of school. There’s an old proverb (popularized by The Shining) stating that “All work and no play makes Jack a dull boy”. My coach has a motto that is far more befitting of the collegiate athlete: “Play hard, work harder”. While these have similar messages, I believe the latter properly highlights the importance of both practices, equally. The privilege and thrill of competition is enough to make the rest worth it, but I’ve learned to find the fun in things whenever I get the chance.

In the time since my last post, I have been placed into a project group, and we have gone through several phases of design. Our assignment is to create an emulator for the NES. I believe this was my second choice when I filled out the survey, so I’m pretty excited for the development phase next quarter!

For now, we are tasked with focusing on design, so there hasn’t been any actual programming yet. I expected all of this planning to feel tedious, but it’s honestly been very helpful for my understanding of the project and its requirements. This design phase is forming a strong foundation that my team can build our project upon, and I think I’ll be very grateful for it come Winter quarter.

In the meantime, I’ve been working on finalizing a schedule for the rest of my senior year. I recently switched my major focus from the cybersecurity track to a custom option, which has certainly been a transition. I’m happy to say that I now have a pretty solid plan, which I think is preferable to the path I was on previously.

Regardless of the specific courses I end up taking, I am in a constant state of amazement from the fact that I only have two quarters left of school (after the current one ends, of course). This is the culmination of almost seventeen years of education, or about eighty percent of my lifetime so far. To say I’m excited is an understatement, but it’s bittersweet in many ways. For the first time ever, I won’t be guided by the structure of academia– I’ll have to figure out a career and life for myself.

As is the case for most major life changes, my situation is just as full of hope as it is of uneasiness. A lack of structure also means a world of possibilities; old eras ending lead to new beginnings. I often think about the concept of “senioritis”, the lack of motivation and desire to simply be done with things that can come at the end of the long journey of higher education. While it is tempting to let the waves of time wash over me, I remind myself that I didn’t come this far, to only come this far.

A blog is only as interesting as its author, so I think it’s important that you, whatever audience may be reading this, have some information about the guy on the soapbox. I’ll try and keep things short– consider this a quick greeting, a traditional “hello, world!” from me to you.

My name is Carter, and I currently live in Seattle, Washington. I didn’t get started with programming until high school, where I took some classes and found I really enjoyed the type of problem solving it required. There’s nothing quite as satisfying as figuring out a logical flow or squashing a particularly resilient bug, then watching the code finally run as intended.

My favorite technology by far is anything involving embedded systems. It’s absolutely fascinating how software can be used to make machines do things, using digital instructions to create physical output. I still have a lot to learn (incidentally, my lowest grade so far has been in Computer Architecture and Assembly Language), but I hope to one day work in the robotics industry.

Lastly, I am a competitive gymnast for the Washington Men’s Gymnastics Team. I spend much of my time at practice or volunteering, as we are an entirely self-funded program. Academically, I’m a Beaver, but I will bleed purple until the day I die: