For today’s blog I will be writing about the Concrete Skills chapter in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The problem that is summed up perfectly in the context section of the chapter, which is summarized as the fact that you have knowledge does not necessarily mean you are knowledgeable. This meaning that your knowledge can be useless without the real-life implementations and skills. But how does one obtain these skills and practice since we are only college students who have never had a “real-world” experience in information technology.

The problem presented in the book is this: you are looking to join a team but do not have the experience desired. The team may not want to hire you at all because the risk of you not being able to contribute or you messing up and or breaking stuff is far too high. So what is the workaround for this? The book says to use your time wisely and to obtain some concrete skills. Not necessarily always software development related, even just some sort of skills such as social interaction and networking. This is important because it does not take a lot of knowledge to do these actions and they can make you seem much more invested in the team and marketable to other companies that are hiring. What needs to be done is to bridge the gap with the hiring managers because honestly they know you have little to no experience and they will have to take blind faith in you, hoping that you pull your weight on the team. But if nobody hires you because of your lack of experience, how exactly are you supposed to get experience to get a job? Practice gaining concrete skills, social skills, networking skills, any skills that do not require coding knowledge that will make hiring managers warm up to you more, and therefore more willing to take that leap of faith in hiring you. I relate directly to this chapter because this is where I currently find myself in life. I have been applying for full time jobs while finishing my last semester of college. Trying to “bridge the gap” to make a seamless transition from school to work is hard. Many employers see you’re still in school and flat our reject your application, and some will humor you with an interview but are very reserved because after all you still do not have a bachelor’s yet. After reading this chapter I feel more confident in my job searching and I will continue to search and apply for jobs.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Far too often you see individuals seeking a shortcut to something they want whether it be wealth, fame, the perfect body, learning, skills, etc. the list goes on.

The Long Road discusses the problem of you wanting to become a master software craftsman and accept each pay raise but leave behind the long term growth opportunities; sure accepting a higher paying position would be nice but the author tells us why sometimes it is better to focus on your long term journey and the abilities you will unlock if you take your time and not take shortcuts. He discusses the amount of knowledge and appreciate software development much more over time. This pattern is not targeted towards individuals that are aspiring to become CIOs or project managers; more towards those who are passionate about software development and being crafty.

One action that was suggested: “Close your eyes and imagine yourself in 10, 20, 30 and 40 years time.” What experiences do you as an apprentice desire? For me, many came to mind. I am expected to graduate in a few months and when I picture myself a year from now it is to be working as a software developer in a structured company learning and absorbing as much as possible but I do disagree the part where I would not want to move up positions. My goal is to start off as a junior developer and over the years move up to a senior developer and maybe one day just a project manager whose goal is to help the team when necessary. I believe even if you are no longer considered as a developer, your thirst for knowledge will continue. This pattern helps me realize that my journey is just beginning and it will be a very long road to look forward to and I can’t be any more excited for it to start!

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.

In the third chapter “Walking the Long Road”, Dave have a bunch of certificates from his education. Then he starts connect to broader developer, he discover that he had barely scratched the surface of what it meant to be a great software developer. He inspired by the power of these hackers’ abilities. He threw himself into side projects and began to read anything he could get his hands on. The more Dave learned, the more he recognized how far he had to go. This is what I image I will be going though once I get into the work force. I am looking for the motivation to learn and see great things.

Speaking of work force, this is what everyone facing once they are doing job for money. We aspire to become a master software craftsman, yet your aspiration conflicts with what people expect from you. Conventional wisdom tells you to take the highest-paying job and the first promotion you can get your hands on, to stop programming and get onto more important work rather than slowly building up your skills. Everyone have their own road, that why we can not follow the successes step by step. I do believe the shorter road you take, the sooner it will be end road. I am agreeing with imagine my own long-term road. What step we are going to take, what experiences we want to try. We don’t want in the future to look back and wish we could take different road. This is always conflict between job and money, they are connected but also affect each other negatively. We are doing what we love but we also want to be successful. On our road of career, sometimes money and promotion could get you turn to different road. Maybe the road that you weren’t to take, this is difficult decision we will face at some point. I agreed with the chapter, no matter which road are we will take. Make sure that’s the road for long term and keep doing what we love.

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.

Consider yourself in the situation where you’ve joined a company, spent some time there, and learned quite a bit. You’ve climbed the craftsmanship ladder and others recognize your work as that of high quality, maybe even some of the best amongst the developers you work alongside. Your hard work has paid off and you’re a legitimately good developer. This is exactly what the pattern Be the Worst from Chapter 4 focuses on.

