For this weeks blog post I will be looking into the pattern where are you told to “Stay in the Trenches”. Here you are advised to stay in the trenches even if you are offered release off the front lines into a much safer area. What does this mean in a modern day environment well you are on the “front line” to say of a programming job where you in a “grunt” position where basic programming duties fall upon you. One day you are offered a promotion where you will no longer be programming or doing to say the “dirty work” but in a more comfortable position. As it says in the pattern that most people always assume a promotion into management is associated with success. Thinking that if anyone is offered a position like that it’s a no brainier to take, meaning you are doing good. The reason going into a management position where you are out of the trenches is that your mastery fades due to you not practicing it anymore. To counter this maybe working with your employer to find other rewards for your good work whether that be more pay or other nontraditional technical leadership roles. If your employer is inflexible then it is perhaps better to seek opportunities elsewhere. This pattern is very interesting to me as it makes a lot of sense to stay in the trenches for experience rather than dwindle. It also falls upon the person to decide whether or not they want to stay on the front line or go up the ladder into a management position. Someone may feel more comfortable or even get more out of a management position instead of being a front line programmer. But again, that is all up to the individual and isn’t really predetermined in my mind. It all depends on what you want to do with your career and so forth so its hard to tell if I could see myself applying this method to a real life situation.
I am writing this blog post about the “Be the Worst” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of the pattern, it is about trying to be in the presence of people with more experience than you so that you can learn from them, as opposed to being experienced already and not having the opportunity to learn from others. I can see this being a useful way to learn, but at the same time it does seem a bit selfish to put your own education above the quality of whatever it is you happen to be working on with everyone else. To be the worst may indicate that you do not actually belong where you are while you exploit the opportunity to learn. If this does not turn out to be a concern then it is still the case that you would not be performing as well as anyone else, so it may be discouraging to have a responsibility and not be prepared for it. Maybe being the worst is taking it to the extreme, but the more general goal of not being the smartest person in the room is a good way to learn from the person who does have more experience. I have been programming in the same language for the last decade and I now know everything about the language down to the exact differences between each version, and that came from being involved with other people who had knowledge that I did not have. Now there is no learning opportunity after having mastered this language, so since I have not nearly the same level of experience in any other language, it would be a significant learning opportunity to surround myself with experts in another language that I intend to become versed in. Since I have learned everything I needed to know to do the things I want to do, I have stopped learning at the same rate. Moving forward into a career, I expect it will become necessary to be just as experienced in more languages, so engaging with experienced programmers who use those languages will be beneficial.
What I found interesting about this pattern is that it mentions “getting past crude HR filters and managers who construct teams by playing buzzword bingo”. This relates to stories I heard of HR or managers who do not have enough knowledge to do the hiring but is placed in a position to do so. As such, they would deploy tricks and systems, or “filters” in order to find the people they need. Another interesting point brought up by this pattern is the action provided at the bottom. It states that we should note discrete skills that could be useful right away for the team that you want to join. I do believe this is a good strategy to be on top of knowing what skills you can bring to the table.
This pattern has not caused me to change the way I think about the intended profession because this also useful for other professions. The process of hiring people onto a team is always a risk in one way or another. Systems are brought into place because they want to avoid issues off the bat from a new hire, as such you have to demonstrate that you can do the job they expect of you.
From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.
The Apprenticeship Pattern “Breakable Toys” refers to a scenario where the environment you’re working in doesn’t allow for you to fail, stifling your learning because failure is often the best way to learn anything. According to the author, the solution to this is to create your own “breakable toys” from which you’re able to learn through catastrophic failure that won’t have an effect on anyone but you.
The thing I find most interesting about this pattern is some of the examples it suggests to do in order to create opportunities to learn. For example, creating your own wiki and adding more interesting features without being bound by existing implementations. I can see how working on something like this from start to finish would greatly improve your ability as a software developer.
It would be great if you could be satisfied with the amount of learning that you’re able to do within your current work environment, but given the fact that businesses need to make money to survive, taking risks and learning through failure is typically not something that can consistently happen if a company wants to continue existing. That’s not to say that mistakes should never happen, but it makes sense that a company would want to avoid them as much as possible in order to retain the trust of their clients. If someone were to make a costly mistake for a company, it should be used as a opportunity to learn from it, rather than just firing that employee and moving on.
I recall there being a disruption in Amazon’s S3 service causing around 3 hours of downtime being attributed to human error. One of the employees on the S3 team was debugging an issue when he accidentally removed a larger set of servers than he had originally intended, all due to a small typo in his input. Regarding this incident, Amazon stated: “We will do everything we can to learn from this event and use it to improve our availability even further”, acknowledging that they would seek to prevent it from happening in the future. I would imagine that the employee who made the mistake may have learned a lot about the potential effects of something that seemed so insignificant.
From recent conversations with friends and professionals I’ve had genuine one-on-one discussions with, a common concern people have is whether they will continue to actually enjoy what they do. Today I’m going to discuss the Sustainable Motivations apprenticeship pattern. This pattern pretty much goes over scenarios people may run into throughout their careers in technology. There will be great days where people may be amazed that they are getting paid to create things and there will be rough days where people may be doubting if it is the right profession for them at all.
The points brought up remind me of a recent article from the New York Times titled Wealthy, Successful, and Miserable. What happens when the new-ness of what started as an exciting role to join in a company wears off and you are left off with unsettled feelings? It is up to individuals to keep going until they find what they love again or shift what they are doing a little to stimulate something new.
I like how the pattern encourages people to come up with a list of things that motivate them. It then tells them to reflect on what those things means or if there is a noticeable pattern from the things they have chosen. Having a list like this around to remind people of what they are working for is a reassuring way to keep them going. It reminds me of a post on LinkedIn I saw where someone kept a sticky note on their monitor screen that just had a number like “-$237.25” because it was to remind them of how much they had in their bank account when they started their job.
The pattern has caused me to think about the way I intend to work as someone who constantly likes to change things up or is not afraid of change. I do not disagree with anything in the patterns as it tells us to keep pushing and persevering by thinking about The Long Road, which is another apprenticeship pattern.
Overall, I think people interested in this pattern should read the NYT article I linked as well because it gives insight on the difference it makes when people do something that makes their work feel more meaningful.
The Retreat into Competence pattern describes what you should do when you feel overwhelmed with how little you know. Every apprentice will eventually feel ignorant or incompetent compared to the craftsmen they will meet. This should not be a reason to worry as it is a normal and inevitable phenomenon. However, when it happens you should retreat briefly into your competence. What this means is to work on something that you already know very well in order to regain some confidence and realize how much you’ve learned since you began your journey. This pattern is relevant for people who are struggling or stretched beyond their ability. If you find yourself in this position, you may need to take a step back before you can continue going forward. However, it is important to realize that this pattern is only a short-term fix so that you don’t surrender to the comfort of working only on things that you know very well.
I enjoyed reading this pattern and found it to be useful because it is applicable to everybody at one point or another. Reading this pattern reminded me of impostor syndrome, which is when somebody persistently feels like a fraud despite evidence of their competence. I think this is something that a lot of computer science students feel since there is so much information to learn and the technology and tools we use are always changing. I think that this pattern is great advice for someone who has a case of impostor syndrome or simply feels overwhelmed by their work. Taking a step back and working on something that you’re comfortable with will allow you to clear your head and regain your composure. It is important to remind yourself from time to time how much you actually know and realize that many things you do easily now once seemed impossibly complicated. Retreating into your competence will help you spring forward when you go back to new challenges. I’m glad that I read this pattern as this advice will definitely help whenever I feel lost or overwhelmed in the future. I now know that in situations like that it will help to retreat into competence for a little while.
For this week’s blog I have read the “Learn How You Fail” article of the textbook. The context of this chapter is failure is inevitable, how will I learn from my failures to prevent them in the future? The context set up for the problem is that we learn from our successes and we are successful because of our successes but we also still suffer from our weaknesses and our weaknesses lead to failures. This rings true with me as I understand that I do not know everything there is to know about software and software development. How I view this is to learn from my failures and learn how to prevent them in the future. I understand that I will fail eventually, as I do not know everything. I understand that I also will learn from the mistakes I have made and the failures I have encountered and I will lean how to prevent them in the future so that I will never have to see the same failure twice in my career. The solution that the textbook is proposing for this is try to identify your failures or areas that your fail before you do fail. Being a self preventative at failing will help myself not encounter failure as much in my future. One point that I really enjoyed was learn what trips you up and become conscious of it. This is a great way to prevent failure because if you encounter or something or know you will soon encounter something that often tends to get you to trip up, hopefully if you realize that is coming down the line you will have ample time to correct the issue before it becomes an actual issue that will result in failure. If you are able to avoid this failure, then you can consider yourself successful. And as we learned earlier, we learn from our successes and we are successful because of them. When we avoid failure we can consider it a success. We need to understand that we cannot become crippled or frustrated by our fear of failure. We have to understand where we fail and learn how to stop ourselves from failure instead of fearing it until it strikes. I have learned a lot from this article and I hope to avoid failure in the future by using the skills I have learned here.
This week finishes up sprint 2 of our senior software development capstone project. In this sprint we accomplished quite a bit. The most important advancement that we made in this sprint is getting specifications from our product owner as to what we need to do for them. At the begining of this sprint cycle we were able to meet with a representative from the food pantry, Serena. Serena was able to tell us more about the food pantry and what they are doing as well as what they would like to see as a product from us. One of the biggest takeaways from this meeting was to realize that the main objective for us is to assist the food pantry in their quest to transfer all their business and business operations from paper to digital. One of the largest problems we realized off the bat is that the food pantry does everything from data storage to daily operation by paper. We know as software developers that this physical paper way of doing things is very inefficient and can be vulnerable to human error (totaling numbers in wrong columns, incorrect data input, etc). Our thought was to help them by making software to help them transfer to digital and also do some automation for them so that they can avoid any possible human error. However, we as the software development team are not here to tell the food pantry owners what they should be asking for. There is a fine line that a software developer working with a product owner where you should suggest what you think you should develop for them that may be helpful while also staying within their guidelines. The biggest issue here is that the food pantry representatives do not have a definitive set of product guidelines and rather are open to any ideas we may have for them, as they currently are 100% paper and are looking for any help to go digital in a way that is useful to them. I enjoyed this part of the sprint because I got to interact with the people on the other end where we can talk about what we need to do and what we would like to do. After our meeting with the product owners we were able to start on our project. One of the group members started working on back-end development and was able to deploy a gitlab project for it. I started working on a front end HTML mockup of our worker client screen. Another member of the group worked on finding out how to parse a json file using gson. After our most recent sprint meeting we decided on tasks that we’ll start doing for the new sprint. More front end development will be done this sprint. This will be taken on by myself and another few team members. I specifically will be working on CSS stylesheets for our project. The other members will begin writing a Java program to connect our project to a database. In sprint 2 I learned a lot about project management and working with product owners.
This week, i read on “record what you learn”. On the reading, i got the importance of recording what you have learned. As it is generally said, it is good to keep notes. During your craftsmanship or the process leading you to the real word job. You will need to jot what ever you learn, whether from your master, from colleagues or from your own researches. By doing this you are able to learn more skill faster.
For instance, you have learned a new computer language just because you want to create a new project. But in order for you to complete the project, you will have to learn an additional language. Since it is a new language, it is likely you will forget a whole lot of stuff. And at the same time you will need to learned this new second language as well. So in this case, while learning the computer language for the project. It is required for you to jot up some notes just in case you are learning the second language and its time to join both languages together to complete the project, you will be able to recall all what you have learned or what actually you might have forgotten.
if you want to become the best in your field, taking notes is your ticket to making it happen. As you build your career and keep track of what you’re learning, you’ll have easy access to your very own refresher courses.
Quality notes not only help you build a strong arsenal of knowledge, but they can help make a difference in the lives of those you care about. If a new co-worker needs to get caught up on a project they’re working with you on, they can refer to your notes to catch up without feeling overwhelmed. If a friend misses class due to a family emergency, your notes can help them get back on track. It’s a win-win situation for everyone involved.
Taking records is a nice action that reveals much about a person’s patience, determination, and attention to details. It also shows you’re efficient and don’t allow what’s important to fall away. From the this pattern, i have come to realized, the reasons for all the blog pages and a whole lot most instructors guide us through.
Hi everyone and welcome to another CS 448 blog. Today blog is going about study the classics which is one of the apprenticeship patterns by Adewale Oshineye, Dave Hoover. This blog is a simple pattern which helps me understand the importance of learning the basic. This pattern is about constantly updating your knowledge about the field and making sure you have a strong foundation on the field. After reading this apprenticeship patterns I realize that I should ask where the sources of information are coming from when trying to understand a subject from a person. Most of the time when I don’t understand something that is being talked about, I usually just ask the individual to explain the details in more depth but now I understand I should ask the person where they had discovered the information so I can learn it. I think the biggest problem I have with advancing my skills in programming is that I don’t read enough. After reading this pattern I decided I going to make a reading list to further my knowledge in programming. I like how the pattern points out that there a reason why the classic books are kept and are important to learn. This change the way I judge classic textbooks and now I more interested in them. Most of my books are updated so I haven’t look at any old books yet but I disagree with this pattern a little because some of the books like programming books always have to be updated so the classics wouldn’t apply but I can see other books like theory having classic book that can still relate even in today times. All in all, I think this apprenticeship pattern study the classics is important to the pattern because it explains the importance of understanding the classics while using modern tools. After reading this article I learn to read more, and I change my view on reading. I always feel like watching videos and doing projects was enough, but I now realize that you have read more of both classics and modern book to further my knowledge in the programming field.