Reading Railroad

Read Constantly is a brief section, but it is an important apprenticeship pattern. Read Constantly is what it says. You need to constantly by reading and introducing yourself to new information in order to learn new ideas and improve. Most of the learning you do is from reading, whether its from sources on the internet or chapters of a good programming book. The more often you read and the better reading skills you develop, the better off you will be.

There is a book out there for every different programming language, every concept, every challenge you will come across in your professional career. I am currently reading a book that discusses the whiteboard problems brought up during many coding interviews. The book is long, and the content inside is dense, so it is important to read it carefully, take notes, and read it again to be sure of the information. That is my usual strategy for reading information that I need to learn.

My biggest challenge with reading constantly is feeling like I’m not absorbing all the information because I’m just trying to get through it. That’s why it is always good to do exercises in the book, if any are provided. That way you can do practical work alongside the reading that helps break up the monotony of reading and also gives you a different way to learn the content.

Another good strategy I use when reading is to take notes. There are often ways to boil down a text to its essential parts and the things you need to focus on and remember. Keeping notes, highlighting key lines, and keeping track of answers to exercises is a good way to maintain a reference if you ever want to brush up on what you just read.

Read Constantly is an important pattern when you want to learn something new or build a new skill. Good reading habits can open the way to learning lots of new things in a short period of time. It is absolutely the best way to learn quickly, especially if you are an independent person.

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.

“Expose Your Ignorance” Apprenticeship Pattern

I am writing this blog post about the “Expose Your Ignorance” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about making known what it is that you do not know in order to learn. People have a tendency of wanting to appear competent and knowledgeable about any job that is expected of them, but faking expertise is counterproductive. It is more helpful to seek knowledge than it is to hide ignorance. I have been looking at job descriptions lately, and many of them are filled with expectations and preferences referring to things I have never worked with before or have minimal experience with. My aptitude is for algorithms and data structures; I have studied and developed and implemented them a lot, for years. When it comes to “technologies”, though, I do not know anything about software development. There are so many languages and frameworks and libraries and acronyms that I am not familiar with because they have never been necessary or relevant before, and now I see that a lot of jobs are expecting proficiency with these tools. I am used to solving problems without extra tools, so in order to work in a new environment where an unfamiliar tool is necessary, it is important to establish that I do not know how to do anything using the tool. Then, I can begin to ask questions and learn how to apply my skills to the new problem. During the CAPSTONE project this semester, for instance, I am required to work with the Angular framework, and a tool for making things with Angular. I have no practical experience with any of these things, so whenever I need to know something in particular, I put out a question, so then I can learn. Rather than going off and trying to learn how to use these utilities, it is much more efficient to begin by seeing whether anybody else around already has an answer. Sharing knowledge and asking questions is a much more practical way to learn about how to work in a new environment.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Pattern 6 – Be The Worst

For this post, I was looking for an eye catching pattern name and “Be the Worst” definitely caught my eye. After a second a of thought, it was pretty obvious what this pattern would be about. This pattern breaks down why it is important to not be the big fish in the little pond. It encourages apprentices to not rush into leadership roles and to not strive to become the best on your team and stagnate with your position. Instead, if you find yourself at the top and lacking learning opportunities, it may be time to move on and find the bigger pond, to surround yourself with higher tier developers when you leave.

I almost entirely agree with this pattern. I remember growing up in a relatively small town, where we had a couple athletes who were notably better than anyone else in the town at their respective sport and position. None, yes none, of them tried to get into bigger school districts where they may be challenged more and had more of an opportunity to get scholarships and even potentially make it professionally. Instead they all enjoyed their high school careers at a school with roughly 500 students in a division 3 conference. They didn’t aspire to leave the little pond and they never made it anywhere in terms of athletics. There are definitely parallels to this even in the college world and looking for positions directly out of school. There are always going to be people who are happy to just cruise by and not learn everything that they can at each step of their careers. I honestly feel like these are the people who are most likely to never even get a job in respective majors and then somehow blame the university for not finding them a job with a 2.0 GPA. No one owes you anything and you can’t expect anything to be handed to you, knowledge especially. There is always more to learn and never enough time to get everything into a four year curriculum. Never settle for being the best you know. All that means is that you need to meet more people.

The only part of this pattern I disagree with is how the authors try to sway readers from promotions. Promotions and new responsibilities even outside of coding are definitely important to becoming the best within a company. If the goal is to rise through the ranks of a company, isn’t this an obvious side effect? That being said, I will definitely consider this pattern as I move along in my career.

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

Find Mentors

