Sweeping The Floor Learning Pattern

This pattern is very important it tells us how to begin the career switch from student to paid professional. It is a scary moment of unprecedented uncertainty. It helps us see with a clearer image that there are levels of expectation. These expectations are stratified to build a path to success. It also throws cautionary tales of getting comfortable doing the work at the outer layers of what’s expected.

This is very personal because everyone of us graduating will face the reality of a professional environment. I could not say that it will be harsh or easy. What I can say is that the expectations and anxiety that we generate ourselves is harsh. It makes me feel better to think that the professional world in general has a path in which one can climb, even if this path is steep. The great fear is that there is no path, the goal is the space station, and you don’t know how to build a rocket.

Putting my trust on the writers I expect this sweeping the floor pattern a practiced reality in real situations. I don’t believe there are any menial tasks. All tasks must be completed, and I wouldn’t mind if I had to do some of them or even all of them if it’s all I can do. I have used this pattern in my own life differently. When my car brakes I usually fix it myself because I can not afford the extra expense, this is something that I really don’t want to do. It takes time away from my studies, but it also helps me afford it. Some people say why should they pay a mechanic x amount for only an hour of work but the amount it would take a normal person without the tools and environment would much offset whatever savings they think they had. Most of the time I think if I had the money, I would pay double for a professional to do this for me.

You learn the cost of doing something by doing things you wouldn’t necessarily want to do. Sweeping the floor may begin with doing the easy undesirable work but it must progress into doing work you are uncomfortable with. Success in life comes when you accept uncertainty and never get too cozy as to be paralyzed by extraneous events.      

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

Scrum and I: My First Ever Sprint

                Recently I have had the opportunity to take part in the development of a new piece of software. That software is known as LibreFoodPantry, an open-source tool that is being developed to streamline the day-to-day operation of and record keeping involved in running a food pantry. This is the first real piece of software I have ever worked on with a team and the first real application of the Scrum framework I have taken part in. Being in this unique situation I am inclined to talk about the experiences and difficulties I faced during my first Sprint both to those who may have not used Scrum before and to those who are just looking for something to read.

                From the beginning I and a group of my peers were tasked with creating a secure login service for LibreFoodPantry that would allow users to sign up and sign into the food pantry’s website. This sign on system also had the goal of allowing administrators to log into and manage the website and its users. The main goals then were to create a sign in that both users and administrators could use and having the website display different options based on the role of the user signing on. While nervous at first I found it fairly easy to get behind this idea, especially considering the goal would be to utilize ‘Keycloak’ an open source login service that will take care of most security aspects leaving us with the task of understanding how to utilize it, and configuring it to run with the website.

By virtue of this being a Scrum based workflow, we were left to plan out a backlog of jobs to finish in this sprint as well as hosting regular meetings to ensure we progressed accordingly to the jobs assigned for this sprint. We also needed a Scrum Master to ensure that everyone was able to progress as needed and suggest solutions to any roadblocks that may appear during the development process. For this first sprint I was lucky to be chosen for this position and with that we got to work.  

Splitting those large goals into smaller tasks to put into the product and sprint backlogs generally proved to be easy enough. We then got to work and were each assigned separate tasks to complete. I myself was given the task of creating documentation for each of the repositories while may have created a simple frontend to test Keycloak on. Much of this first sprint came down to research on how to integrate Keycloak with our website and how to allow users to sign up, login, and disallow any use of the site without a login.

                The team worked well together and we made it a point to, at least twice a week, have a meeting to discuss our progress and if anything was holding back our progress on a certain job. From a teamwork perspective communication was solid and any resources found were shared via a group chat should another team member find them useful.

                It became clear as we went on however that we had underestimated the amount of work some jobs might take. Along with this, it dawned towards the end that we do not need to all commit to different jobs, but we can create small groups within our team to quickly take care of larger jobs. All of this really became clear as we neared the end of the sprint and realized that there were still some remaining jobs. I myself found that I was stuck on a single job most of the sprint trying to get Keycloak to work in some capacity and did not get to do any job past that. Along with this I found myself being too immersed in my own work and communicating less than would be ideal especially considering I was suck and could use the help.

                While none of us lacked enthusiasm it was clear that we lacked experience working with Scrum and the Sprint cycle. This however is nothing that cannot be improved upon with due diligence and time.  Scrum in of itself is a self-organizing workflow that sets aside specific times for review and adjustment. Going into the next sprint I can say with certainty that we will perform better and build upon the experiences of our first sprint.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Finding Mentors

We all have people we look up to, those who we see as guiding lights in the unpredictable lives we all live in. These special few, these mentors can be anyone, from friends, to family, to anyone in between. Having a mentor does wonders to the process of learning as well as providing a source of motivation and consultation when you find yourself struggling or at a dead end.

