Just like the title says this week I have read the pattern “Expose Your Ignorance” from “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This pattern describes how any aspiring developer should put aside their ego and be able to tell other about not knowing something and ask questions. It is about being able to admit that we do not know something and to start learning even if it means showing others your “ignorance”.

As always with this book and its chapters this hits close to home when it come to me and my work experience, as well as school in that matter. I found it interesting because it really shows me that it is not only me who can struggle with this particular pattern. My boss always tells me and my teammates during any meeting or code review: “you owe me at least two questions”, and this is the part that is described well in this chapter as well. The author says: “The most obvious way to expose your ignorance is to ask questions.”. I agree wholeheartedly with this statement, we have to be able to ask questions even if it shows our ignorance on the subject, but the sooner something like that is out there the sooner we can work and fixing the problem as well as better working with the team, since they will know that we might need some help.

The only part of this pattern that I do not agree with all the way is the same one I just mentioned. In my opinion there is a place and time to ask questions to expose one’s ignorance, but there are also times when holding them back until later is the right decision. One such time is when working directly with a customer, a particularly tough or difficult one. Or when having a meeting with a lot of higher ups at a company and your development team. Question on the subject are usually good but ignorant questions can have some unforeseen consequences in these situations. Overall, I agree with this pattern and the idea about having a list of things you do not understand and to update it periodically is in my opinion a very good idea.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

“Be the lions tail rather than the foxs head!”

I enjoyed doing the reading. It is protrayed well enough to understand the basic concept of how ones should emerge in the field of computer science.

Three things that I caught attention towards were: learning new skills, taking risks and surronding yourself with people who knows more then you.

There is a say that, hustle like a broke and live like a master.
What I have reviewed is that thinking that you are the weakest member of the team will make you eager to learn and work hard. In order to be the best version of yourself, you have to take risks.
There is no easy way. That is where your patience is tested.
If you fail, you learn, if you didn’t you are always one step closer.

Looking at the Software development companies. They took risks, worked hard and learned from others. That is how they are able to stand out in the Tech world.
To be a good developer you have to collaborate with great developers. It is not their time need it’s the skills that you need to learn. Surrounding yourself and being among them will give you motivation and positive energy to grow into the Software Development field.

This strategy can be applied in any field. maintain and give you the motivation to grow and not give up.

From the blog CS@Worcester – Tech a Talk -Arisha Khan by ajahan22 and used with permission of the author. All other rights reserved by the author.

I have furthered my reading in Chapter 2 of the Apprenticeship Patterns this time about Concrete Skills. With all the romanticism of being an Apprentice and obtaining the ability to learn quickly this chapter really tells the other side of that. It does pay to bring a level of enthusiasm for learning to a team but in order to be hired on a team you need a point of persuasion. This is when concrete skills come into play. Examples described in this chapter are things like a basic knowledge of various industry popular languages, frameworks, and a well developed understanding of your native language. Having these basic, or concrete skills, allow you to show some sort of way that you can benefit a team indirectly with basic tasks before you learn how to directly help.

This chapter addresses something I often think about. Some questions that run through my head, “What are the basic skills I need for getting my first job?”, “Am I expected to know what they are developing and how to contribute, or will they teach me?”. The truth is you can’t know about a development project before you are part of it. How things are done and what the scope is, will have to be learned as you go. Then my first question of what it is I need to know beforehand becomes more clear. My concrete skills need to be further developed, I need to explore more now at this stage in my career. 

I often feel the pull to my familiar skills when presented with a project. I need to use Java because that’s what I know, I need to use this IDE, I need to use this Database. However, it’s interesting as I read this book I see my development toward these goals presented in each chapter. The reading helps solidify my exploration into the unknown. The start of this semester I thought I would only use my most used IDE and the database I was used to using. As the semester got going I began to use a new IDE that seemed to better fit my interests after I took the step to get familiar with it. I also took the chance to learn about a new database application that better fit the needs of the project rather than catering to my familiarity. My next goal is to learn a basic understanding of a few more popular languages.

Developing these concrete skills is just as important as unleashing your enthusiasm for learning. Both are beneficial for a team but concrete skills will give you a practical use upon hiring.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

This week, I’d like to discuss the next step from last week’s apprenticeship pattern. Once you’ve exposed your ignorance to others and realized it yourself, you have to own it and fix it. If others can’t help you, you’re on your own.

This pattern can be used in isolation, without showing others. This is helpful if it’s something very basic which would be embarrassing to admit to, or something you lied about knowing, which is never a good idea. The downside to learning on your own is an isolationist mindset. In a team where everyone is working on their own, this could create a culture where ignorance is frowned upon.

I generally agree with the ideas in this pattern. It is good to keep its downsides in mind, especially since I know I generally prefer to learn on my own. Sometimes, it is simply more efficient. In college, I’ve saved about 2 semesters’ worth of time (and money) by taking CLEP exams, learning the material on my own. For some subjects, it’s simply much more efficient to create my own study guide, find the gaps in my knowledge, and fill them in.

