Although we’re supposed to write about one pattern per blog post, I couldn’t help but feel that these two patterns are interlinked with one another. Exposing your ignorance and confronting your ignorance goes hand in hand with one another, and I believe that it is difficult to write about one while excluding the other. These two stuck out to me because it is something that I have recognized in myself.

While in the process of looking and applying for jobs, I realized that though I have many good traits as a programmer (hopefully), I am also lacking in a lot of things as well! I noticed that my knowledge of algorithms was much lower than I would like, and in pursuit of growth, I started to ask my friends for advice and help. I was exposing my ignorance to those around me in hopes of getting better, and though it was honestly a bit worrisome since I didn’t want others to think less of my abilities, I knew that it was the right thing to do. Like described, there is a balance to exposing and confronting your ignorance. If you simply expose your ignorance without any attempt to confront it, it leads to only helplessness and you become a burden, while if you don’t expose your ignorance and try to confront it, it leads to situations where you might hoard knowledge and create a culture of only success despite failure being essential to the learning process.

In my case, because of my exposing of my ignorance, I was pointed towards various resources that would help me up my algorithm design. For one, I think most people know about leetcode, but I also learned about Code Signals! These two are very similar, but I much prefer Code Signals as it feels a lot less intimidating to start with. It does not have as big of a wealth of different problems as leetcode, but in my opinion, it is much nicer to start with.

Then of course, with these resources now known to me, I started to confront my ignorance! I start to work on my faults through these websites, and though I still think that I am rather lacking, I know that I am a bit further down the road than I was before. I highly recommend anyone who might feel their skills are bit lacking to do something similar to me! At worst, you keep your skills honed and at best, you learn so much more than you could possibly expect! I know I did!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Through a bit of coincidence a friend and I were having a discussion on version control and how we went about naming our versions a few days ago, and I say coincidence, because it seems like we’ll also be working on Semantic Versioning sometime along the line in class.

Being the person that I am, I made my own rules without being influenced by anyone else. For me, I simply though that

Well… It’s my code, right? That means I can name things however I want, right? So if I said this is version 0.9, then it’s version 0.9! Or if this is version 2.0, then it’s 2.0!

In response, my friend informed me of a few soft rules, since he was more familiar with versioning through an internship opportunity than I was, and he shed some light on a few details. Like how versioning is not just a made up number that you assign to your project/code. Hearing this, I was honestly pretty confused, but I looked into it and discovered Semantic Versioning!

And wow, did that blow me away. Looking back at the way I approached things, I was no different from a headless chicken running around! Learning about Semantic Versioning, through this video, it is both so straightforward but also so useful. No longer will I have my versions be numbered willy-nilly, nor will I even forget my own versions and what happened in this update! It’ll finally make sense!

To break down Semantic Versioning, consider versions as three parts!

The Major version, so think 1.0.0
The Minor version, such as 0.1.0
And finally, patches, like so 0.0.1

Major versions are, well, major! These are versions that leap forward and have large changes! Making a major version usually implies that the code is changed in such a way that it will no longer work with older versions. These changes might be large architectural changes, or other large scale changes that usually break the existing structures or APIs.

Minor versions are NOT as massive (duh), but they come with plenty of other things compared to, say, patches! Minor versions could be added features, or updates to existing features, and most of the time, nothing should break. Functionality that existing before should still work, and further development of new features shouldn’t impact or break anything either (ideally).

Patches are like bandages! These are where the bug fixes are! If something is broken in an unintended way, that’s when patches come in, and they should be used to iron out problems that were not accounted for. It could be something minor like the output of some code is a 2 instead of a 1, or it could be a bit more major like a whole portion of the code crashes when run, but patches are for fixes!

As an example, I’ll run through a brief bit of versioning on a made up project! Let’s say… I’m making a program to print out a leaderboard. It connects to an online library to gather scores, and then displays it to whoever connects to it.

