Category Archives: Week 13

Find Mentor

There is always a good teacher behind a good student and a good engineer needs a good mentor who will help sharpen the skills and knowledge of that person. There is a saying “if you want to go fast, go alone. If you want to go far, go together”. Together with the mentorship, the engineer will become skilled at his job and has solid fundamental knowledge in this field.

By learning from the best, we learn how to become one of them. The apprenticeship will be supervised by a series of mentors who possess varying degrees of mastery. Every master used to be a student and no one is perfect. So keeping in mind that a master must be perfect is a misconception. It can be tempting to feel that way because they know so much more than we do. We must resist the temptation because we would not want to disillusion our mentor’s inevitable weaknesses.

The story about Dave finding his mentor shows us his journey. By sending out a random email to his mentor, Wyatt, he initially did not expect Wyatt’s response however Wyatt did. The effort was a payoff and he earned himself a mentor. What we could learn from this story is that we should not afraid to ask for help because sometimes what the other is waiting for is us asking.

Good mentors are not easy to find and not everyone is willing to open their arms and welcome us as amateurs. Plus, reaching out to someone that we do not know feels intimidating. However, the risk of being rejected is low but the payoff would be huge. Even though that person does not want to become our master but if we are consistent enough, what we could get back is a good friend. Besides taking in, passing along what we have learned from our mentors is one of the ways in which we can begin the transition to journeyman status.

How could we do that? One must wonder

Choose a tool, library, or community that has an active mailing list. Start small by signing up for the list but do not post any messages yet. Gradually, we will understand the values of the community and learn which of the subscribers are patient teachers. Seek out the members of this list the next time we see them and ask if they would be interested in providing us with some advice about the lesson they have learned. As I said above, we might get rejected but the valuable gift that one might earn is a good friend.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

The White Belt

Summary:

The white belt pattern is about learning new things. We have mastered one language or area, now it is time to learn another because being an expert in one language or area does not allow us to grow and widen our capabilities. Pattern recognizes that sometimes despite working hard and giving our 100%, it does not lead to success. We need to recognize that different areas require different methods and approaches which may be drastically different than what we already know. Solution that pattern provides for us is that sometimes we need to clear our minds and start from zero.

Why this pattern?

Ever since freshman year I have been learning Java. First, we did intro to programming, then data structure and then testing in Java using Junit. Along the way I did a little bit of C, python for data analysis, and JavaScript, CSS, etc. for projects last semester and capstone. While working on this stuff I realized I kept using concepts from Java and messing up the code. Even while using mocha and chai testing framework, I kept using testing concepts of Junit. Due to this almost every time I had to revert the code, go read the proper documentation, come back and redo the code.

White belt pattern teaches us to re-assess our knowledge. It teaches us that as computer science students there is always knowledge out there, we can learn and help ourselves grow. As Elon Musk said, “Biggest mistake smart people make is believing that they are smart.” And to learn or acquire new knowledge and skills we need to start from square one. We cannot build a skyscraper on top of another skyscraper. We need to start below the earth, lay down a good foundation and then build on it.

White belt pattern also teaches us to be brave. I personally get nervous and anxious nowadays when it comes to learning a new language like python or JavaScript, software like docker or Kubernetes, services like Gitlab or AWS, etc. Pattern recognizes that sometimes it is painful to start from the bottom but tremendously crucial in accelerating the learning process. Mastering the new language or area is far more important than the short-term loss of productivity.

Where I disagree:

I might be nitpicking with the technicality of the word ‘unlearn’ but I do not think we need to unlearn what we know to learn new things. We do not need tear down a building to build another one.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Retreat Into Competence

For this week’s blog post, I have decided to look at the apprenticeship pattern “retreat into competence”. The idea of this chapter is that you, a software developer, are beginning to realize how little you know, or that you have taken on a new challenge that is not working well in your favor, or your having problems with both. Due to you realizing how little you know you begin to get overwhelmed with your ignorance. The solution to this is to pull back and launch yourself like a stone from a catapult. You need to retreat or take some time away from your task to re collect yourself so you can come back to the task stronger than before. According to Dave H. Hoover & Adewale Oshineye, the authors of the book, they say on this,

