Category Archives: Week 4

Apprenticeship Pattern – The Long Road

The apprenticeship pattern “The Long Road” is a pattern for those aspiring to become master software craftsmen. For these people, the path that should be taken differs from what is expected from them. Rather than trying to climb the wealth ladder by taking every promotion you can get and enter a less programming-oriented role, you should continue walking on “The Long Road” by focusing on learning and long-term growth.

This pattern is really interesting because it’s a path that focuses entirely on honing your craft rather than salary. I’m sure most people would jump at every opportunity that offered them more money, regardless of what the job actually entailed, so long as they considered it a “step up.” This is a different, legitimate path to take, but it won’t necessarily be the same path as the one to master software craftsmanship. It’s entirely possible that in the long term, focusing on learning and long-term growth would get you “further” down the path of mastering software craftsmanship.

I’m still not entirely sure if it’s the path that I want to take, as it’s difficult to pass up short-term gains. It’s easy to say that you want to walk the long road, but when facing a fork in the road it may be hard to continue. Although, I’ve heard many stories of people who took a higher paying job only to end up regretting it due to lack of growth, poor work-life balance, boring work, etc. That being said, I don’t think that I’ve experienced the industry enough to decide what path to walk. So it’s difficult to say whether I agree or disagree with the pattern, but focusing on improving yourself would likely not lead you down the wrong path.

Imagining strange roles that you could be in 10, 20, 30, or 40 years from now and what you did to end up at those points is an interesting exercise that I think would help people figure out what they want to do in life. Obviously it’s not necessarily guaranteed that you would have a breakthrough from just thinking about it, but you might realize that you don’t like the path that you’re on right now or maybe your dream role has an entirely different starting point from where you are now.

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

B4: Create Feedback Loops

          The “Create Feedback Loops” pattern is seen as a way to gain a better understanding of yourself without completely suffering from a blind sense of skill. The book continues on to say that self-assessment is limited to the abilities you have which makes it narrow minded if you don’t have many skills to start with. The best way to cope with this issue is to create a system where you can receive feedback or external data on your performance. It allows a more conscious take on your weak points as seen by other people which in turn will create a much more detailed self-assessment for yourself. The book then shows the importance of feedback in various environments such as job applications where applicants can be turned down, but this can become a learning experience as well. Understanding why one was turned down for a job also is a type of feedback that can show you different aspects of your character that you didn’t see. Finding a specific task to do is the hardest part because you must find something you can measure. Once this is done, compare how that task is affected by your work and understand how your actions are affecting it.

          I found the idea of creating different feedback loops with various people very useful and interesting. The idea of getting feedback from multiple people in multiple groups of your life could be very valuable information. I personally feel that there are aspects of work that meld into our personal lives and until someone else points them out, they seem second nature to us. This idea of taking others advice even when its not work related can cause interesting changes in how you tackle problems and view the situation. I found that listening to these valuable inputs is important but it’s just as important to understand which advice to follow as not all of them are good. I disagree with the idea that self-assessment is only limited to someone’s abilities. I think that even when you have little skill, you can accurately create an ideal image of what you want using facilities like the internet to expand on what you need to work on.

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

Concrete Skills

This week’s blog is about Concrete Skills from the Apprenticeship Patterns book. It talks about what to do when you are looking for a role on a talented team that will provide you with better practice and enhances your learning, but sometimes these teams do not want to be bothered. Sometimes, having a new hire means you are going to be teaching them again from the beginning and these new hires do not offer anything to the company or team yet since they do not know how things work. This section of the book talks about how to deal with it.

In this section, they talked about concrete skills. They said that it is important to have some concrete skills so that you will be trusted to contribute indirectly until you start to gain their trust. It will help reassure your team members that you can be put to good use rather than being a burden that they have to babysit. They added skills like writing build files in various languages, basic web design, JavaScript, and knowing some standard libraries in the language of choice.

I find it interesting that the book suggests that you look at the CVs of the people whose skills you respect and identify the skills noted on the CV and determine which of these skills would be useful on the team that you want to join. Implement these skills on your own project, make sure that you know how to do them and how they work.

I completely agree with this pattern. I think knowing some concrete skills will come a long way when looking for a job or when starting one. You can’t always rely on your team to teach you stuff and they can’t also just ask you to do things that you have never done before right away since they are also working on stuff and not just there to babysit you. They will expect you to work and you have to prove to them that you are capable of being on the team. That’s why I think having concrete skills is good.

 

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

The White Belt

The white belt as an apprenticeship pattern is what it sounds like. You are at the beginning of your journey and have a deep understanding of your first language. The problem arises when you are struggling to learn new material and it is harder to piece things together than when you started learning your first programming language. The author relates the solution back to Star Wars quoting Yoda, “You must unlearn what you have learned”. By doing so, this accelerates the learning process because you don’t try to relate things back to your current language but instead connect neurons together when trying to understand the new concepts you are learning.

I agree with the many things the author taught in this apprenticeship pattern. That too is how I learn new tools and technologies on my own but on the other hand, I always try to relate it back to my strongest, most knowledgeable language, and see if there are similar concepts and if there are ways to carry out a task more efficiently.

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.

