Category Archives: Week 5

Find Mentors

There are going to be many situations in which we will not be able to figure out a solution to something. Deciding what to do in these situations is a big portion of solving the problem. Sometimes we can get very frustrated and give up. Other times we will try mundane fixes that won’t even solve our main issue. One thing that we need to realize, however, is that we are not alone. Most often than not, some issues that we run into have been solved by someone else. There is no reason to tread dead water if a solution is out there. Finding the way to this solution is a key part in problem solving. So, what do we do from here? We seek out help.

The thing I liked the most about this method is that by seeking help, it shows our willingness to understand and continue to learn. It also teaches us how to figure something out on our own, even if we don’t know what that issue is. One main part I agree with about this method is that it explains how, since this field of study is fairly new, it can be difficult to narrow down the “masters of the craft” because an apprenticeship can only mean so much. The difficult part is finding that one person who CAN teach you and guide to on the right path. One of the hardest part about mastering something is finding a that specific master or network of masters in order to reach the goals you have set for yourself. You can’t expect to learn everything on your own, this is an issue in itself. You need to seek help, evaluate that help, and then decide if it is worth your time to continue to learn by them. If not, that’s something you will have to decide. One great modern tool that we can use to do this is the internet. A simple google search can solve a lot of our problems, especially in this field of study. But sometimes we also should be careful at which sources we are pulling from.

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.

Pattern “Read Constantly”

The apprenticeship pattern I decided to choose for this week’s blog was “Read Constantly.” It was somewhat self-explanatory, but I thought it had some good insights nonetheless.

It recommended reading books over blogs. I would imagine that this is the right course of action from researching blogs last semester. All the material was good and informative, but many times when the host was interviewing someone, it felt like a summary of what could be a very interesting book. There’s only so much that can be gained from a blog post or a podcast. The things that you learn from those can be valuable, but it is better to go deeper when possible. Even if you have a very wide base of knowledge, it will only get you so far when you only scratch the surface.

The quote at the very beginning, from Steve McConnell, says that if you read a good programming book every other month, you will distinguish yourself from your peers. This seems like a worthwhile task, and frankly it is very doable. He chalks this up to be 35 pages a week, which is less than many reading assignments for school. Those don’t take me very long and aren’t very hard. It would be helpful to read more supplemental material, especially on break and after I graduate.

I haven’t read any research papers in this field, but that sounds like something I should start thinking about doing, especially when I pursue a graduate program. It recommends reading some at least every once in a while.

It also recommends keeping a slim book to fill dead time throughout the day. I think this is a good idea, especially when something can be overwhelming. It’s like the old adage of how to eat an elephant — one bite at a time. Or in this case, one page at a time and whenever you have a moment.

This is something that I’ve been trying on my own in general as well. When I was younger, I was an incredibly avid reader, and I’ve slowly gotten out of the habit as I’ve gotten older. I would like to read more of everything. I think it is a mark of a well-rounded and intelligent person to be well read.

It was a new year’s resolution to read more. I have been trying read a few chapters everyday of something, which has mostly been non-technical so far. I’m going to to change that and start adding more material that will not just better me as a person but better me as a software engineer.

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

Rising from the bottom

For the fifth week’s reading, I chose to read the pattern, Be the Worst. It is about facing a problem where your rate of learning has plateaued. As such, a solution is needed and is presented as instead of being in a team where you are at the top. You will have to find a team where you can be at the very bottom. The objective is to work your way up from the bottom, and from that you should be able to learn from those who are better than you. By actively trying to become better than what you were before, you allow yourself to continuously improve. However, there are risks of placing yourself at the lowest. The first is that you could be a negative impact to the team which would mean that you aren’t contributing as much as you should. Second, you might find yourself losing motivation when things do not pan out the way you thought it would. The action provided in this pattern is to rank teams by skill level and find a team that would allow you to work your way up.

What I found interesting about this pattern is that there is no easy way of solving this problem. You have to be willing to improve, willing to learn, and willing to drop your comfortable position to continue chasing the top. After allowing yourself to do that, you need to continue having the motivation and enthusiasm to improve yourself in a team that you know is way more knowledgeable than yourself.

This pattern has made me think about the intended profession in a way that everything will not remain the same forever. As time passes, teams will become more knowledgeable, but every individual will learn at a different pace. If you happen to be a person that progresses faster and becomes better than the team much quicker. You will eventually come to the realization that your learning has plateaued. By planning your road map in conjunction with this pattern, you have a chance of continuing your journey to become a master if that is what you wish. This is what I learned from this pattern.

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.

Retreat into Competence

This apprenticeship pattern seem to be able to fit most of us as we emerge as newly graduates going into the development field for the first time. We have enough basic skill and foundation to get us through problems but there are many things we have yet to uncover. Retreating into competence talks about how you begin to realize how little you actually know and the task you are assigned with may be a bit overwhelming.

The solution provided for this problem is to simply regain your confidence. Know that you have come a long way since day one and that you are capable or finding a solution. This is a problem that everyone will eventually go through; especially those who take on more than they could manage. The author suggests to re implement a concept that you know very well which usually works for me also. It allows me to regain composure and confidence at the same time.

