Apprenticeship Patterns – Practice, Practice, Practice

This pattern discusses the importance of practicing when it comes to improving your skills as a software developer. Many people’s daily programming activities do not give them the space to learn by making mistakes. If you find this to be the case, it is important to find an environment where you can practice without interruptions or pressure. For this pattern to be useful you need to carve out time to develop software in a relaxed and stress-free environment. If you aren’t relaxed, it will be harder to learn from your practice. Feedback is also important when it comes to practicing coding because it helps prevent bad techniques from being developed. The point of practicing is not to hone your memory, but to learn the nuances of your skill. This is why it is effective to do something a little different every time an exercise is performed. Choosing the right thing to practice is almost as important as the practicing itself. A good way to practice is to go through old programming books that focus on the fundamentals of computer science, as the information rarely stops being useful and provides a large source of interesting problems.

Reading this pattern was interesting because it complements the last pattern I wrote about, Use the Source. While that pattern discusses how reading code is important for improvement, this pattern talks about how practicing coding is important. I thought this pattern was very useful because it goes over the most effective strategies for practicing. The advice given about practicing in a relaxed environment and practicing within a community is very true. Enjoying your practice and getting feedback on it are both important aspects that are necessary if you want to see real improvement. The advice about doing exercises from older books that focus on the fundamentals rather than the latest trendy framework is also useful. There are so many frameworks out there that it can be overwhelming to pick one that you want to practice with, and sticking to the basics is usually more helpful anyways. Overall I thought this pattern was interesting to read through and I will try to apply what I’ve learned from it when I’m practicing in the future.

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

“Practice, Practice, Practice”

After “Expand Your Bandwidth”, we learned how to learn skill set. To make those skills better, I don’t know any other way than “Practice, Practice, Practice”. This is no secrets in life and coding is no exception. Once you learn, practice is the way that you can apply, and deeper understand from your mistakes. There is no point learn language without apply it to practice.

This is good point, if we take the time to practice our craft without interruptions, in an environment where you can feel comfortable making mistakes. When we don’t code with other people, we don’t feel pressure to get it right. When we make mistake, we just debug to fix and learn from it. The “deliberate practice” seem nice but we do not live in ideal world. Although it would be great, if there are program that learn from our coding and suggest exercise base on us weakness. It is better if we have stress-free and playful environment to practice, I would feel more comfortable doing in this area. Because I do feel the pressure coding in classroom. Although it is comfortable and less tress when we are coding alone. It is having its downside, to get better we need someone else to look at our code. Good code is not just the code can run or not. Code is good code when it is clean and efficient, by other developer look that our code. They could tell us where are our strong and weakness. We correct them and repeat the process; this is how we are getting better. As in the book suggest, each time should be a bit challenge. Take what we have learn and devise it to the next level. As I am graduating soon, this is one of my goals. I will try to practice more as well as learn new technology.

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.

Sprint 3

Hello everybody and welcome to another sprint retrospective blog post. Today sprint retrospective blog post about what I have done during sprint 3. Some of the things we had on our sprint backlog is if we have login information – examine screen code for some examples of screens on AMPATH site. Figure out if we’re getting information to access AMPATH site. If we have time – read more about Angular unit testing – mocking. If we have time – read more about Angular unit testing – mocking. Read mobile angular docs http://mobileangularui.com/docs/. I also sign up for Zeplin and send my information to Greg so he can verify my email. I also kept an eye out for Zeplin shared folder – where designs will be. I also to work on the navigation bar tool for the Ampath project. I created a skeleton for the Ampath project and discuss roles for stories that will about the project. After the second sprint I realize that I was getting more comfortable with scrum. I can now easily now login on to Trello and understand what’s going on and what I can do and what other did and are in the progress of doing. When I finished the skeleton, I posted on Gitlab instead of Github because there wasn’t a repository for at the moment and I was more comfortable with Gitlab. I also lookup more sample of a navigation bar so I can see what features other navigation contains. One of the problems that I have so far was to get the toggle button to drop down when click because the code actually to drop down when hover. I think the scaling of the project is not going to be a problem because I tested the component and it look fine in a iPhone simulator. There were others stuff I think has to be done like adding information and hyper link to the navigation tabs so that when clicked it would navigate to a different view controller. I think design is also important later to make the component more presentable. I also ran the project on a web browser, and it was fine too. During the standup, I got more comfortable with the time schedule. I haven’t missed a stand up. I realize the importance of the standup so that we can keep track on our progress. All in all, I think this sprint all went very well, we got a lot done, I think. I also found many ideas on how to show that link actually works by inserting hyperlinks and navigate to that site. I think it is a good way to show how the component performs. I didn’t have much problem during this sprint and expecting the same going forward. The only problem is that we don’t have access to the service right, but I don’t think its issue because we don’t really need it to have the component to work. This sprint was fun, and everyone was on the same page, until the next sprint retrospective blog

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