“A Different Road”

This post is connected to my previous post, “The Long Road”. What happen if we were following our dream road, the road we versioned in long-term. But there a limited subset of all possible career paths. You don’t know if this road is longer fit you. You are looking for a path of your own. There are many difficult come with change a path, you are putting your career and your future on new line. But you also don’t know your limit of possibilities.

“A Different Road”, when the road that you draw is leads you away from the main road. You found the new opportunity with new reward, something that you are attract to. But this mean you have to take a turn away from your craft. There is also all the worry of life responsibility, specially family. This will make our choose much more difficult. In this pattern, they suggest despite this risk, don’t be afraid to do something different with your life. I am agreed with taking change and do with what you love. But the situations are different with everyone. It is hard to tell them what to do.

We will have this situation to our life, the people to support around us also are the big factor. We surround by people with different opinions. It is important to listen to who truly support us and with different point of view. They able to help us to feel confident to take that step. The true supporter is the one who stay with you no matter what and will tell you their honest opinions. Although I always thinking about this subject. This pattern tells from another point of views, talk to people with different job. Ask them what they love about it and compare that to the things you love about software development. Go with whatever you see yourself in.

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

Apprenticeship Patterns: Kindred Spirits

This week I read through Kindred Spirits from Chapter 2. This pattern is reflects on the stage of life of an apprentice who feels like they might not fit in entirely well with a company’s culture, perhaps because they have different interests or a different level of enthusiasm. Perhaps your organization is not very tight-knit and you’d prefer it to be. The solution is to make sure you reach out to meet those who are like you, and that you actively stay involved in what those people are doing. Read books, remember names, and attend meet-ups. Even getting coffee from time to time and discussing ideas can help immensely when your work life isn’t feeling satisfactory. You may even find yourself in a spot where you are offered a position to work alongside those kindred spirits who are just like you.

I found this pattern pretty interesting because, due to graduation coming up, I personally have been pretty concerned about finding a work environment that I really enjoy — as I’m sure everyone is from time to time. I know that I’m someone who seeks to get involved in the places I spend my time, and that if I join a company it is important to me that I’m not coming into work, getting things done, and then leaving. I want to find coworkers that I connect with, work that I can get invested in, and people who are enthusiastic and encouraging. From what I’ve heard and from what the chapter suggests, organizations that a truly encouraging are often few and far between. It may not even be the entire company, it could just be that those you who associate with on a day to day basis are not quite as enthusiastic about your work as you are. As a result, I really enjoyed the tips that this pattern suggested. Make sure you remember those who are similar to you and who have shared goals in mind, and that you keep those people as close as possible.

It’s important to keep track of who you meet, who inspires you, who knows what you know and is passionate about what you’re passionate about. Make lists of communities and try to get involved in them. One thing I’d like to do personally is to attend some software conferences — I know there are plenty and I know many are not outrageously expensive, so it’d be a really great way to meet people and make connections. It’s important to keep those you you mesh well with close to you, as those people will provide you with opportunity and friendship like no others.

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

Why Doctors Hate Their Computers Response

A lot of the times in the office, people can get easily frustrated with their tech. This article talks about how there seems to be some sort of disconnect between the technologies and the doctors. To start off, when a software is developed for a certain field, there are certain expectations and requirements that should be met depending on what the service is for. if you are delivering a software for a food business, you should expect it to handle some sort of client interaction along with employee interaction. This also can translate to mass scales where more and more people are using it. When a lot of people are using the same software, there should be a type of initiative to make it simple yet effective to use. If the software that is being developed for a specific purpose isn’t developed correctly or with those things in mind, it can sometimes be detrimental to that business’s practices. In this case, it was a matter of updating a lot of records and technology to keep the systems “relevant”.

In the case of a hospital system, the records are computerized and the new system that was being put in place would be able to handle a lot more. This is the reason why the upgrade was good. The new system would be able to deliver a single platform for recording and communicating medical observations, sending prescriptions to a patient’s pharmacy, ordering tests and scans, viewing results, scheduling surgery, and sending insurance bills. However, with these new systems seem to come a lot of overhead for the people using it. There were quite a few tensions that actually made it more difficult for doctors to get their jobs done. One of these tensions was between the doctors and administrative staff. Often times they disagree on what should and should not be included in the software. Sometimes the staff said adding certain procedures would be more time consuming. Certain fields that doctors didn’t have to fill out before were now being required due to administration simply telling them that they had to be done.

I feel as though the real customer in this situation seems to be the administration. Whenever a new system is implanted, hospitals often have to schedule less appointments just to accommodate for training of the new system. This puts, not only the patients, but doctors and other faculty way behind. From the article, it states that in the first five weeks of a new 1.6 billion dollar system upgrade, there were about twenty-seven thousand help desk tickets were just simple how to questions about the system. The lessons from this implementation don’t only apply to the Electronic Medical Records systems, but other systems dealing with these same mass software upgrades for facilities similar to hospitals. This reading has changed the way I think about the topic because although upgrading something to make it current, doesn’t always necessarily mean it won’t add additional overhead. I agree with the fact that upgrading systems can be important, especially when dealing with thousands of medical records because you want to keep things secure. But at the same time it is important to understand that there should be more efficient ways of training with these software to make them more accessible and understandable for the people using them.

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.