I agree with the solution to this problem because I have already gone through it in my own ways. At the moment I am learning and gaining the skills to become a full stack developer. I am utilizing all my skills I have learned as well as new concepts that seem like a different language to me. Many times I find myself staring blankly at the screen, lost and confused at what I just wrote down or why my methodology isn’t working. Sometimes I even walk away and come back hours later. I find that each time this happens, I am leveling up; I am getting out of my comfort zone to learn new things. I know that this is just the beginning of this journey and it most definitely gives me confidence that I am able to solve the hardest of problems sooner or later.

Stay tuned for the next apprenticeship pattern!

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.

Expand Your Bandwidth

For today’s blog I will be writing about the “Expand Your Bandwidth” pattern out of chapter 5 of our text. I enjoy this pattern because the context is simple. “You have picked up a basic set of skills”. That’s it. That’s the context for the chapter. It is broad which leaves it open for many people to relate (perhaps not just software developers!). I can personally relate to this because I have a basic set of skills in programming that I have acquired over the past four years at school. Now that we have the context we can delve into the problem that the chapter presents to us. The problem put forth by the book is this: You have a narrow-focused low-level understanding of software development. The problem is that you think this way because of the narrow day to day scope of your work. When you work at a narrow scope of software development, then your knowledge and perception of software development becomes less broadened and more narrow and that is not good for a field that must consistently be changing and overcoming new ways of developing in the field. The solution is to broaden yourself by improving your ability to take in more amounts of new information. The text says “You’ve been drinking steadily through a straw. But there are seasons in apprenticeship when one must drink from the fire hose of information…” I think this is a perfect analogy because in a small setting like university classes we are hyper focused on our assignment at hand or the specific software skill/methodology that we are using for that class. A perfect example would be when I took my software testing class, we were solely focused on writing tests and not actually developing any code to test. In this case we were drinking from the straw, but sometimes a project would require you to know what was going on in the source code, which required other knowledge not related to testing, which in this case would be drinking from the fire hose; a much bigger flow of information. To make yourself marketable for a successful career you must know how to take all sorts of information from all aspects of software development. In this way and after reading this text, I believe that it is good to know a decent amount of information across many aspects of software development than it is to have a vast knowledge of one aspect of software development. Having the smaller knowledge of many areas allows for more flexibility and easier adaptations going from one task to another in the software development field.

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.

Apprenticeship Patterns: Record What You Learn

This week I read Record What You Learn in Chapter 5, Perpetual Learning. I read this partly because I found irony in recording what I’ve learned about recording what you learn, but also largely because I’ve heard it given as advice in the past, and it is something I’d really like to put in place for myself. The pattern itself reflects on the situation where you learn something for whatever reason, be it for work, school, or personal development. However, without dedicating time towards fully understanding the concept, it doesn’t solidify and you fail to retain the information. The proposed solution is to write. Write as much as you possibly can about each and every part of your journey. Make time for it, because by simply putting concepts into your own words and jotting them down on paper (or on a blog, like this), you etch that knowledge into your head far easier than you would simply trying to absorb the information.

I’m sure we’ve all been in the position where we’ve learned something and then completely forgotten it some time later when we’re meant to recall it. Perhaps on tests, for work, or in conversation. We know that we’re familiar with it, but we seem to fail to remember it fully unless we seek to make it our own, and really feel it out. Take mathematics for example. In order to solidify a concept, you need to learn it and practice its implementation in several ways to really grasp the meaning behind it. Simply trying to absorb the information in one lecture or introduction won’t work for nearly anyone. So why, then, would it work for a theoretical concept in any field, or even something like a life lesson? You need to practice thinking it through in different ways. Writing about things does exactly that.

Part of the motivation behind starting this blog during my Software Development concentration was to have a portfolio to point to that shows what we’ve worked on during our classes. Not only that, but it was a means for connecting with the greater software development community. However I’m finding (through being more consistent with my blogging) that perhaps the most important thing isn’t any of these, and that the majority of the benefit has come through the act of journaling about what I’m learning. Everything I have learned and written about, I feel like know well. Coming from someone who felt extremely awkward about blogging when I started, this was an interesting change of heart — and a welcome one at that.

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

Expose Your Ignorance

This week’s blog is going to be about Exposing Your Ignorance from the Apprenticeship Patterns book. This pattern tackles the problem of not knowing other technologies in the workplace. The people that are paying you are expecting you to know what you are doing at the very least. Your managers and team members need confidence that you can do the job, but you are unfamiliar with other technologies. It happens to everyone. Especially if you are a new hire.

This pattern is very interesting to read. Normally, we do not show our weaknesses to others. We tend to keep it in even when we are having a hard time dealing with something. I would assume it also happens in the software development industry. No one wants to be seen as ignorant and be looked down upon that is why sometimes you try to hide these weaknesses. But this pattern is different.