While most of the Apprenticeship Patterns  I have read thus far are mainly focused on developing long term skills with an internal locus of control, as many of these patterns’ goal is to change our perspective to be more successful and adaptable to the software development industry. What I like most about this pattern, “find mentors”, is that the authors give good advice for branching out socially into the software development community by finding skilled individuals who can serve as mentors that can use their perspective and experience to catalyze the growth of our skills.

What spoke out most to me about this pattern and the reason I decided to write about it was their quote which seemed to me to encapsulate exactly the meaning of what they were going after; “Your apprenticeship is unlikely to happen in isolation”. While it is ultimately up to us as apprentices to take responsibility for our own development, there is an immense value in finding someone else who is worlds more experienced than you to show you the ropes and use the benefit of their experience to learn the best ways to do certain things or pitfalls to avoid.

The authors give a lot of good advice which I would not have thought about without reading this pattern. First, they highlight not only the importance of finding mentors but also the difficulties associated with finding something. Not only is there the risk that the individual is not interested in mentoring an apprentice, but it can also be difficult to find such a suitable person. The solution the authors provided is to start out by lurking at online forums related to the field and topics that we are going into. After lurking and getting a good sense of the community and their values, then it is good to start discussing on threads with people, and even asking for advice.

What I learned from this pattern is the importance of finding a skilled mentor to catalyze my professional development, as well as concrete strategies for finding people who might be willing to take on an apprentice. While the responsibility is on us as apprentices to gain the skills needed to succeed, finding a mentor is definitely a huge step forward in the journey to master the craft of software development.

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

Apprentice Pattern: Expand Your Bandwidth

I work for a cable company that provides internet and a hot topic is always internet. People always accuse us of throttling or limiting their bandwidth. The issue that would result in is would be slower access to the internet. The word bandwidth being a trigger word I picked it out of the list of… Continue Reading →

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

Journey into “Retreat into Competence” (An Individual Apprenticeship Pattern)

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 seventh individual Apprenticeship pattern I have chosen to do “Retreat into Competence”.

Summary

There will be times, where you will feel completely over whelmed because you have taking on more than you can handle. Feeling over whelmed can be caused by other circumstances like having lack of knowledge and/or lack of understanding on just about anything regardless of complex level. Using the “Retreat into Competence” pattern is a good solution for this dilemma, even if  this solution is only a temporary solution. This pattern suggest that when you are way over your head the best solution is to take two steps back in order to be able to take 10 steps forward towards the right directions. The way the book puts it is to “Pull back, then launch forward like a stone from a catapult. Retreat briefly into your competence to regain your composure.” We must understand that to use this pattern we must set a time limit to our break or however long we choose to take a break. The reason is that if we take to long we can get stuck and never end up moving towards our true end goal. Another suggestion given is to seek guidance from your mentors because with their help and the new information you had picked up from your past experience will help you “be better equipped to handle the inevitable bumps on the road when you try again”.

 

My Reaction

This pattern helps you understand the importance needed to retreat into competence in order to have a clearer mind that can help you solve whatever, issue you might be facing at the moment. I agree with this idea because I found this pattern to be 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 should not panic if I do not know something but instead I should be taking steps back to see the big picture in order to be able to move forward and handle the situation I was presented with.

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

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.

Apprenticeship Pattern “Breakable Toys”

This week, I will be exploring another apprenticeship pattern, which is “Breakable Toys.” I briefly mentioned this pattern in my last post, and I thought it was worth revisiting.

The professor of my capstone, Dr. Wurst, had suggested for us to try to create something, even if it wasn’t exactly what we were trying to do. This would allow us to dive deep into learning one thing.

The term he used for what he was talking about was “spike,” which I isn’t exactly the same as this pattern, but it certainly is a similar idea. This pattern more pertains to doing projects on your own time to learn from your mistakes.

In school, it wouldn’t make sense to turn in projects that don’t work. It would be hard to pass most classes if I did. In many cases, school or work, failure is not an option. Of course the authors don’t advocate experimenting with those projects. They would rather you learn independently so that you can apply the skills you pick up.

For the past few blogs, I have talked about being more proactive. I have made a conscious effort, but it has been hard keeping it up. I have to realize that change doesn’t happen overnight, and it’s good to take these setbacks in stride to avoid being discouraged.

In the pattern, it uses the analogy of someone learning to juggle. I once read a study where of those instructed to juggle just five minutes a day, all of the participants were able to juggle by the end of the study. Reading this was enough to encourage me to try this experiment for myself. I set a timer for five minutes everyday, and I was able to pick it up after a few weeks.

The important thing to note is that five minutes was the minimum I set for myself, but I would invariably go for much longer than that. Currently I do not have any side projects that I am actively pursuing. If I were to set a five minute minimum to do something, although it would be small, it would be far better than nothing. I’m willing to bet most days it turn into much, much longer segments of time than five minutes.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

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.