Author Archives: krothermich

Create Feedback Loops

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.

Concrete Skills

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.

A Different Road

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.

Sprint Retrospective

We collectively hopped on a discord call and discussed how we wanted the front end to look and how we wanted it to act.

Created the guest-list component that would be displayed on our ApproveGuestWebUI.

Our sprint team did an exceptional job at coming together towards the end of this semester to put together what we have done. What did not work well originally was the loss of face to face communication. I believe our team did a great job this time around of constant communication and problem solving through discord. I believe what helped us thoroughly with this was the split between the data base and the WebUI. This allowed for Khoa and Tyler to be able to work through any of the problems that arose with the data base but had no effect on what John and I had been working on with the WebUI until the very end in which we needed to communicate between the two. By going about it this way, we were able to make huge progress by bouncing ideas of the other while working collaboratively on our respective pieces. I am happy that I was able to turn myself around from the previous sprint and be able to have an impact on what was created. This also led me to have a greater appreciation and enjoyment on Angular which used to be my kryptonite.

The thing that gave us the most problems and what seems to be the most problems for other teams was running everything inside Docker. Due to people having two different “types” of Docker, one Docker Desktop and the other Docker Toolbar, there were often conflicts. Another difficulty was the communication between the other teams, whereas previously we could simply go over and look at what the other teams were using and developing to allow for us to fit into everyone’s schema better. We had to communicate through discord and on gitlab, which to our credit, I believe was done well.  Nonetheless without face to face communication, there were definitely a few hiccups that were caused along the way.

If we were to go back and do this whole project over again, I believe the biggest change for our team would be where we direct our focus. It was difficult in the beginning to know exactly what is going to be vital, what can hold off and what is needed to be completed in order to move forwards. Towards our last sprint, we were able to get a better grasp for what was necessary, and I believe it really streamlined our progress.

Lastly, if I were to do this all over again, I would try to invest my time better than what I did. Often times I spent too long on something that would not be necessary until much later. I still often hold myself accountable for not contributing as much as I would have wanted but I am able to walk away from this sprint happy with what my team and what I was able to accomplish. The way our team came together in the end for the last push was remarkable.  

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

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.

Study The Classics

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.

Sweep The Floor

 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.

Retreat Into Competence

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.

Sprint Retrospective

This is the guest-approval component that I have been working on with Angular material.

In the beginning of the Spring before moving entirely remote, I believe we had a good plan set in place in order to be able to accomplish all that we wanted to do. Originally, we were going to have John and I work on the WebUI together while Khoa and Tyler would be finishing up with the database and API. We were making good progress until we had to move to remote.

Once I moved to remote, I ran into many problems along the way. The transition into all online classes caused me to lose time towards all of my classes collectively. I had still been working for a majority of the time off and needed to put more time towards my classes outside of school than I had before. From there I ended up becoming overwhelmed by the work. I had to have been doing other schoolwork trying to catch up on everything I had fallen behind on. Once I started working on the approve-guest component I ran into a lot of problems. I had a functioning component before the time of going remote but once I started working on the component again, I ran into a bunch of problems. I was able to get my code to run and load in any HTML editor but once I moved it into WebStorm, there was almost always a blank page. I went through all of the dependencies, created new projects and consulted online with many different resources.  I seemed to be incapable of providing what I needed to for my team at the time.

The only improvement I can say for our team is that we need to be able to discuss more of what is going on throughout the project. We will have to find a way to be able to piece together all of the pieces that we have on GitLab into one project.

I need to put all my effort into this next Sprint because it has not been fair for what I have contributed during this time. I was not as available as I should have been with my team. I also needed to be able to better communicate that I could use some help to get my component back to functional. During the next spring I plan on going above and beyond for my team as they have all been doing an incredible job with this project. I will try to have daily discussions with my team in order to ensure that I stay on track. I will also try to be more active on GitLab with such things as moving the issues to done, approving merge requests or creating new issues. Hopefully this next sprint, I will be able to better estimate how long each problem will require so I can set more time aside for each one. I look forward to making this next Spring into a fully functioning GuestApproval.

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

Sprint Retrospective

Here I am finding out about docker, posted resources to videos for the team.

Created a document that highlighted the key commands that would be used for docker containers and images.

These are the endpoints that I reviewed and moved to done.

From the very beginning of the spring we had assigned everyone an issue of what they needed to start on. From there each respective person worked individually on their assigned task until moving onto the next one. This was working well for our team in the beginning and for me, because I had a higher weight task, because everyone had something to work on. However, once I thought I was done researching docker and creating the wiki for the docker commands, I had run short of things to do with docker. My main task was familiarizing myself with docker but since we were not going to be using docker until at least the next sprint, there was little to do with everything I had just learned.

Another tough issue was the actual design of our endpoints. Our teams had not yet gotten the documentation of what would be stored for information on each person. For our initial design we made simple variables that could be replaced once the correct information was present. Eventually we were able to change into the correct variables with proper documentation.

Our team was very good at coordinating with the others when it came to work on our endpoints. We had originally designed them each with base variables as described before. After the documentation was given, the main problem that arose was the communication between other teams. We needed to understand what we were pulling from other teams and what they would be pulling from us. Our team did well to communicate and document the interaction and solutions on GitLab.

I think something that our team could do better in the division of tasks. For next sprint, as mentioned in class, we will be waiting to assign the next task once someone has completed theirs. I believe this will allow for a smoother distribution of work. Another team improvement, we could have better documentation when working through GitLab. When different people were working on different task, it was easy for the work completed to be missed. It can also cause a lack of understanding through the team if there is not much to go off of.

An improvement I could make would to be to take on a greater responsibility. I need to communicate to my teammates that I need to take on more work than previously because I felt a lot of time was wasted. I have to be better at involving myself in the ongoing process of something new in order to immerse myself, even if it is just to help push someone to the end of their goal. Another change I will make going into the next spring will be better documentation. I posted a document in the wiki for reference, but should be in markdown on the page for everyone to see easily.

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