“An apprenticeship is a roller-coaster ride. You will experience the thrill of learning new technologies, leveraging your knowledge and creativity to deliver value to your customers. But you will also experience the heart-in-your-throat terror of perceiving just how little you know compared to the craftsmen and experts you meet along the way. It can be overwhelming, particularly when a deadline is looming or when you’re dealing with production issues.” (Dave H. Hoover & Adewle Oshineye).

This pattern is most relevant to people who have stretched themselves to far thin to be able to concentrate on the task in front of them anymore. However, by pulling back you do have the chance to launch more forward than you have been able to before. Note however this pattern does come with risks as if you forget to launch back forward or don’t have the desire to there can be repercussions. I liked this chapter as I am a person who can get stretched thin very quickly and am not able to bring myself to walk away for a bit to recollect myself. I liked that this chapter talked about both the pros and the cons of using the pattern. This will be something that will stick with me while I’m in the field because I am prone to being stretched thin and will sit there and still try to figure out the problem for hours. By walking away for a bit, I will be able to launch forward.   

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Expand Your Bandwidth

Christian Shadis

In the apprenticeship pattern Expand Your Bandwidth, Hoover and Oshineye explore the importance of learning as much new information as possible as a new developer. They talk about how many developers have relatively low understanding of programming concepts when they enter the workforce, and how these new programmers can take advantage of the wealth of knowledge available for consumption. They make the analogy of drinking out of a straw versus out of a firehose – increase the volume of information you consume as much as possible.

This pattern particularly resonated with me. I feel as though I have a very solid low-level understanding of several different concepts in the world of software development and data analytics. I lack that high-level expertise in all the subjects I have studied in the past three years. I have attempted to emulate this pattern before learning about it: I have a shelf stuffed with books about everything from CS basics to networking to Machine Learning, and I do my best to read as much as possible about the subject.

As mentioned in my previous post, I entered the Computer Science world far later than I would have preferred and faced the difficulty of entering a vast industry filled with passionate, lifelong learners as a programmer with absolutely no knowledge of anything related to computer science. I believe I have spent my time wisely, learning lots of information about several different subjects, and managed to build up a solid toolkit before graduating.

I hope to use this pattern throughout my career, but especially so over this coming summer. I will be seeking employment as a software developer or engineer, and I feel as though some gaps in my knowledge should be plugged up as soon as possible. I plan to do a deep dive on full-stack development and connecting the frontend and backend of a system and use my newfound knowledge to do a complete rebuild of my website (ctshadis.github.io) with a proper full stack and domain name. I believe this will require learning lots of new information and applying it immediately in a way that will make me more qualified for any full-stack development jobs I apply for.

Reference: Hoover, D. H., & Oshineye, A. (2010). Perpetual Learning. In Apprenticeship patterns: Guidance for the aspiring software craftsman. O’Reilly.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Share What You Learn

To avoid frustration, I try to keep myself motivated by thinking about the feeling when I complete my task. Along with the feeling of completion, sharing information among people is some sort of motivation that I want to show off every time I learn something useful.

In my view, I am not a beginner applying this method introduced in Dave Hoover’s book since I am not feeling strange when I explain to my mates what I have learnt, instead, I actually like doing it because it is not only a way to help my mates understand the part that I have been working on but also a great opportunity to test my understanding over subject and enhance my memorization onto it.

I started feeling the benefits of sharing information with other people since high school. Back then, I mostly helped my friends when they didn’t understand some math problems in class, and every time I do it, I remember that issue much longer, and I feel more comfortable with the technique used to solve that problem. The more I “teach” them, the better my “teaching” skill and my sense of learning improves as well. As they started counting on me in these difficult tasks, I would perceive the sense of motivation to push my learning into the higher level.

We are afraid of having a conversation about a topic that we do not really comprehend. In both math and code, exchanging information, in my opinion, is an infamous problem since I have encountered lots of people who suffer from it. Coding and mathematics have a similar concept (it is like a feeling, but I cannot think of a more specific word to describe it) that once you understand the flow, solving their problems is utterly attractive. Therefore, besides the benefit of improving my apprehension, I also want to help my friends be able to comfortably debate when it comes to specialized topics.

As we grow, we have less confidence to ask other people, searching for problems online is therefore becoming a more popular approach. Hence, publishing blog posts to share my learning will be my next path to maintain my motivation and improve my understanding. Stay tuned!!

From the blog CS@Worcester – Vien's Blog by Vien Hua and used with permission of the author. All other rights reserved by the author.

Find Mentors