Sprint Retrospective 4

For this sprint, my team and I continued our work on trying to mock the server aspect of the project so as to give other teams a way to test their code. We had followed the tutorials on nock to make sure we understood the way that it worked and how we would have to translate it over. However when we went to the AMRS code to try to find something to try to mock we ran into some problems. Going through the code, there is a lot of moving parts to each element with the program which made mocking just one thing look like it may not be possible. Not only that but almost everything we found looking through the code, returned html responses from the ng-AMRS server they have set up already. For example one of the main things we looking into mocking was the patient-creation-resource part of the simple App, since it seemed to be one of the smaller files and less requirements/calls to other classes. In trying to mock one of the methods from this, this is where we started to feel that this may be a little too high of a task for us without the AMRS server itself. I feel as though if we had access to their already made server and could have just mocked the tests at that point we would have had much better success. There were just too many moving parts to each thing for our current way that we planned on mocking to be realistic. During this sprint though, I feel we were able to work more on the project and were actually making headway till we hit the wall on what we could actually wind up mocking. At the end of this sprint we also started talking about the possibility that we might not be able to achieve what we set out to do originally, so we also started looking at the bottom navigation bar element that still needed to be completed. We chose this as our backup and I had started to get some of the smaller stuff out of the way for that. I have gotten together all of the CSS and HTML components for the bottom navigation bar with what was provided from Greg Schmidt on the Zeplin app. Since this seems to be the direction we will be heading in the next sprint I felt it was smart to try to get ahead on some of the smaller/easier stuff. What I will need to be looking into and finding out how it works is the button elements that Greg Schmidt wants and how I can recreate them.

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

Apprenticeship Pattern – Create Feedback Loops

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s08.html

This pattern encourages the reader to pay close attention to minor details along the way when evaluating a success or failure. Apprentices commonly find themselves in complacent situations in an average team, so naturally improvement stagnates and it becomes hard to keep yourself on track. The problem is, “the less skilled you are, the worse you are at assessing the skills of yourself and others.” This indicates that it is especially hard to get started again once caught at the bottom of the barrel.

The pattern advises seeking out feedback and constantly adjusting yourself accordingly. This will help you more accurately predict success or failure and help you more efficiently improve. Being open with your work is the focus of other patterns, all apprentices should strive to be as “teachable” as possible.

The chapter classifies feedback under two categories; reinforcing and balancing. Reinforcing feedback encourages more of something, while balancing feedback encourages less of something.

In my personal case at work, I can apply feedback to the pitch I give to the average customer. For the most part, my pitch is designed to be friendly and get the customer the product they are looking for quickly. In that time, I work to fit in other deals or offers I think the customer might be suited for. This could mean higher quality products, the benefits of the best buy credit card, or becoming a member of our total tech subscription service.

At the end of the month, we are provided feedback on how much we sold and how many cards or subscriptions we put out. Some months are luckier than others, but certainly every associate starts to get better and better over time. If an associate doesn’t raise enough revenue after a few months, they receive coaching on their style of pitch. Reinforcing feedback in this case would encourage an associate to mention the subscription service to more customers, thus increasing the chances of closing one. Balancing feedback would prevent swearing and acting rowdy with coworkers in front of the customers, in an attempt to be more approachable.

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

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 – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

Sweep The Floor

Whenever you are new to a team, it an be very nerve racking because you do not want to mess up a single thing. This mindset is perfectly normal and makes sense.  This pattern discusses newcomers into a project and what to do in this environment. For starters, it’s always important to make good relationships with your team. The situation is that you are a new apprentice on project and the team is unsure of you. You want to find ways to contribute to the teams work but you can’t overdue it. This pattern explains that y ou should volunteer yourself for simple but necessary tasks. There are always going to be certain tasks that your team will need to get done one way or another, and even though they are simple tasks, they can often enable for the future success of whatever project you are working on. When taking these tasks, you should still pump out a high quality job. Showing that you can perform even basic tasks at a very high standard of quality shows your team that you care about what you are doing even if it is just small tasks. Sometimes these tasks can be just as vitally important as other tasks. Some examples of these tasks are maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, or even setting up the project wiki. However, it can be tough to do if you spent a lot of time and money on computer science education. The reality of it is that when you get into the workplace, our education is worth a lot less. When you join a computer team, getting hired is different from joining a team. Your firsts takes should be made to send a message. However, there could be some potential downfalls to this pattern. It could keep you permanently doing these mundane tasks for the team and never giving yourself a chance to expand to bigger and better things yourself. But if you do the tasks that sometimes your team may not want to do, it could give you a sort of priority on what you can do next for the team and open new opportunities for your team to see how worthy you are.

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.

Apprenticeship Pattern Blog: Sweep the Floor