In ‘Apprenticeship Patterns’ by Hoover, Dave H., and Adewale Oshineye we see the pattern of seeking mentorship described in detail. Consider being an inexperienced software developer who has run into dead end after dead end while developing a new piece of software. Often we turn to those more experienced than us for insight into our problems and this case is no different. We seek out anyone who has had a similar issue and ask what they did in that situation.

Finding a master craftsman and learning from them is the goal of all aspiring apprentices and an ideal that we all seek. This however is often very rare today so many of us will find mentors who we can gather advice from regarding their own past experiences. Our field is relatively young and often changing, leaving few master craftsmen to teach those who are just starting out. Along with this many of these masters may not be physically available to you. This is where the mentors arrive to fill in the gaps.

Weather they are a coworker, a dear friend, or an anonymous individual online, a mentor can mean the difference for many software developers out there. They can offer insight on their prior experiences that may mirror your own, expose you to new ways of thinking, or just offer genuinely good advice. It is just another way to break your coding block when you find yourself stuck with a nonfunctional or misbehaving program you are attempting to get working.

With that said however, we all ‘walk the long road’ at the end of the day (Apprenticeship Patterns Ch 3). and finding someone to guide you can be hard so I will leave you with a recommended course of action by the authors. Find a library, or community with an active mailing list and being observing any messages left there. Over time you will pick up on the values of the community and which members are patient and willing to teach others. At the next opportunity, seek them out and establish that first connection with them in order to see if they would be interested in offering any informal advice or lessons they have learned over their time.

Bibliography:

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Week 2: Apprenticeship Pattern Chapter 2

For this week’s reading, I decided to read the pattern ‘The Deep End’ in Chapter 2: ‘Emptying The Cup.’ The context was taking small safe steps has led to unsatisfactory progress and has lead to not a plateau, but a rut. In a rut, it’s worse than a plateau, your competence decays into mediocrity. The problem is you need to progress your skills, your confidence and portfolio. Already, I began to relate to this pattern because I’ve fallen into the trap of being complacent with my skills and not ‘honing my craft.’ It’s a pretty bad place to get stuck in, I really would not recommend falling into this trap. For someone like me, it was really hard to get out of this spot in my life, even now I still feel like I’m plateauing, maybe even in a rut, but the first step to preventing this is to be proactive and push yourself.

The solution was practically the same thing I just said before, to push yourself, jump in the deep end. Basically, try to take the high risk high reward tasks in life that will significantly push you toward a higher knowledge is how I interpreted this pattern. Pushing yourself too hard will only set you back and you won’t have a significant enough takeaway from that high risk task you did. To which I agree with, although I can’t say that I have put
into practice this solution in my life yet. I have been too complacent for too long, it was only recently that I decided to try and push myself. The mental setbacks with myself make it very hard to push through and gain that knowledge that I seek but can’t perserve to but every day I try to tell myself that this is the day.

As for the action for this pattern, it basically says to write your projects down in a chart to path how your career is moving in complexity. At least,
that’s how I saw it. To be honest, I didn’t know what the action meant, I thought it was a second solution but after reading this it kind of makes sense to me but
I still don’t understand it. Perhaps I should put it into practice to see how my progress is going.

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

Craftsmanship Log #1 – My First Language

In the first Craftsmanship post I made, I mentioned that I am reading through Hoover and Oshineye’s book named “Apprenticeship Patterns”, which outlines certain patterns that inexperienced software developers may adopt so that they may overcome any potential hurdles during their personal learning experience rather than providing technical solutions. In fact, in that very post I mentioned (though not by name) two of such patterns, namely “Craft over Art” (introduced in chapter 3) and “Record What You Learn” (introduced in chapter 5). Though I may expand on these two particular patterns in a later post, I want to first address my reactions to one of the very first patterns that are introduced in the book, namely “Your First Language”.

            Briefly put, “Your First Language” is a pattern that is meant to address a software developer’s potential issues that may arise due to the fact that, though they may know multiple languages, they lack sufficient fluency in one of them. As such, such lack of fluency may put the developer in a difficult position when they are needed to work on a project that needs to be in a specific programming language. In this case, the book suggests picking a specific programming language to learn and master, preferably one that is used by any experts one might know. Now, it is important to specify that “learning a language” is not simply achieved by reading some resources related to a specific language, but by using that language to solve problems and actually apply what has been learned. Thus, by continuous application, a software developer may hone their problem-solving skills, which then may help them in learning other languages as well.

            While I personally found this pattern to be particularly helpful when I first started studying Software Development, I feel like my experience has changed the way I approach specifically learning a programming language. Though becoming fluent in a language is important, I believe it is also important to be proficient in the learning process itself. In my case, while I was learning my first language, I also made sure to internalize what that language was composed of in terms of concepts and structures I could use so that, when there is a need for me to switch to a different language, I would have some expectations as to what concepts I should expect to encounter and only worry about syntax while learning the new language.

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