Mapping it Out

The next apprenticeship pattern I took on was Draw Your Own Map. The premise is simple: you are the only person who can choose the paths you go down and which roads you travel. You should not leave yourself to the mercy of your situation and those around you to determine the course your future will take. Is is a definitely a pattern of self-determination.

The Draw Your Own Map pattern is absolutely useful. I have always been a person who has difficulty relying on others. Although I acknowledge this as a weakness in most ways, one way it has strengthened me is I usually don’t find myself depending on others for approval or assistance. If I want to do something with my life, or make some future plans, the only person I ask is myself. This independence and selfishness is important, in my opinion. There is only every going to be one person looking out for your best interests: you, and so therefore it is your sole responsibility to map out your future and make the decisions that will lead to your happiness.

Despite this, I do think there are limits to the pattern, even when applied to careers. For example, although your position in a company might not be immediately satisfying, with time there is potential to move throughout the company to a position that is better for your skills and abilities. There are some paths you can only get to by travelling on a bumpy, gravel road first. It’s not optimistic, or ideal, but the text definitely glossed over these potential scenarios where you prioritize long term gains over short term happiness.

Overall, Draw Your Own Map is not an interesting or a surprising apprenticeship pattern, but it is a hugely useful one and one I feel I’ve already been using to make college-related decisions for a long time anyways. Basically, only you can make the choices that will lead your life to happiness, nobody else will do it for it. Just as long as you are making ethical choices that don’t tread on anybody else’s map.

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.

Given-When-Then

GivenWhenThen

Blogger Martin Fowler in his self titled blog describes a template for organizing unit tests, called “Given, When, Then”. This concept is perhaps a rephrasing of what we discussed in class, the four phase test, or “Setup, Exercise, Verify, (teardown)”. The idea is to structure our test cases in a logical, easy to understand process.

Fowler describes the idea as “essential to breaking down writing a scenario (or test) into three sections”. Given a specification, any situation we need to test for can be broken down into these three steps. The first section is “given”, or the “setup”. During this phase of the test, we would create variables and set up the preconditions to a test. Fowler uses a scenario of trading stock to illustrate his point. “Given” a certain amount of stock to invest (precondition) move on to the next phase.

The next step in the model is the “when” phase. During this phase of testing, we are choosing the behavior of a function to be tested. In Fowler’s stock trading example, this translates to “Given: x amount of stock to sell- When: I want to sell y stock”.  This phase essentially defines the behavior of the test we are writing.

Last but not least, the “then” phase is all about putting the first two cases together and verifying them. Following Fowler’s stock example, the “then” phase is represented as “Given: x amount of stock to sell – When: I want to sell y stock – Then: I should have x-y stock”. This phase is where you verify the expected behavior to the actual behavior of the program.

Personally I find this model particularly helpful, in the sense that it provides a useful narrative for breaking down testing situations. To me the “given-when-then” model seems more intuitive than “arrange, act, assert” or “Setup, exercise, verify”. While all three models definitely describe the same process, I think that this model is the most clear. In any case, breaking down test scenarios into discrete parts like this is integral to creating clear, easy to understand tests.

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

Mutation Testing

Greetings reader!

The nature of this blog is to give a short summary over a topic that is essential in the Computer Science field: Mutation Testing. This blog will share my analysis of Tutorial’sPoint’s: Simply Easy Learning- Mutation Testing Tutorial.  I will be expressing my reaction to the content by sharing what I find useful and interesting and displaying if I have any concerns or disagreements. Without any further introduction, let’s begin.

First, let’s start with defining what mutation testing is. Mutation testing is a testing technique that uses the structure of the code to conduct the testing process. It is simply the rewriting of code in small ways in order to take out the excessiveness in the code. This wordiness may cause failures in the software if it is not altered. It is very sneaky because it can pass through the testing process’ unnoticed.

There are three types of mutation testing: value, decision, and statement mutations. Value mutations are efforts to change the values to display errors in the programs. The change of the value is usually to either a very large value or a very small value. It is found that the most common strategy to combat this is to change the constants. Decision mutations are when the code is changed to check for errors in the design. Ways to fix these errors are by changing the arithmetic operators to find the failures or by altering the relational and logical operators. Statement mutations are when changes are done to the statements by deleting or rewriting the line.

Mutation testing is based on two theorems. The first is the competent programmer theorem. This theorem explains that most software errors made by experienced programmers are due to small syntax errors. The second theory is called the coupling effect. The coupling effect says that simple errors can couple to form other faults.

All in all, mutation testing is a fairly simple technique that is used when testing code. Sometimes errors or faults can be hidden when making tests that will cause the source code to fail. Mutation testing is the process of altering these subtle errors in efforts to run the code.  This topic is extremely important to this field because it gives us a deeper understanding of our errors, which helps greatly when correcting “bad” code.

Source: Tutorial’sPoint’s: Simply Easy Learning- Mutation Testing Tutorial

 

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