For this week, I have decided to read “Concrete Skills” pattern from the Apprentice Patterns by Adevele Oshineye and Dave Hoover. I have chosen this one since it is a good refresher for understanding that knowledge known is not the same. I believe this will help me in making so that I can be sure to give more demonstration than telling by just writing it out.

This pattern starts with the context of seeking out a role in a group of talented people that will provide better learning opportunities than currently. The problem is that the team, when asked, they can not risk of bringing someone that would not be able to contribute for the intended workload. There is also when thinking further, the possibility of not being able to do even the simplest task when asked. The solution to that problem is concrete skills, acquiring and maintaining them. With these skills, demonstrating and having them will increase the possibility of being trustworthy and be able to reach the goals. Eventually, there will be less dependent on these set of skills as the possibilities increase in being hired for the jobs intended.

From this pattern, what I found useful is the listing for concrete skills as an example to give the point of giving trust to the employer. As we try to give a good impression and trust for the likes of employers, we want to be sure that we at least have a clear understanding and demonstration of the basic things to do like JavaScript and the standard libraries by choice for computing jobs. Skills may require more thoughts to give an even better impression than intended, but it does answer questions to which the employer may ask. This pattern has changed my way of thinking in my profession. As I read the short pattern, it has become clear to me that I should not only directly say as intended but also if needed, demonstrate what I can do even if it is the basic thing. For this pattern overall, there is nothing I don’t disagree upon and this is because the pattern was able to give good perspectives of knowing what to do with this concept.

Based on the content of this pattern, I will say this is a simple but effective one. This pattern has showed good examples of the real-life scenarios. It allows me to be aware in the future of demonstrating than telling by just paper. For practice, I will show some technical work to give good impressions.

Link to the pattern: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch02s04.html

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

Practice as they say, makes one perfect. Practice is the act of rehearsing a behavior over and over for the purpose of improving on it to be perfect. From the readings, i notice the statement which says “Your grandmother may have told you that practice makes perfect. She was wrong. In fact, practice makes permanent. ” which i think was quoted by George Leonard. Actually, i think he is getting the whole thing wrong. Practice actually make you perfect and also makes your permanent. Whether you are learning the good thing or the bad thing, you will eventually be very good at it, leading to perfection.

I also learned by practicing, you do not have to do it alone. Just by being at work or under a master, you will be learning a lot. By learning you are practicing at the same time. You should also be making sure you are learning the best stuff, since what you are learning, can be come permanent. You don’t want to learn being good at something that will not profit you in the long run. That will be a waste of time and resources. In order ways while you are searching for a good place to work or a mentor, you should make sure you picked the right person(s).

Also while getting used to things, make sure you are learning other new skill. You don’t get stuck on one thing. You need to know more, and by doing that, you will have to learn new skill when ever you thing are okay with others. Pick harder stuff or projects to practice on. Always check you strength, if too easy move to harder ones.

This pattern has not caused me to change the way i viewed practicing. But it has showed me there are ways i can practice in an excellent way or a better way.  And also types of practicing i can take. Also to my understanding, practicing with peers is more an effective way to be better at your skills. I really enjoyed this pattern and i know it will help me now and very well in the future.

From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.

          The “Be The Worst” pattern is described as a way be able to keep learning after you begin to hit a roadblock and your rate of learning has plateaued. The book explains that the solution to this problem is to make sure you are around developers who are better than you and can help you identify your weaknesses by comparison. It removes the sense of comfort that builds up once an individual performs better and makes you recover faster from mistakes with more competent team members at your side. The learning process can become smoother through this pattern and allows the individual a better sense of understanding of their skills before and after joining the team. The goal is to not remain the weakest team member and to be constantly working hard to make sure that you can surpass your team members. This can lead to sudden risks of dragging the team down if you cannot catch up quickly enough and affect how you view yourself. The motivation of an individual is tested here as well how much stress one can endure and to push through for the eventual endgame.

          I found that this pattern is very relatable to me which in turn could be useful to apply into my daily life. I find it interesting how much of the situations the book brought up were so similar to problems I’ve faced in the past in terms of moving my skills up to the net level. I found that my learning had plateaued as well and didn’t really understand how to deal with it. The idea of removing my sense of comfort form my first language is thought-provoking because it seems to be very difficult for me to let go of my first language and move on to more difficult concepts. I have always loved learning Java, but this pattern as shown me to look past a single language and continue to grow with the industry. I still am hesitant to let go of my coding habits from Java but realize that I have to make this change immediately. I should surround myself with those that are better than me and try to survive in that environment to evolve my understanding of code at a faster rate. I agree with this pattern completely after fully understanding how it works and how to better my skills through my environment.

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

https://www.newyorker.com/magazine/2018/11/12/why-doctors-hate-their-computers

