Draw Your Own Map is a pattern that discusses how you must forge your own path in terms of your career and not let yourself be boxed in by your employer. This pattern is relevant for everybody who wishes to advance their career as there is only a limited set of career paths that any employer can offer. It is not up to anybody but yourself to decide what the next step in your career should be. When you figure out you want your next step to be, you should visualize the smaller steps that you need to take to get there. Taking the first step will help propel you to achieve your goals. If you discover that your vision for your future is not compatible with your current employer, you should start looking for other opportunities. Draw Your Own Map is all about not getting stuck in one place that doesn’t provide for career advancement.

I think that this is a very useful pattern to follow. It is common for people to grow comfortable in a certain role which makes them unwilling to look for other opportunities. It is also unlikely that any company will provide you the exact path that you want your career to follow. It’s important to remember that your employer is not invested in you advancing the exact way you want to. Even though you may work for a particular company for a long period of time and feel like you should have some level of loyalty, it is better to examine other opportunities when your company’s ideas for you are not aligning with your own. This is the only way to truly draw your own map.

I thought that the two example stories given were interesting to read through. Reading real life examples helps to drive home the point of the pattern and shows that this type of thing is not uncommon. It was also interesting to learn about two actual career paths that have been taken by people in the industry. Overall I think that this pattern is applicable to everybody and is important to remember for people beginning their careers.

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

The White Belt Pattern, as defined by Dave Hoover and Adewale Oshineye, is an apprenticeship pattern with the goal to learn new concepts or information. The way the pattern achieves this is by having the user abandon their previous knowledge and conceptions regarding the topic, and look at the topic from a fresh perspective with a willingness to learn, despite the potential difficulty and inefficiency of doing so. This comes in handy if you are trying to learn a new programming language or if you need to solve a problem using a new or unfamiliar algorithm.

I definitely can recognize times in my life where use of the white belt pattern would have been helpful. Often times when I’m working on a puzzling programming challenge, I try to think of it in terms of challenges I’ve had before and previous problems I’ve overcome. If I can apply a previous solution to this problem, wouldn’t that be the best way to do it? While I personally do still think this kind of thinking can be useful in reminding yourself of your steps to reaching a previous solution, it can also be distracting and push your mind in the wrong direction. Sometimes the best way to solve a problem is to approach it from a totally new angle and abandon anything you think you know about how to solve it. Some times it’s the knowledge you think is helping you that is actually getting in the way.

I can absolutely see me reminding myself of this pattern and its intentions in the future. If I find myself overthinking something, or trying to shoehorn a solution to a problem that doesn’t fit, I will try to forget what I know and open my mind up to new solutions and ways of doing things. Even outside of programming, freeing up some of my preconceptions on the ways I think things work could be very healthy. It’s important not to let our accumulated knowledge cloud our judgement and prevent us from learning even more. After all, if our goal is to learn, we should approach it from the most practical way possible.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

When you ask a group of developers what is more important, writing adaptable code or writing tests for the code to pass? I believe that both are equally as important as the other. I came across a blog by Tobias Goeschel, “Writing better tests with JUnit”, where he talks about the importance of writing better tests. In order to keep your code as high quality as possible, you must write tests. Poorly written tests as he describes may lead to bugs bypassing your code and having malfunctions in your program. As he lists in his blog, a set of well written tests will tell you (and more):

• How to access the API
• What data is supposed to go in/out
• What possible variations of an expected behavior exist
• The exceptions that might occur
• How parts of the system interact with others

Tobias goes on and talks about how good tests should not be underestimated because it not only helps new team members understand what should be done but also reviewing old code that’s to be tampered with.

Reading through this article it all makes sense why we were always so test driven with the projects that we did in Data Structures. Every project we wrote had to pass a certain amount of pre-written tests. The author stressed the importance of unit testing which changes the way I will write in the future. Not only will I focus on written code but also tests. I believe that Unit Testing is equally important as mentioned.

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