Hello and welcome back to Benderson’s blog! This week we will be discussing another apprenticeship pattern that I have found that talks about being the new person on the team and how you should approach the situation. This apprenticeship pattern is called “Sweep the Floor”, which is basically saying “work your way up and build trust”, or at least that is what I got from the title of the pattern. Before reading it, I thought of it as like you may start off barely doing anything interesting and not like your job at first because of the lack of oppurtunities or being put on tasks that aren’t what you want to do but you got to stick with it because you’re the new guy and you got to work your way up the chain.

Sweeping the floor is a very boring job that no one really wants to do, being the new guy on the team is also something people don’t really want to be. You got to start somewhere though and being the new person on the team maybe terrifying to you but you will get through it. This pattern talks about growing from being the new guy to being a big contributor to the team. It talks about showing the team that you can contribute and work hard and get things done so they can trust you more as the time goes on. You may be stuck with the boring jobs of programming such as maintaining a build system, production support, responding to maintenance requests or even bug fixing code. These won’t be fun but they will get your shoe in the door of gaining the trust of your colleagues. You may feel like that you spent four years of your life working hard in school and that you deserve a better to start after all your education that you have received but you got to work your way up, you can’t start at the top. An example I could think of where this pattern is relevant is with a guy that runs the Xbox department of Microsoft. He started at a low part of the company and wasn’t really known until he stayed with the company and became a loyal employee and when his opportunity came years later, he took it and everyone trusted him to take it over because of all his hard work through the years at Microsoft. So far, in my opinion, he has been leading Xbox in the right way after a huge personal relation bust that happened before their latest console launched which was with another guy being the head of the Xbox department who later retired. That is what I hope my story is, I want to work for an up and coming company and eventually after striving for a long time, I want to make the company huge and lead it to become one of the best and most liked companies in the country. Huge goals I know, but you got to aim high to get high. With that last inspirational line, I will send you off this week, thank you for joining me at Benderson’s blog, I’ll catch you next week!

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

Lost and Found

The section titled Find Mentors discusses finding people in your field who are seasoned and have a lot of experience to offer, and to reach out to these veterans of the field and try to gain from them what knowledge they have to offer. It is a simple idea, but as the text explains, it is intimidating to just ask someone to offer their services and mentor you. It is a lot to ask, and not everyone is up for it after all. Besides, it is challenging to know who is even a good mentor, and who is not.

I consider many of my professors at Worcester State mentors to an extent. However, I wouldn’t say I’ve ever had the kind of mentor-ship detailed within the section. I can definitely relate to the anxieties listed about reaching out to someone. It can seem weird and uncomfortable. I suppose it is just a feeling you have to conquer if you want the best for yourself, however. After all, nobody else is going to ask for you.

From my perspective, Find Mentors is such an important pattern because there is a limit to how much most people can learn independently. There is such a huge advantage to having a resource like someone who has been through all the challenges you are facing and can solve some of the problems that come up. I hope that in my future I have the chance to meet someone who can offer me these advantages. Actually getting into the field is a huge hurdle, and having someone who has been through it and could coach me on how to navigate it would be incredible. It is just something I am going to have to search for.

Overall, Find Mentors seems like one of, if not the most important apprenticeship pattern I’ve read about and discussed so far. After all, finding a compatible mentor that is willing to dedicate the right amount of time for you would result in huge growth and development. It is hard to obtain this ideal, but it is something worth striving for.

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.

Sweep the Floor

For this weeks blog post I will be discussing the pattern known as “Sweep the Floor”. Sweeping the Floor is about you starting from the bottom and then getting into the more complex tasks. This being you contributing to simpler tasks, learning from these and becoming more skilled then graduating into larger more complex tasks. Imagine you are an new apprentice on a project, unsure where you stand compared to others on the team and they are unsure about you as well. You want to earn your place on this team, contributing where you can, gaining their trust and growing in the craft essentially. To do this you could simply volunteer for something simple that is necessary to complete. This is a good starting way to contribute to a foreign team and to the teams success early on by showing you can do high quality jobs even for simple matters. Skimping on quality here could lead to trouble later on when it turns out later that this part is actually very important. Some various examples of these tasks include maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, setting up a project wiki and so forth. Basically you would be focusing on the edges of the system where less risk lies rather than the heart of the project where the stress and complexity would be. But this of course could prove tougher to swallow if you have spent a lot of time and money in a computer science degree. The moment leading up to your career in theory has been doing all of the said above tasks almost just without pay. Another negative aspect of this would be you ending up as the teams gopher, condemned to do menial tasks no else wants to do. You may find yourself intimidated by doing anything other than sweeping the floor, feeling only comfortable doing this. There is also danger in that you may not be able to develop appreciation for bigger projects due to the smaller menial tasks you are accustomed to. In short finding the tasks nobody wants to do or complains about and creatively resolving these problems in ways that exceed peoples expectations will allow you to slowly soar above, something that most including myself can get behind.

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