After long and grueling work, I did it! I finally completed it and so, I release…
Version 1.0.0
It’s done and completed, but then… It turns out, my leaderboard only prints out the WORST scores! Dang it, I flipped the list around by mistake! So off I go, fixing this bug. After everything is working again, my next version should be 1.0.1.
But then… I think to myself, wouldn’t it be cool if I added region support too? Then we could see where this score is from, and potentially even group regions by high scores!
So, after adding this new feature, my next version will be 1.1.0!
Pretty straightforward, right? It’s really clear what is going on too!
Let’s say another bug is introduce, bam, 1.1.1!
Then more features, 1.2.0
And finally another bug is squashed! 1.2.1
And… another bug ! 1.2.2
But… then wait, there’s another bug. 1.2.3
Things feel good and everything works, but I learn about a whole new library that does what I want it to do, and gives me more room for growth. So rework the whole program with this new library! The old stuff still works, but since I’m switching to a whole new system, this version will no longer work with the old one, and now, this is when I jump a major version.
We’re now on version 2.0.0!

I hope that example made sense! There is more to semantic versioning as well, but that is the quick break down. Introducing things like alpha/beta and also ^ and ~ adds some other intricacies, but for now… Let’s not think about them! Alphas/betas are optional for testing purposes, and to be honest, ^ and ~ are a bit out of my grasp. I don’t fully understand them yet! I’ll look into them more, and maybe I’ll have a future update post detailing what I’ve discovered!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to benderson’s blog! This week we are discussing a different pattern that is found in the book Apprentice Pattern called “Confront Your Ignorance”. Confront your ignorance talks about identifying gaps in your skillset that is relevant and will affect your everyday work. The book talks about a common problem with most people trying to master computer science and that is where to start. There is so much in computer science that you don’t know where to begin, you got to decide on a language to learn, what to program, etc. There are too many pathways just to choose one. The solution though is to pick one skill/technique that will help you actively fill the gaps in your knowledge, and you can do this in many ways as well, some suggestions that book has is to look at overviews or FAQs of different computer science topics. Either you eventually master it, or you get good enough in the skill and you move onto other gaps that you need to fill. To find the gaps in your skillset, you need to do another pattern known as “Expose Your Ignorance” which confronting your ignorance attacks.

Confronting your ignorance is a challenge of mine as I want to be proficient in other programming languages other than java, but I don’t know which one to choose half the time. I have tried python and a little C but I always get caught up in something else and never finish learning all the ins and outs of the languages. I feel like I’m familiar with all my ignorance’s, so I’m passed the exposing my ignorance’s phase and I just need to confront them. As I have said before, I’m worried about getting into my first job and not being able to work efficiently enough so getting experience and filling my gaps is something that I need to do to gain more confidence. I probably will start learning another programming language soon that most workplaces use just so I’m ready to use the language right when I get into the job. Eventually though, I will do my best to fill all by gaps and get the job I need to succeed. Thank you for joining us this week on benderson’s blog, make sure to comeback next week for more patterns.

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

Hello and welcome back to Benderson’s blog! This week’s blog will focus on the documentation and formatting you would use for testing software. I found a blog that talked about the right format for documentation and formatting by Chris Kenst. At the beginning of his blog, he talks about how you know what is the appropriate documentation for a test and says it will depend on the degree on the test technique and approach you use. He talks about a couple different techniques in a short sentence but in the end says cramming all of them into one system isn’t really a good idea. The next paragraph talks about how much you need for documentation which he sums up with a small amount because you need to focus more on the project itself than the documentation that you put in there. The time it would take to make all the documentation for the test, you would run out of time for the test and documentation it self. The next and final paragraph focuses on stay agile, “Focusing on the appropriate documentation for your tests and then creating the smallest amount you need to do your job well also allows you to have agility”, this sentence from the blog sums up the whole paragraph really well.

This blog was very informational on the topic of test documentation and formatting and how much you should focus on it. I haven’t really been big on documentation in my four years in college as I always find it as an additional thing that I really don’t have to do but over the years, I’ve began to realize how important it is to have in your code. My reasoning usually is that I know what each of those methods do so it doesn’t need to be documented and formatted but I realized that in the actual work world I will have other people reading my blogs and they won’t know exactly what each method does unless I document it. So going back to this blog, getting all the information I need to know how much I should document and how I should format is very helpful for not only me but my future colleagues who will have to read my code. Knowing exactly what you’re testing is probably a pretty good thing to know. Also, knowing some tidbits such as focus more on the testing than the actual documentation and write a small amount so you have time, will help me make sure I get the tests done and have a good amount of documentation.

Link: https://www.kenst.com/2018/09/appropriate-test-documentation-formatting/

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