In this stage of the Apprenticeship patterns, it gives us an overall idea of what it’s like to be an apprentice. In terms of learning different programming languages, especially if its a new language, it will be hard to learn it because you have prior knowledge on the concepts of basic programming actions. According to the Apprenticeship patterns, “we have to be able to put aside our past experiences and preconceptions to allow new knowledge in. This is especially difficult when trying to learn your second programming language, because it is likely the first time that you have to sacrifice productivity in order to improve your skills.” When you think you are knowledgeable in programming languages, you are unable to take in the maximum depth of learning you are expected to take in as well as limit the ability to discover new possibilities.  To put this in the modern work place, team members will always have a certain level of competency in the work that they do. Pride will be one of the factors that may be an obstruction to the team unless each of them are able to allow themselves to unlearn what they learn in order to learn new things in case problems should arise in the future.

What I found interesting about this pattern was how the metaphor “white belt” was used.

“Wearing the white belt is based on the realization that while the black belt knows the way, the white belt has no choice but to learn the way.”

In my mind, I thought it made sense because as a true beginner, you know nothing at all to start off. To be taught at first, it is normal to think that the first way you learn would be the right way. At that point you allow yourself to learn, and therefore, you are able to discover possibilities you hadn’t known.

This Apprenticeship pattern was useful because it made me think of when I first learned my second programming language, which was Java. When I transitioned from C++, I thought learning Java wouldn’t be as hard as I thought it would. It ended up being harder because I wasn’t allowing myself to learn the full principles and rules of the language. I took shortcuts when I wasn’t suppose to, and I had to learn that the hard way as I struggled through learning it. Soon after, I took it step by step and allowed myself to learn it the right way.  I completely agree with this pattern because not only it applies to programming, but it can apply to anything you learn in life, and it starts by wearing that “white belt” first.

From the blog CS@Worcester – Ricky Phan by Ricky Phan CS Worcester and used with permission of the author. All other rights reserved by the author.

The authors began this chapter with a really thought-provoking story of a Zen master and a young philosopher. In this story, the young philosopher sets out to learn the ways of the Zen master but every time the zen master would begin to describe his own practices the young philosopher would cut him short and start talking about how he does things and how it might relate. Essentially, the Zen master is never able to complete any of his thoughts because the young philosopher keeps interrupting and talking about his own experiences. This goes on for a while until the Zen master goes to pour a glass of tea and he keeps pouring until the the cup is overflowing. at this point, the young philosopher tells the zen master to stop pouring to which the zen master replies, “If you come to me with a cup that is already full, how can you expect me to give you something to drink?”

I think that the short story about the Zen master and the philosopher is extremely relatable to learning how to become a software developer. In the field of programming its’s really important to approach problems with an open mind and to not disregard certain techniques or practices due to the fact that they aren’t familiar to you. By emptying your ‘mental’ cup and being upon to new ideas you will inevitably be much more successful in developing and honing down your programming abilities.

The authors go on to describe the best way to get your software development career started. They suggest that you choose one specific programming language and “become fluent in it.” Some of the things they proposed to get help get you started are using that programming language to build a “toy” application, trying to solve real problems using that language, and reading the language’s specification documentation. The authors recommend using tools like git to publish and/or contribute to open source projects. The benefits of contributing to open source projects include the fact that you can get feedback on your code and advice from experienced professionals that already know the language your learning. Overall, I’d have to say that they present some really good advice on how to get your programming career started and I wish that I had read this when I was starting out as it probably would have saved me a lot of headaches.

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