https://www.360logica.com/blog/difference-between-static-testing-and-dynamic-testing/

            While trying to gain more information on Static and Dynamic Testing, I found an interesting blog post that pit the two against each other. It started by explaining that Static Testing is used to test things related to the actual code within a product. The post further says that Static testing is where developers check code to find faults. This testing can be completed without any current applications. The post then defines Dynamic Testing as testing the application with valid entries and checking their outcomes against an expected result. After explaining the two terms, it stated the major differences between them like how Static testing is a preventative measure while dynamic testing is used in solutions. The post explains that Static testing is therefore more cost-effective and provide greater benefits when compared to Dynamic testing. Dynamic testing can take longer as it tests each case separately while Static testing can cover more in a shorter amount of time. The blog post goes on to explain that since Static testing is done in a verification stage, the code can be looked at without any execution. This differs from the Dynamic testing which is done in a validation stage where the code is executed and tested without being looked at.

            I chose this article because I found myself interested in the difference between Static and Dynamic Testing. I understood these terms in a programming sense, but I didn’t quite grasp the concept in a testing setting. My initial curiosity was filled with a sense of what these different testing types meant. I found the post very informative on what each testing type did and how they worked. I can understand that Static testing is better overall because of its speed and benefits but I also understood how Dynamic testing works as well. I enjoyed how the post used multiple examples when explaining these terms because it allowed me to get a better understanding as to the context of the definition. This blog post has taught me that Static testing is the go to style for testing as it is cost-effective and overall better. The most interesting part about this post was the different benefits it stated between Static and Dynamic testing as it gave a better insight to how they both worked.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

While sifting through blogs trying to determine which might be a good read, there was one in particular that caught my eye. We all know as developers we love to start new side projects and never see it to completion am I right? Well that’s true in my case anyway. As I read through Joel Spolsky’s article, “Developers’ side projects”, I learned some fascinating news that I shall keep in mind for the near future.

In the opening paragraph Joel talks about some kind of proprietary invention agreement that most developers sign when working for an employer. Basically what this agreement states is that whatever the developer comes up with or invents while employed by said company will belong to said company. Yes that may seem silly but to the company it is very profitable. Say you are the employer and one of your developers create an app that gets 1 billion users over night. You would want the rights to this app to maximize all profits. Smart.

This article was very interesting because it opens your eyes as a young developer waiting to join the real world. Never did I ever think that once I would be employed as a developer that a company MAY have the rights to the work that I do in my spare time. Spolsky talks about legality issues that might come about if you were to create a product while employed under a company and what could happen if you try to branch away to form your own competitive company. He then states that the only way for independence is to be independent.

Many questions come to mind after reading this article. Should I be afraid to create content once employed? Does every employer attempt to own the rights to every employees’ work? For one, I do agree that there is ease of mind working independently but sometimes that’s not always the best case. Moving forward I will make sure to read contracts thoroughly before I sign anything!

Don’t forget to share and follow

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

This article is very interesting in that it offers a new perspective on the importance of a front-end user perspective first type of testing scheme. It starts off by explaining to us the normal pyramid testing scheme and how at the tip of the pyramid is where the user perspective and UI is. This article is contrary to all of those other testing pyramids because, by how this article explains it, the top of the pyramid is just as, if not MORE important than the lower levels. Typically in a Test Automation Pyramid you have Unit or unit tests at the bottom (long base), then you have your service tests (integration, component, and api tests: middle slice), and finally at the top you have your user interface and ideally what the user sees. Knowing that, this article explains how the pyramid should actually be flipped upside-down, having the user perspective be of larger importance. You would still have your unit tests and integration on the bottom and middle, it just wouldn’t be as large. This is the point the article is trying to make, “Just as a triangle has more area in its lower part than its upper part, so you should make more automated tests on lower levels than higher levels.” This is not an argument; this is not reasoning. Nothing in the nature of a triangle tells us how it relates to technology problems. It’s simply a shape that matches an assertion that the authors wanted to make. It’s semiotics with weak semantics.” Pretty much, the article is saying that the shape of the triangle in which these schemes are based on don’t really carry that much weight into technological problems.

My reaction to this article is that I agree with what they are describing here. Similarly to the article, I also think that when you have a project, each layer above the next can often be a lot more complex than compared to the lower levels. This in turn can also even carry a higher risk. The model the author is talking about is the Round Earth model. The round Earth model states that you should think of technology as concentric spheres and that each layer can increase dramatically. This article made me open my eyes and made a lot more sense of how certain models don’t really understand what they even stand for.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.