The problem with reaching this status is that you’re may likely find yourself at the pinnacle of growth in your work environment. Everyone turns to you for learning opportunities, and you’ve definitively established yourself as a leader in your workspace. However, you’ve found yourself unable to absorb information from your professional environment like you used to. Your rate of learning has stalled, and you’re no longer finding yourself continually developing and expanding your skillset.

The solution is something we’ve all heard before — surround yourself with those more skilled than you. Do so constantly. When you find yourself feeling like your learning has stalled, it may be time to locate another team whose skills outmatch your own (or at least, are in some kind of different field that you have lesser experience with.) Not only this, but keeping yourself in the ‘bottom-tier’ of your coworkers will “unlock” other patterns, which will help you keep yourself in the apprenticeship mindset. This is key because it ensures that, if you’re motivated, you’ll have continuous growth. Now, don’t get this pattern confused — Your goal is not to stay the worst on your team. It is to climb the rungs of the ladder until you’re an absolute coding machine, equipped with a host of skills that you’ve picked up from the time you’ve spent chasing craftsmanship. Then, once you’re at the top of the ladder, find another to climb all over again. Eventually, you’ll find yourself to be a developer skilled enough to guide others through the same process.

What action can you take to push yourself towards this goal? I may have been implying that it’s wise to up and leave every group that is slowing you down, but that’s not entirely what I meant. There’s no reason to forgo professional relationships in the search of career development if you’re happy where you work. Instead, search for elite teams across the world (via the internet) who you can be a part of. Get involved in more communities, different projects, etc. Staying in communities seeking growth will encourage you to do the same.

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

Have you ever heard of the Single Responsibility Principle? What does it sound like when it comes to mind? To me it kind of sounds like an object is tasked to do one thing.

In Jon Reid’s “Single responsibility Principle: Is it a fundamental mistake?”, he talks about the different problems that arises when applying the SRP. He starts off explaining that in order to apply the principle, we must keep subdividing until the class cannot be subdivided any further. That task sounds like a nightmare right? It gets worse. He goes on talking about classes and an important concept called “Cohesion”. Simply put, cohesion expresses how closely related parts of your code are with one another. For example the more each method uses the same instance variable the more cohesive the class is therefore that class must be narrowed down according to Reid. There is a such thing however as extracting too much from classes but he doesn’t really go into detail describing when you know you’ve narrowed down too far he only states you’ll know when you’re there which doesn’t help much.

I thought this blog was sort of confusing because he didn’t go into detail about how to not make the mistake about breaking down your code too far; I guess he just wants us to learn through trial and error which makes sense over time. I don’t think I will try to change my way of coding because the way he described SRP kind of made me want to sway away from the idea. There just seems to be too much room for error in my opinion. Yes I agree it is good to narrow down your code but you do run into the problems he 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://blog.codeship.com/behavior-driven-development/

          This week, I found a blog post that talked about Behavior-Driven Development and explains how to implement it within Computer Science. The post begins by defining behavior as the way the user wants the application to behave. It explains that you must have a clear idea on the user needs for this implementation to be successful. The implementation of this is done by dividing the user needs into small stories which have selected keywords to help define the behaviors of the application. The post uses examples very well to explain these ideas by highlighting and explaining important phrases. The selected keywords are used to put the stories into a more “readable” format while also creating behaviors based on the user needs. The post gives some advice after this, saying that the most important behavior to the user is the best starting point for these stories. Then you just keep building off that idea to encompass a final product that you can show to a client to make sure that all needed scenarios are covered.

            I chose this article because I was curious as to what Behavior-Driven Development entailed within the computer science world. I had no idea what this term was before reading this article, but I have gained a much better understanding now. I found this content enlightening in the sense that it taught me to think a bit differently. I enjoyed how the post explained the importance and implementation of this development through the use of these stories. I found this way of understanding user needs very helpful and a fresh new perspective compared to other things I’ve tried. I was able to understand how the development process works by starting at the user needs first. This will affect my development process by allowing me the option of working with the user to create better specifications. The most interesting part of this blog was the overall explanations for the development process. It was intriguing and informative while teaching the purpose of properly addressing the clients by starting with their needs first. I found this subject very interesting and this source was a good resource to understand with its use of examples and visuals.

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