Unleashing your enthusiasm focuses on bringing enthusiasm to your new team.  It emphasizes approaching your new team with energy and readiness to learn as much as possible.  The book explains that a lot of new developers may be hesitant to appear too enthusiastic, thinking that the team that they are integrating into might not be welcoming to the new injection of enthusiasm into their work place.  Enthusiasm is infectious though and in just a short period your enthusiasm to work and learn will spread to the other team members and the overall work environment will rise.  I agree that this works not only in software development, but in any industry.  During my time in the Army there were plenty of days that were miserable at best.  No matter what the condition was though if you had a positive energy and enthusiasm it made the day a little easier.  When one person showed up with this type of attitude they were quickly berated and rejected by those who were determined to stay miserable.  Soon enough though the positive attitude spread to others and everyone had seemingly found what little good and joy there was to find that day.  Work then seemed easier and the day moved quicker.  No one could tell you any specific time or event that the change occurred.  The tone of the team just kind of changed as the enthusiasm spread.  I think that a high morale and enthusiasm for the job will greatly improve the overall morale and performance of the team.  I found the study from the aircraft carrier interesting.  The idea that new employees mixed with seasoned vets of the industry makes sense, but is often overlooked until it is brought up.  The vets share their experience with the new employees while the new employees are able to share the newer ways of teaching and question the way things have been done in order to change procedures if necessary.  When the employee is in the middle of these two extremes is where changes are made and new procedures and policies replace the old.  It’s important to for all to remember that this process doesn’t work without a mutual respect and open mindedness towards all.

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

The White Belt pattern arises out of an issue I’ve encountered — I’ve learned one language fairly well and have some practice with others that follow similar paradigms, but have found it to be more challenging to learn new things.  Tools, skills, and languages that are different from what I know don’t come as naturally as it seems they should.

This apprenticeship pattern seeks to solve that problem through a mindstate and a more practical approach.  It teaches the mindset of a willingness to feel like a beginner again, to fail and maybe look foolish in order to adopt a childlike ability to absorb knowledge.  More practically, it suggests a learning strategy: adapt a simple, known software project from one language to another, using the paradigms of the new language to their fullest rather than trying to write “Fortran in any language”.

As I said before, I have notice that I struggle more and more to acquire new skills.  Whether that’s environment setup, picking up new languages, or adapting to a different set of tools it seems to get harder as I learn more.  That doesn’t bode well for my mental plasticity, and this pattern provides a useful solution.

The most useful aspect of the pattern, for me, are what the authors calls the mindset of not knowing.  Of willingness to ask questions, start from the beginning (whether that’s following tutorials that feel beneath me, or finding help elsewhere).  Of taking a harder road to learn things right and come up with a better and more nuanced solution rather than patching together something that’s familiar and comforting.  This speaks to something I learned in a high school gym class: we learn and grow the best and most successfully just a bit outside of our comfort zones.  I need to push myself into the “learning zone”.

The action advice is also something that I can take away and use moving forward.  While I don’t have a lot of time now, I am interested in refactoring old projects into new languages as a learning exercise, to blend something that I know well already with something brand-new.

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

http://www.codesimplicity.com/post/kindness-and-code/#more-1673

This week, I read this blog post titled “kindness and code” authored by Max Kanat-Alexander on his blog, Code Simplicity. The post is about the toxicity of the software development community and Alexander is trying to help improve it by explaining the importance of kindness and treating fellow developers with respect. I chose this post to write about because I am interested in improving the typical harshness people tend to deliver to each other on the internet. As somebody who plays a lot of remarkably toxic video games such as league of legends or call of duty, its easy to see how that type of bad behavior can also exist in software development. In fact, you can find horrible behavior common in any field regarding random community communication on the internet.

I believe people tend to lash out over the internet more often than in real life. This is because they are mostly anonymous and care less about good manners or reputation when it involves somebody they may not ever meet again. This allows somebody who is given any slight reason to judge you, the justification to barrage you with hate. This type of behavior is pointless as Alexander writes “There is no value to being cruel to other people in the development community” as it seems like an instinctual reaction for some people to point out anothers flaw just to make them feel bad about it. Take an example of any normal person trying to learn something new for the first time, either with a video game or in software development, and they make a mistake. If another person online is able to see their mistake, they might be aggravated by it enough to insult and verbally abuse the poor person who is just trying to learn.

Usually this occurs when somebody more experienced looks down on a newer person however, not necessarily. As the internet matures like an older brother, more and more experienced people are picking up the habit of lending healthy advice down towards the still learning user, and that is what Max’s blog is about. Coming from an experienced point of view, he offers techniques of constructive criticism to the software development community in hopes that they will help each other rather than judge each other. While today it is common sense to simply ignore and accept the inevitability of horrible comments on the internet, it is becoming more of a growing trend that not everybody on the internet has something hurtful to say. That means progress! Even though it is difficult to imagine an internet without any angry anonymous trolls waiting to insult your every move, I believe the internet community is getting better and better every day.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