Find Mentors

Self-learning is one important quality of any programmer; however, self-learning is not always useful since the learner might not know what is waiting for them and if their approach is good or not. In this case, every learner needs mentors, those who already achieved what we are working on or at least, they have deeper knowledge about the topic that we are learning.

“Whether a beginner starts out with a training course or is self-taught, the first step on the path to software craftsmanship is finding a craftsman to apprentice himself to”

–Pete McBreen, Software Craftsmanship, p.96

From my own experience, I find this statement can’t be more accurate as I find myself learning more productive when I have mentors to show me what I should do compared to learning by myself. However, as in the book illustrated, as an apprentice, it can be difficult to tell who is truly a master craftsman. Therefore, an apprentice should follow a set of mentors that each one will show them a bit of a huge picture. And the set of mentors here counts not only “real” people who we should have already considered them as our mentors to learn, our friends and our professor, but also the active community we could find online to exchange information with people on it.

Besides, according to what was written in the book, an apprentice shouldn’t expect their mentors to know everything and get disappointed if mentors don’t know what we are seeking for as the current mentors could be other’s apprentice, we are all walking on a long road. Because our field is huge, a person who can guide us through 10 in-built React hooks may not be able to show you how to design the API route and vice versa, these twos are completely different topics and what we probably need is to master a specific set of skills that we desired; but it’s obviously the more we know, the higher opportunities we’ll have.

In conclusion, what I learned from this chapter is that I should find a community and actively communicate with other members there. Luckily, I found myself on a discord channel of one of the biggest Vietnamese tech forums, J2Team, having a community of developers exchanging lots of quality contents.

A channel in J2Team server

Now, I should consider posting my first message here and seeing where it will lead me to. 

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.

Chapter 3: Walking the Long Road

This chapter has talked about how to start your career with low expectations if none at all. For example, Gustav Mahler, musician and composer has talked about the life of Dave in his career. As I paraphrased like this: Dave had his own cubicle and, despite having even less experience than he does today, he kept a stack of certifications by his desk. The stack began with a Perl “master” certification from Brainbench and grew to include certificates demonstrating he had completed multi day trainings in C, J2EE, Vignette, and ATG Dynamo. This modest stack of pseudo parchment comforted him (and his organization) that he was in control of his situation. He’d been “schooled.”

Meanwhile, through http://perlmonks.org and the comp.lang.perl.* newsgroups, Dave had begun to expand out and communicate with the broader developer community. It was in these groups that he met some of the best Perl hackers he’d ever met. The hackers’ knowledge was intimidating, especially because Dave could tell that they were still learning and learning quickly. It seemed to him that he had just begun to scratch the surface of what it took to be a great software engineer. His stack of training certificates gradually vanished beneath a greater mound of scratch paper and printouts of book drafts and lessons during the next few months.

Dave was captivated by the learning process after observing and interacting with a couple of these excellent hackers. Periodically, he’d catch a glimpse of the hackers’ expertise and be either disappointed or inspired—discouraged by how little he understood yet inspired by the force of these hackers’ abilities. He got into side projects and started reading everything he could get his hands on.

The more Dave knew, the clearer it seemed that he still had a long way to go. Over the next few years, he had the wonderful opportunity to work with some excellent software developers face to face. Even though these extraordinary people were miles ahead of him, Dave saw that they were all on the same path.

The Long Road

There are many different patterns that resonate to me, but The Long Road is the best one to me because it explained what type of expectations you should have when you want to be a master software craftsman, but your ambitions are at odds with what others expect of you. Rather than gradually improving your skills, conventional wisdom advises you to take the highest-paying job and the earliest promotion you can get, to stop programming and move on to more important work. Accept the possibility that you will be perceived as odd for what you desire to become. Second, maintain a long-term perspective. Prioritize learning and long-term growth prospects over money and traditional ideals of leadership throughout your apprenticeship.

From the blog CS@Worcester – Site Title by proctech21 and used with permission of the author. All other rights reserved by the author.

Unleash Your Enthusiasm Pattern

This week I decided to read about the apprenticeship pattern ‘Unleash Your Enthusiasm’. The meaning behind unleashing your enthusiasm is that there may be something that is holding you back. Just like the pattern says, you have so much enthusiasm that’s ready to be release. The example that the book uses, is that software developers, you will more than likely be working as part of a team. Usually when working in groups, there is something called a norm which is what everyone follows. No one tries to stand out or if they did, they would find themselves in an uncomfortable position.