Many apprentices in this craft are inexperienced and have little knowledge of what’s next in store for them or how to prepare for what’s to come. Luckily, most apprentices, are not the first person to walk down the same path, and there are many people who are experienced and knowledgeable who could provide help and guidance when needed. This apprenticeship pattern is about finding these people and having them mentor you in your journey to becoming a master craftsman.

Mentors can be quite hard to find. It may be easy to locate authors of books on the craft, accomplished conference speakers, committers on popular open-source projects, and developers of successful websites. However, it is difficult to convince them to mentor you. They may not be interested, or they feel intimidated by the request. One should expect rejection as a risk. However, the risk of being rejected by a mentor is fairly low, while the payoff is massive. The key when searching for mentors is to be tenacious and appreciative.

One thing to keep in mind when searching for mentors is that it’s important to understand that mentors are also going through their own journeys towards becoming master craftsmen and that no one person knows everything. It’s tempting to want your mentor to be a master because of their vast and deep knowledge of the craft. However, such temptations should always be resisted. You shouldn’t dismiss mentors by over-focusing on their inevitable weaknesses or blind spots, these mentors still have a lot to offer.

Although this apprenticeship pattern discusses a simple concept, it is extremely important. Finding people to guide you in your journey is invaluable. Mentors can help you make the right decisions for you, they can teach you new techniques, they can give you tips about the craft, and they can give insight into what you can expect. Every apprentice should actively look for mentors and learn as much as they can from them. By the same token, it’s important to realize that just as you are looking for mentorship from people ahead of you, there are also people who are behind you who seek mentorship from you. Being able to pass on your knowledge and experience is one of the ways where an apprentice can begin to transition into a journeyman.

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

Find Mentors

Programming alone can be difficult with unclear paths to take with lots of uncertainty about which approach will be the best. Without someone who can give you guidance, it makes it difficult to move forward alone. It is necessary to find a mentor who will be there to guide you in times of uncertainty. The mentor you find does not need to be someone who knows all, but someone who has more knowledge and experience than you in a particular programming area. Finding a mentor requires a lot of searching because they may be hard to find, especially finding someone who is willing to spend the time to help. However, when you find one, they will provide a world of experience.

I found it interesting the author himself found a mentor after a few years of already being a programmer. It shows that it is never too late to find someone who knows more than you and to ask for help. This practice relates back to a previous pattern about exposing your ignorance. You must be willing to do this in order to get the proper guidance.

This pattern focuses on the theme of approaching programming as a craft where you must start as an apprentice. This reminds me of my grandfather who was a carpenter. When he was young, he started small jobs without much knowledge. He learned from the other men on the job who were eager to teach him what they knew. Eventually, he learned as much as they did and in his later years went on to share his knowledge with those who were younger just learning their craft.

After reading this far into the book, I have reshaped the way I view the development landscape. I feel that it requires the perspective of apprenticeship and the need for finding others to help you develop your craft. I think it is possible that at the same time you are being mentored, you can also be mentoring someone else. There are no areas in this pattern where I disagree with the author. I find that his recommendations and personal experience are well thought out and are great advice.

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.

Retreat into Competence Pattern

For this week’s apprenticeship pattern, I did a reading on “Retreat into Competence”. Retreat into Competence pattern about feeling overwhelmed, realizing how little you know about or taking on a big project and things may not be working so well for you. In this pattern it talks about how you should “pull back and then launch forward like a stone from a catapult”. What this means it to retreat to a zone where you’re comfortable with and once you feel ready, you’ll be able to launch yourself even further than before you might have felt ‘stuck’. An example I found from this pattern is pick something that can be self-contained that you know really well and stick with it, by doing this, opportunities will emerge, and it will allow you to capitalize on those opportunities and you will end with great gains.

Unlike my other blog posts, my initial reaction is not quite the same since I have yet to experience this. The closest time I ever felt overwhelmed is just the pressure of trying to find a job by graduation. Its not exactly related to what this pattern talks about but the same concept. For me, it was a matter of constantly getting rejection emails from companies, so I took a step back to look at what I may be missing. Once I was able to go over my resume and qualifications, I started to reapply and now I am starting to receive multiple invitations to take coding assessments and scheduling interview dates. This pattern goes hand to hand with ‘Expose Your Ignorance’ and ‘Confront Your Ignorance’.

