This pattern discusses the need to have good, quality feedback to allow for personal growth. Often times, the only form of feedback is coming from ourselves and what we have done. As discussed in the article, this can often cause our reflection and feedback to be skewed and biased. If you are on a very good team, it can cause you to either ride their coattails and feel more prepared than you are in reality or cause you to become overwhelmed and feel as if you know nothing. On the other side of the spectrum if you are on a bad team, it can cause you to become complacent because you are able to succeed easily on this team.

The way that this pattern offers a solution to this common problem is to be able to develop a test of actual tangible data that will allow for an honest form of feedback. For example, if you are in team but writing your own portion of code, have another teammate peer review your code. By having another pair of eyes on your own code, they will be able to pick up and point out portions of code that are bad, messy etc. that you would usually gloss over because it was how you had always done it. In a similar manner, if you have any supervisors or managers above you it is always a good idea to be asking for feedback from them. This will not only help you improve your abilities but will also show them that you have initiative to improve yourself.

I believe that this type of feedback is very important to get. Many times, people can become too complacent with their own skills and not try to improve or gain more knowledge. This has happened to me and the main reason I was able to realize my complacency was by working in a group project. By constantly collaborating with them it was easy to see my strengths and weakness and what needed to be worked on. By having the group give feed back and documenting the project as you go, allowed for you to see your progress in a tangible sense.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

This pattern begins by discussing the desire to get into the software development field with the drawback that often times managers or HR won’t hire without experience. To be able to show that you can become an effective member of the team, you need to be able to translate all of the knowledge gained previously into concrete skills. A good way to show these concrete skills is the capability to demonstrate that you would be able to make an immediate positive impact to the team, even if that impact is something very basic. By showing these concrete skills, it will give you a leg up on the competition when hiring.  HR is already taking a chance on you; it is best to show that it will not be for nothing and you are at least capable of something beneficial.

The way to go about this that the article discusses is by going through CVs or anything that shows the concrete skills that well-respected professionals list about them. Then find which one(s) of the skills are applicable to whatever team you are trying to join. From there, work on being able to demonstrate that skill as a concrete ability, whether it be by doing a pet project or simply practicing that over and over.

I believe that this pattern is something very important to learn. As someone who is just getting started into the software field, it can often be hard to even get a foot in the door for some companies. When you finally are able to get in the door, it is absolutely essential that you show that it was not a waste of time. The most successful interviews I have had was when I was put in front of a team leader who wanted me to demonstrate certain skills that would be able to help them immediately. Often times it is simple problems that are needed to be shown, but it is very important to show that you not only understand the problem but are able to apply the solution. A hiring manager is far more likely to “take a chance” on you if they think you’ll be able to immediately have useful, applicable skills for the team.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

Many times the plan that people have laid out for their lives are almost never the same as what actually happens. In this pattern, A Different Road, the author discusses that sometimes it is okay to step away from The Long Road that you were taking to becoming a software developer. This simply means that its okay to step way from this, whether it be permanent or temporary, you should always carry the skills that you learned with you into whatever it is you do next. Then expanding from that, if you do return, you should keep those unique experiences and bring them back into your next job.

This pattern speaks to me personally because I have had many different jobs ranging from warehouses, Dunkin Donuts, meat shops, landscaping etc. The point being is that I have had the privilege to be able to experience this firsthand. Many of these jobs were basic minimum wage jobs that left me desiring for more, and to be able to actually use my brain. However, these jobs all were able to give me something back that I have been able to carry with me throughout my life. For example, most of these jobs gave me the motivation to constantly be trying to reach a better place in life and work. I know how it feels to be sitting in a job and feel like my brain is melting from boredom. Going through these times grants me the motivation to not have to return to them.

The pattern also discusses that often times with a desired job in the software field, HR will see the other jobs as simply lack of experience. However, through the many jobs that I have had it is very obvious to me that this does not constitute for lack of experience because all jobs tie together in different ways. Because I simply was not doing software strictly at the time, does not mean I am not capable of a software job. This is where it all ties back to the pattern. If you are able to take away good, beneficial lessons from where ever you are, you simply have to be able to prove these “skills” to whoever is doubting you.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

The white belt is discussing the situation where you are feeling yourself come into full fruition with your first language. However, once you reach this area it is common to feel that your progress and knowledge is starting to plateau. It often becomes harder to learn a new language per-se when it is easiest to fall back into the one you are so comfortable in. What wearing the white belt means, is being able to fully put aside any of your other knowledge and be able to accept that you are new to this and must re-learn in a new way. By approaching a new situation with a stance of “not knowing” as the pattern says, you will be able to have a broader grasp on the subject. This will also allow for you to be able to progress in the new skill much quicker due to the fact that you are not letting previous, possibly contradicting knowledge of another skill have any affect on your current learning. This is often the easiest way to not feel like you are plateau, but instead staring up another steep cliff of learning. That is how you can ensure that you never stop learning. In this pattern it is worth mentioning that a skilled industry veteran ended up “wearing the white belt” after reading a book that caused him to change how he wrote code entirely. The codebase he writes now he has claimed to be “better tested, more loosely coupled and more adaptable system”.