In the article link listed above, surgeon Atul Gawande describes his frustrations with a recently developed new software which he and many others must adapt to. Initially one might assume this person just isn’t good at using software, like your grandmother trying to send an email. However, professionals in the medical field are typically especially adept at technology, their patients lives depend on their ability to update themselves on the latest development in the industry. That being said, the problem must lie in an inefficient new system.

The earlier stages of the switch to the new software are especially problematic. Firstly, medical professionals in all areas are required to spend a lot of time at training sessions when they could be spending it for their patients, which costs efficiency right off the bat.

Next, as everybody learns how to use the system, multiple problems can occur. It can take hours for somebody new to complete a complicated task, or minutes for one who is experienced in it, so the most obvious option is to get help from the IT department. The system is also new as a software product, new software products contain unknown bugs and glitches. I assume there is a rigorous testing process for any new tech when patients lives are effected by them, still, the software can be found at fault in the early stages. Both of these scenarios contribute to hundreds of tickets flood the IT departments inbox. In response, the hospital hires more IT people to help but ultimately a backlog keeps issues in waiting. Some of these issues can be especially serious in the medical field.

These early problems are expected, with the assumption that after a few months the system will be seen as an improvement. In this case however, even after getting use to the system, Gawande and his colleagues notice setbacks compared to the old software. For example, it added the ability for everyone across the organization to edit the “problem list.” The list use to be a quick way for clinicians to assess their patients at a glance, now it is filled with redundant notes from each person who accesses it. The same diagnosis is listed three times by three different people, long descriptions make it difficult to read the few things that actually matter, all contributing to more inefficient overhead. Furthermore, filling out diagnosis sheets has become more time consuming with the addition of new required fields. Whereas it use to take one click to order a mammogram, now it takes three.

What can be done about these inefficiencies? The article elaborates by explaining the concept of the “tar pit.” This describes a state of software development where a program becomes so large, it must be rigorously defined and spelled out for every specific situation so that it can encompass each scenario the same way. Users find themselves slowed down by these specifics, but cannot escape them, much like a tar pit. The result is that professionals spend so much time working through the system, they spend less time actually doing their jobs.

Software progress trends like these have serious consequences, professionals in this situation are more likely to experience burnout. Burnout is a state of emotional exhaustion, depersonalization, and personal ineffectiveness, this is caused by the pointless bureaucratic work that professionals must endure with their daily career. This eats up much more time than they are willing to give up. In 2014, only a third of physicians stated their work schedule “leaves me enough time for my personal/family life.”

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

On this Software Development Capstone journey part of my assignment is to choose 10 Individual Apprenticeship Patterns out of 35 patterns among Chapters 2-6 from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsmanby Dave Hoover and Adewale Oshineye. For my third individual Apprenticeship pattern I have chosen “Sustainable Motivations”. I will first summarize the pattern and then I will state my reaction of this pattern.

Sustainable Motivations summarized

Sometimes we are hit with the harsh reality of the “real world” you will run in to overwhelming programming projects. These programming projects would have you in all sorts of negative feelings more often then not. Other times there would be just about anything in your job that would have you feeling all sorts of ways as well. This pattern is guided to helping you get through these hurdles and preventing your programming motivation to be stump. That is why ” it is crucial that your motivations to program are aligned with walking The Long Road” [1]. In order to be able to achieve that you must ” it is crucial that your motivations to program are aligned with walking The Long Road“[1]. Otherwise “you will find yourself trapped in a Golden Lock”[1]. This pattern advises you to first make a list of at least 15 things that will keep you motivated and then after waiting a while add 5 more to the list. Then you are to answer the following question to help you with the eliminating process… “How many of your motivations are about what other people think rather than what you feel? Are the percentages different between your first 15 and the final 5? How many of the motivating factors can you do without?”. Your final step is to list, the 5 most important goals that would keep you motivated.

My Reaction

This pattern guides you with the ability to narrow down your goal to 5 things that would keep you motivated. It also, makes you aware of the danger of being too complicit by not desiring for mastery could lead you to being trapped in a Golden Lock. I agree with this idea. I found that this idea is not just interesting but also useful and thought-provoking. This pattern has definitely changed the way I think about my profession and the way I think because it has made me realize that I need 5 important motivation that will keep me motivated on this long road of Software Craftsmanship.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

“Some programmers become inadvertently trapped by their motivations. In More Secrets of Consulting, Dorset House, Jerry Weinberg describes this phenomenon as the Golden Lock: “I’d like to learn something new, but what I already know pays too well.” “[1]

[1] Quote is from the book Apprenticeship Patterns by Adewale Oshineye, Dave Hoover from the Sustainable Motivations pattern chapter.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

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.