My initial reaction to this pattern is that it can relate to more than just software development. It can be compared to the outside world. For example, who you choose to have as your friends. In my instance, I used to have a circle of friends I used to ‘confine my enthusiasm’. Eventually I learned that they were holding me back from furthering my life from being greater. Once I started being myself, things naturally got better for me. My life got overall got better ever since I hold myself back. Just like how some new software engineers that start their first professional jobs confine with the norms. They become held back because they don’t want to speak up and voice their own opinions which then results in them becoming an ordinary worker who doesn’t stand out.

After reading the pattern, it has definitely made an impact to how I view myself working in a professional environment. I tend to be a quiet person when working in teams but lately have been more active and more vocal in the teams I am in at school. By doing this, I believe it will help me get out of my comfort zone and allow myself to ‘unleash my enthusiasm’.

This pattern can be applied to not only for software developers, but to their personal lives as well. I would agree with what have been said in this pattern because the meaning behind it, is to just let loose your ambitions. In order to grow and further your career, you can’t become a person who holds themselves back. There are times when staying in the norm is okay, but overall, it’s better to stand out because that is how you will get recognized.

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.

Breakable Toys- log 3

This week, I read a pattern called Breakable Toys. This pattern occurs when an apprentice needs an environment where the apprentice is allowed to fail and redo his projects as many times as possible. The main purpose of this environment is to make apprentices or software developers feel free to make mistakes and they can learn from failures until they succeed or until they have a deep understanding of a concept. To solve this problem, the author recommends to his readers a solution called Breakable Toys which can be broken many times; and the consequences of the failure will not affect anyone else, except the person playing with the breakable toys. The breakable toy here can be anything that an apprentice can use to practice techniques, try out new ideas, or to learn new things. Furthermore, breakable toys should be relevant and useful to your life, such as building a wiki, calendar, address book, or game. A breakable toy also should be fun to ensure that you enjoy playing with it and can stick with it long enough to learn everything you need and to enhance your essential skills.

For myself, this pattern is really interesting because it is similar to a method I have taken to learn a new concept or to practice a technique. However, after reading this pattern, I think I have used breakable toys to learn computer languages ​​in the past. To learn the Java language, I wrote some programs that are used to manage a coffee shop or a bakery. My programs would take input from the customer to place an order, then print a receipt, but at that time I didn’t know any tools to store those data into a system. Fortunately, I had the opportunity to learn about MySql, a tool that helps me store and manage data of a system. So, I tried to develop those programs to link them to the database in MySql. That way, I can play with the Java language and also gain a deeper understanding of how to use MySql tools. Furthermore, I have also applied the breakable toy method to learn python language. I wrote some of my own games in python with simple ideas after watching a few tutorial videos on YouTube. Although they are just simple games, it is a great environment for me to play with what I want to learn. On the other hand, I can also freely break the code at any time without worrying too much about the consequences. In conclusion, I believe that breakable toys is a good method for software developers to learn and to experience any tools from zero to hero.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

Digg Deeper Learning Pattern

This pattern is a great idea for a beginner such as me. It offers a way to complement the lack of knowledge that comes with the lack of experience. It should be used carefully because of the ease of wanting to just reinforce the skills you are already good at. Knowing a little on a lot of subjects will not help getting things done and knowing a lot in just one subject will get you just as far. The secret as I see it is to have a good toolbox and know how to at least hold each tool. As you need to pick up each of these tools you learn about them more in depth but not too much to hinder your progress. As you shuffle through this toolbox picking up things you need and not obsessing on one tool you build a hierarchy of depth in the knowledge of things you need most. We will handle the same tool more than once and every time we do, we should dig just a little more.

The author presents a more all in version of the dig deeper which I think is the philosophical normalized world idea. It would be nice if we had the luxury of tunnel vision and look for the PhD dissertation of the original design algorithm for every tool we use, but it is also the easiest way to fall into a deadlock. I find that in school it is very hard to get in depth knowledge on every subject as much as I want. Time and time again I see myself compromising and kicking the can down the road, because I do want in-depth knowledge in some subjects, but there are time sensitive co-responsibilities that need immediate attention. Although, as I said earlier, some of these tools that I want to understand better come up again and again over the semesters and I do indeed gain a little more ground on understanding them.

I believe the author is right when he says that we need to learn to dive into ever lower levels of understanding.  By lower I mean from specific to general and by specific, I mean not only the surface high level function you need. The author does throw a little caution which I also mentioned earlier. The risk of becoming what some call a one trick pony.  The balance is really hard to define, and it is very personal. I don’t have my own balance definition yet, but I hope that with time this too will come.

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