This pattern suggests that you show what you are lacking.  Telling people what they want to hear is not a good way of building relationships and them having an impression on you. Tell people the truth. Let them know that you are getting the hang of it and are still in the process of learning. Reassure them with your ability to learn and not by lying to them that you know how to do it.

The most effective way to do this is by asking questions. There are no stupid questions. That is what every teacher would tell you. But it is not easy. Sometimes, people have expectations from you and it can be hard to ask “stupid” questions. There is also a sense of pride when asking a question. Sometimes you would look around you to see if you are the only one who did not understand.

I personally have this problem. I almost never ask a question. I always thought that I do not want to bother the whole class asking a question that seems like only I have a problem with. I would usually just tell myself that I would just look it up online and answer the question myself. After reading this pattern, I would definitely try to change that habit of mine.

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

B5: Expose Your Ignorance

          The “Expose Your Ignorance” pattern is described as a way to come to terms with the fact that you won’t know everything in your field. Everything starts as a learning process when you enter a new team. It becomes easier as time goes on and creates a better environment when your team sees you making sufficient progress and growth. The pattern explains that creating a strong relationship with clients and colleagues causes them to grow more interested in your growth as a developer because of the increased efficiency you gain which in turn helps push development even further. Telling people the truth that you’re in the process of learning new skills may make them see you as an amateur but it is certainly better than giving them false promises of creating a finished product on time when you can’t quite deliver on it. This also brings up the point of asking questions, since questions can also show your ignorance but that shouldn’t matter as much since it all is a learning experience. You must ask questions if you plan on putting your pride aside and showing your team that you truly want to learn without taking any shortcuts.

          I found the importance of being honest with your team very useful to expose your skill set to them. The idea of letting your team exactly what you can and can’t do will help them better gauge what tasks they should start you off with to make the learning process easier. I enjoyed the fact that the book doesn’t tell you to shy away from asking questions. Questions can make you seem much more ignorant but the reason why you ask questions is to learn in the first place. This pattern expresses the importance of learning through honesty with your teammates which I will incorporate into my own experiences. The honesty aspect also will help with trust within the team as it shows that I’m not willing to hide anything from them. I overall enjoyed this pattern and agree with it completely. It repeated some very important aspects of teamwork and honesty that I will make sure to never forget.

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

Use Your Title || S.S. 5

Sams Ships (6)Having a software-induced identity crisis? Worry no further, I guess that may be a more common thing than I would have expected! This week’s individual apprenticeship pattern will be Use Your Title.

I thought this was really interesting because there is such a high likelihood that there will come a time when you find yourself in-between positions but called something higher because there was no pre-existing label or category that would perfectly suit you. It may feel weird to have to explain yourself in your title to someone who assumes what you do based on what they see or hear. But perhaps, I wanted to add that I feel like someone could just be feeling imposter syndrome; which is something I heard is common for women in certain career fields tend to feel. What if someone does 100% fit the title they feel that they need to explain their title for but just does not see themselves the way their supervisors do.

I like how this pattern tells us that the title is due to the organization we work for, not necessarily us whether or not it does not match us enough or over-exceeds our abilities. By removing ourself from the current situation, I like how we are encouraged to think how we would view or think about someone’s role based on what they actually did in their job. This perspective was thought-provoking to me because I had not considered

Something I tend to think about is knowing when you need to step out of your comfort zone. When should you move on from one thing to the next; how do you know to take that risk? Seeing the little feature on David Hoover’s actions after he achieved his goals, it was interesting learning how he decided to move forward by continuing to draw his own map.

Overall, the pattern has caused me to think a little more on my intended profession in terms of where I want to end up. Right now, assuming I will have a junior/associate position after I graduate and later become a ‘senior’ or ‘lead’; where would I like to go after that? What will be my ongoing goal?

 

 

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

“Kindred Spirits”

This is another important chapter in software development, chapter four “Accurate Self-Assessment”, they are talking about how we assessment ourselves. “The talented and hard-working apprentice must not become self-satisfied with his success.” We know there is never ending road of learning in this business. We must fight mentality by seeking out and learning about other teams, organizations, journeymen, and master craftsmen. We always to leave room to recognize ourselves if we are going easy way and room to improve.

Again, when we are walking on “The Long Road”, you find yourself stranded without mentors and in an atmosphere that seems at odds with your aspirations. The road is not mean to walk alone, we need camaraderie. It is can be difficult for some people, including myself. The people we meet along the way could make huge impact on us. There are always someone who on the same road, or ahead of us, someone we have career connection with. We can feel free to show each other what you’re learning and have no obligation to follow the other’s lead. We also should be someone who benefit to our community. This is how our industry get to next level with welcome open arms.

The pattern “Kindred Spirits” also suggest that trying to join all the communities you could join based on what you are interesting. Also join new group with fresh open mind. Inside your group, feel free open discussion and become “regular”. I do like this suggestion; I think this is one of the best way to meet new people and learn naturally. This is what I will try to do more, not just get out of comfort zone but surround myself with people with same interest. Be kind to one another is the best way to be a community.

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.