The result of doing so has been much clearer, broader, and more detailed understanding of the subject matter as a whole than I would have otherwise had taking a class. Taking a single exam held me more accountable than a class generally does, which is broken up into smaller assignments with the goal of preparing you for the final exam.

This would never be the case for learning to work on a software team, as we are in our software development capstone. Reading about Agile won’t make you an expert in Agile. Collaboration is a practice.

While not always ideal, I think this pattern can be extrapolated to professional applications. If you’re learning a technology on your own, you don’t know what someone might ask of you. The pressure is on to learn as much as you possibly can. If your goal is to appear as knowledgeable in a subject as possible, this pattern might be the way to go.

The warning against taking this pattern to the extreme is valid in cases of working with a team. It is important to use discretion when choosing between exposing ignorance to others, or confronting it on your own. I plan to lean toward exposing ignorance and asking for help in the future.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

While good testing and version control habits are always helpful and save a lot of time, the process of committing changes, running tests, and deploying the changes can in itself be time consuming. This is especially true in an agile development process, which aims to make small, incremental changes in a series of sprints. Ideally, the process of committing, testing and delivering could be done in a single command.

This is where CI/CD comes in. An Oracle blog post on CI/CD describes the software development pipeline as being a four-step process: commit, build, automated tests, and deploy. CI/CD involves automating this process so that a single commit results in changes deployed to production, so long as the changes can be built and pass the tests. However, any of these stages can be skipped and not all of them have to be automated if it doesn’t make sense to do so. Additionally, other stages can be added if desired.

Oracle stresses the importance of testing in this process, and the requirement to have a suite of unit, integration, and systems tests. These are important to have for any project, but are vital if a commit is automatically deployed to production to make sure users are getting a reliable product.

Gitlab uses Runners to run the jobs defined in a file named “.gitlab-ci.yml”. Jobs can be defined in the stages mentioned above, or any arbitrary number of custom stages, to create a single pipeline. When a commit is made, the pipeline lists the stages and whether they pass. Of course, unit tests should be run before a commit to ensure that the code is behaving as expected, but once a change is committed the rest of pipeline can be automatic.

In large systems, this automation is especially useful. You may be not able to compile an entire code base on a local machine. You may not be working on the same schedule as the rest of your team. Automating other portions of testing and deployment allows a single developer to finish a feature or patch on their own and reliably get it into the hands of users.

In researching software engineering jobs, it seems that many companies use Docker as part of their CI/CD process. Imagine you want to make sure your software runs on Mac and Windows machines. Docker can use predefined images to build isolated containers in which the code can be run. A pipeline can contain separate build stages, for example, to make sure the code builds on both operating systems before running tests and deploying. Next week, I will look at Docker in more detail and describe how it can be applied to software testing.

From the blog CS@Worcester – Inquiries and Queries by ausausdauer and used with permission of the author. All other rights reserved by the author.

SOLID is an acronym for a set of important design principles. Paired together they create a framework for worry free code, and by “worry free” I am speaking of code that would trouble you if any changes needed to be made. In the world today things are constantly changing and being updated and so should your code. If that’s the case then any code you write should have the ability to be edited without causing a complete overhaul of your whole program. Basically what you want to avoid is trickle down effects, and unlike trickle down economics, this is real. If you change one thing or responsibility of a class or variable and that causes a cascade of continuous changes and troubles, then you are experiencing this trickle down effect. To help with this issue is the first design principle in the acronym, Single Responsibility Principle.

Single Responsibility Principle is exactly what it sounds like. Give your classes and methods a sole responsibility so that if they are changed it will only effect that method or classes responsibility. If a class or method handles multiple responsibilities then changing the design of one part may be cause to change the entire entity. 

A crude example would be a Rectangle Class. Let us say you have a constructor to build a rectangle object and all it does is take arguments for height and width. However, you also add if and else statements in the constructor to see if the dimensions make a square and printing a confirmation message if it is. Perhaps you even write “if (myShape.isSquare())..” to send the object to a method to, but this is giving the constructor more than one responsibility. If you decide to change the placement of the square check then there will either be duplicated code or you will have to edit the constructor to pass the isSquare result to other methods. Doing any of this would result is test case changes if you were testing the code. In this scenario it is best to have the constructor just be the constructor and to dedicate the square check to its own method like isSquare. In this case if changes were made then only a single class would require changes and not several that are connected in a convoluted fashion.

I think the Single Responsibility Principle is a must know. I remember beginning coding is CS140 and Data Structures and I would try to get as much done in as few methods as possible by cramming in multiple functions into them. I thought the less methods the better but I was so wrong, it’s worth so much more to have many separate methods and classes that each have a sole function. This way code is organized, easy to arrange, and simple to implement or change.

SOLID Design Principles Explained: The Single Responsibility Principle. (2018, December 17). Retrieved from https://stackify.com/solid-design-principles/

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.