This is another video from Joel Spolsky. I found this video through the last blog entry from last week. In this video he talks about the impact of coding in everyday life. He uses a taxi as an example of how coders deal with coding. he mentions if the person tries to make the taxi turn right, instead of the taxi turning right, it might have the trunk pop open or the taxi turn in the opposite direction. The driver will ask what’s wrong and try to figure out the problem. The driver will go online and find another driver had the same problem asked the question then was given the answer.  The driver could use the answer to solve his problem. Before stack overflow, there was a site online where programmers post questions to a coding issue, then would have to pay the company money to see their own answers that they have written up, Stack overflow was created where programmers can write questions to the program they have a problem on and other programmers can answer. Those answers are rated by other programmers who use the site. Those ratings can help a programmer build their reputation as a programmer. This could possible lead to jobs as a programmer in the future. Programmers need every detail of instruction for the program to run properly. Like mentioned before, algorithms are used in software design to run programs on websites. These algorithms allow a site to post certain pictures, articles and other posts, based on what the user is searching for or their feelings towards a certain topic or event.

The video was interesting. Joel uses everyday trends such as Uber and Facebook to explain how coding works in general and how it is used in everyday life now. I picked this video because I really liked the last video, and video was similar to the last one. The last video talked about programming and coding effecting the future of people. This video talked about coding impacting everyday life of today. This gave me a better  idea of how a website work and how a program runs. Again this shows me what expect in the workforce of a programmer. Joel compared the early days of programmers working similar to working at an assembly line. Programmers were hired to create a program write it and run it, and doing it in small cubicles with computers that did not work properly. Now a days programmers work with he company on the spot to make sure the program runs properly and fix and problem as they arise. This gave me a better understanding on how algorithms work on a site and how to use them for when I create a site and run it.

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

In a post by Yegor Bugayenko, Single Statement Unit Tests,

“..I believe, can help us make our tests, and our production code, more object-oriented. Here it is: a test method must contain nothing but a single assert.”

He makes use of the assertThat() that is available from Hamcrest. Benefits to using assertThat() are: Reusability. Classes needed to create test assertions are reusable in other test methods and test cases. Brevity. Shorter and readable code that’s easy to understand. Readability. Using a single assert, the intent of the test will always be apparent. Immutability. No need for setters or getters if we limit use of algorithmic code in tests.

He uses and example method RandomStreamTest from OpenJDK 8, created by Brian Goetz:

@Test
public void testIntStream() {
final long seed = System.currentTimeMillis();
final Random r1 = new Random(seed);
final int[] a = new int[SIZE];
for (int i=0; i < SIZE; i++) { a[i] = r1.nextInt(); } final Random r2 = new Random(seed); final int[] b = r2.ints().limit(SIZE).toArray(); assertEquals(a, b); }

In this example there are two parts, the algorithm which creates two arrays of integers and the assertion which compares them using assertEquals(). The author recommends modifying the code to look like this:

@Test
public void testIntStream() {
final long seed = System.currentTimeMillis();
assertEquals(
new ArrayFromRandom(
new Random(seed)
).toArray(SIZE),
new Random(seed).ints().limit(SIZE).toArray()
);
}
private static class ArrayFromRandom {
private final Random random;
ArrayFromRandom(Random r) {
this.random = r;
}
int[] toArray(int s) {
final int[] a = new int[s];
for (int i=0; i < s; i++) { a[i] = this.random.nextInt(); } return a; } }

The change is the test is that there is only one statement in the method now.

Yegor notes

"The biggest benefit we get when this principle is applied to our tests is that they become declarative and object-oriented, instead of being algorithmic, imperative, and procedural."

I chose this resource because it's an interesting way to design tests and the benefits of using assertThat() might be of use to me in the future. I think it is important to keep up on the best unit-testing practices if I want to write good code to match. I'm also interested in looking more into Hamcrest.

Using assertThat() allows you to write relatively short test cases that are clear what is being tested. Sometimes tests can become bogged down with too many assertEquals() and setters and getters. Using assertThat() allows you to simply compare two immutable objects. I plan on using this, or at least trying to implement it whenever writing tests in the future along with whatever makes writing tests more readable, understable and object oriented.

The post Single Statement Unit Tests: Making tests more object oriented appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.