I find this pattern one of my favorite due to the amount of times I have had to wear the white belt. I began writing code in Java since I was 14-15 and had been my predominant language up until learning C some 5 years later. I originally struggled with C because I had been trying to relate it too much to Java. After viewing it as a completely different world, unrelated to Java I began to have swift development in C. From there I then had to do the same when teaching myself Angular. Angular was different from anything I had done before but again once I started to view it as such, my progress was much quicker. I even had ended up deleting a large portion of work with Angular that had taken me about 3 days to learn how to do. However, since I deep dove into learning everything about Angular, I was able to recreate it within 2 hours the next day.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

This pattern begins by discussing the fact that many experienced developers will often refer to older books that are assumed to have been read by any developer in their position. If you come across a situation in which you are unaware of the book being mentioned, you should make sure to add it into your next books to read. Often times these old books contained outdated technology but certain ideals and basics behind them never change. You have to be careful though when going into the so-called classics of software development. You must be able to distinguish which books no longer have any benefit as the technology has changed so drastically or is not even still used. However, if you run into a software developer that has a book that seems to be too outdated to still be relevant, you should open a conversation with them to be to get the reasoning behind the book and potentially add it to your reading list.

What I found interesting about this was that often times in classes you do end up reading articles that are from over 15-20 years ago that still hold true. I believe this to be true because of the nature of computing, the basics almost always remain the same, people have just become cleverer on how they can be manipulated. By being able to look into the beginning of how a certain software was created, it can also give insight on how the current version of the software can be improved. Often times when adding to software they are looking only at the most current forms of it, when looking further backwards could also prove beneficial.

I think this pattern has pushed me to start to try and expand upon the books that I read for whatever happens in my path towards a career. All too often, I glaze through texts not fully absorbing what is inside. The times I have genuinely studied the texts and books I was given, I found that I was able to massively expand my knowledge and it really comes down to commitment. I agree with this pattern because they also mention that not only should you keep up with the classics, but you should be mixing in the most modern books as well to always stay up to date.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

 Often times when you are a newcomer on a project, the team does not know your capabilities and does not know your worth. It is vital that you show your value in any means possible. This is often accomplished by taking on the unglamorous tasks but preforming to the highest of your ability. Since you are new, the team can not immediately trust you to be thrown in the midst of the project as it can often be dangerous without understanding the full scope, depending on what is being worked on. By completing these seemingly meaningless tasks to the best of your ability, it will help to prove our worth to the team. Eventually, all those “meaningless tasks” will be vital to the project and if the team is able to see them done to highest quality, they will be able to incorporate you deeper into the project.

I find this pattern to be one of the most useful patterns I have read, not only in the computer science world but in life. Often times when starting any new job, you are given the low-end tasks. When I was working at a grocery store when I was younger, I was given all the tasks of taking out the trash, cleaning the floors, and a lot of other unpleasantries. However, I was always on top of these and never had to be asked for them to be completed. In a short time, they had moved me off of these tasks and onto managing the next person who would be doing them. By simply proving my worth early on, in what seemed to be meaningless tasks, I was quickly able to gain my teams trust.

I think this pattern simply reinforces the mindset that I have always had whenever you are beginning something new. Often times people will come in with their head held high because they were considered extremely competent at their old work. However, if the new team you are a part has no reason to respect you yet and you come in with an arrogant attitude, that will cause the team to immediately not respect you. You must always put in the grounds work in order to start to build anywhere.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

Often times when moving forward in your career, you will end facing many different projects that can seem overwhelming when you do not have the full grasp on it yet. This can cause people to shutdown due to their sheer lack of motivation after being discouraged over and over. This pattern says to help fight this type of interreference, it is also okay to Retreat Into Competence. This is essentially moving back onto work that you are confident in and able to complete easily. This will allow for you to gain the needed confidence and motivation in order to start working on a harder, lesser known task. However, you can not retreat into competence for too long or the dread of restarting the hard work will outweigh the problem prior.

I find this pattern to speak to me in many ways. Often times I feel myself overextended and worn out from trying to learn a hundred new things at once in order to complete a certain project. When this happens, I tend to get discouraged easily once things start to fall apart. Thankfully, I had realized how useful this pattern is without knowing it existed. When this happens, I will always tend to move back to a smaller easier project to complete before returning. The pride of accomplishment allows for me to get back into grinding on the harder project.

I believe reading this pattern helped to reinforce the idea that returning to something more basic is not always a bad thing. Often times I will feel like I am wasting my time on simpler tasks, so I move to the harder ones but end up accomplishing neither because I lack the motivation for the harder task. From here on out, I plan on using a smaller, more well-known task as a way to kick start my work and allow for my confidence to grow. From there I believe it will end up becoming much easier for me to take on these large-scale tasks while still also being able to feel like I am continuously accomplishing something towards my goal.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.