The pattern has changed the way I view my profession because I never thought about needing to take a step back in programming. Maybe because I never ran into a situation where I needed to? However, after reading about this pattern I started to reflect on the things I’ve done so far and what else could I do to improve my programming skills and knowledge. I am also trying to figure out what I am really good at so I can focus a little bit more on that skill and work around it so when the time comes and an opportunity presents itself, I will be able to capitalize on it.

From the blog CS@Worcester – Michael's Developer Blog by michaelchaau and used with permission of the author. All other rights reserved by the author.

The Long Road

This week I have decided to write about the long road. As we reach the end of the semester, it seems like a good time to acess the road ahead of me as a software craftsmen. Thus far, I have seen my road as just getting a software job. And everything else was secondary to that. That road included going to school, creating a resume, appying for jobs, studying for interviews, and interviewing. Many of these tasks included programming, but most of this time was not actually spent programming. Now I will be starting my first software job after graduation, and it is the perfect time to consider the road ahead.

Dave mentions that a craftsmen can achieve almost anything if he stays with his craft for 20 years. And that learning is a lifetime skill. He also mentions that the craftsmen should value long term growth over all else, including salary. I have seen online that senior engineers can make comparable salaries to technical managers. So I don’t think that craftsmen need to choose between salary and growing their craft. There seems to be plenty of roles that provide learning oppurtunities, and high salaries. But Dave argues that money should not be the main motivator of the craftsmen.

The action is to imagine my career 20, 30, and 40 years from now. It is difficult for me to say what my career will look like this far out. But I know that I want to work in tech for my entire career. I do know for the next five years I want to work as a Software Engineer. With the hopes of moving from Junior level, to a mid level engineer. From there, I may decide to take on a leadership role, while still focusing on the codebase most of the time. This could be a tech lead, or Senior Engineer role. Twenty years from now, I could either be in leadership, or a may be a very accomplished engineer. It would be very rewarding to be the guy that everyone goes to with questions, and I do like helping other people succeed. So this could be a good path. Thirty years from now I could see myself being a leader of a tech focused small business, or maybe freelancing. Going out on my own is something I have always been interested in. Forty years from now I will be sixty eight. So I will likely be getting ready to retire. But who knows, maybe I will still be coding at that time.

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.

Docker: The Differences Between a Dockerfile, Image, and Container

Docker is a program used to package applications and their dependencies into bundles that can run on any computer. A running instance of the bundle is a container. Docker containers help developers build software by isolating applications, sandboxing projects, and guaranteeing running software. To have a docker container, one needs to write a Dockerfile, build it into an image, and run the image. When I was learning the process, my instructor explained the process and terms by using only an analogy. He compared them to the process of how source files became executables, and then running processes.  Because analogies only help understand concepts (not define them), the goal of this post is to define Dockerfiles, images, and containers as well as their relationships. To achieve the goal, I will be using information from the article, “Differences Between Docker Images and Containers,” written by Eugen Baeldong, an author who has written about software development extensively. His article differentiates Docker images from containers.

The Dockerfile is a text file that contains instructions on how to find, install, and configure an application and its dependencies. In the same way an embryo is a baby at the first stage of development, a Dockerfile is a container at the first stage of development. Some commands that can be used to create instructions are RUN and COPY. RUN is used to install a package or application and COPY is used to copy files and directories from one location to another. With the commands, instructions are created. The set of instructions tell a computer how to find and install the applications and its dependencies.

When a computer executes the instructions in a Dockerfile, an image is built. According to Baeldong, an image is a template for creating the environment one wants. In other words, it is a snapshot of a system one wants. Returning to the baby analogy, an image is a container at the second stage of development in the same way a fetus is a baby at the second stage of development.  I imagine an image as one’s desktop environment. The icons in the environment represent the application and its dependencies in a dormant state. The application is not running yet in the same way desktop applications do not run until one double-clicks their icons.

When a computer runs an image, a container is created. A container is an environment where an application and its dependencies are running. The application in the container is independent from the applications on the computer. In other words, the contents inside a container and one’s computer are unaffected by one another. I imagine it as a computer inside a computer; however, the second computer will not have a graphical interface because it is not necessary for an application to run.

https://www.baeldung.com/ops/docker-images-vs-containers

From the blog CS@WORCESTER – Andy Truong's Blog by atruong1 and used with permission of the author. All other rights reserved by the author.