Category Archives: Week 8

Be The Worst

Sometimes being the worst is not the worst thing to be recognized as. It can be a scalable thing. In sports for example, being the worst player on the Boston Celtics may seem like a bad position to be in. The reality is that your skills are far more impressive in comparison to the average person who watches basketball, and you should give yourself more credit for even making it into the league. The “Be the Worst” pattern is one that allows those who exercise it to never remain stagnant. While it is nice to admire yourself for all the progress you have made along your journey, you should not bask in these accomplishments for long periods of time.

There have been many times in my life where I’ve felt like I’ve done all that I needed to do and “now I can just chill”. That same attitude has also gotten me in a few binds during my academic career. These things occurred because I felt like I was doing my best at something and would always be the best even if I didn’t continue maintain a certain level of excellence. It seems like the view here is that being the worst is the best and being the best is the worst. In other words, you have nothing to lose if you’re the worst and have nothing but the potential to grow, but if you’re the best then you must maintain being the best and potentially face having to fall from grace.

While I understand the message this pattern was trying to get across, I feel the messaging could possibly be misleading. The author mentions being the worst person in your team that produces good work can “make you feel as if you are performing better” when you could not be performing at all. While I feel like this pattern is helpful for myself, the advice given here should be taken with a grain of salt. To me, the most important part about being the worst is making sure you have the will to become the best and repeat the process.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance Pattern

For this week’s apprenticeship pattern, I did a reading on “Expose Your Ignorance”. A summary of “Expose Your Ignorance” is simply about how you may be unfamiliar with some technologies that are required to do a job and your manager and team members are looking to you to complete the job. At this point you already landed the position at the company but now, you’re required to do a task that requires certain technology like a specific language you’re not proficient in. To counter this, you must show them that learning new technology or anything is part of the process of getting a job done. In this pattern it mentions about how you should be honest and speak the truth to your clients and team members. This would allow them to be reassured even if you do not know the technology right away. If you’re able to show them that you’re learning and progressing, it will build trust and your reputation will be built upon that. Not only that but ask questions. Even though there’s already a presumption that you already know certain things since you’ve been hired, it will never hurt to ask since this is the most direct way in getting a task done and learning. The whole point to this is, to not be afraid of learning and let your team know that you’re learning.

My initial reaction to this pattern is similar to those of the other patterns where I can relate to it. In my capstone class, I am constantly being exposed to new stuff that I haven’t touched or barely learned from the other semesters, and I find myself always asking questions or looking things up on how to do a specific thing. What’s thought provoking in this pattern is how it mentions to not pretend what you know what you’re doing. I believe this is something a lot of people do, and it will negatively impact you more than anything. If you are honest with your manager and team members, they will get a better understanding about where things stand but will more than likely give you a chance to prove that you’re able to learn and do the work. Then if you were to pretend to know what you’re doing and give a horrible product. After reading this pattern, I felt more reassured that it was okay to ask questions and that it was okay if I didn’t know exactly everything. As long as I’m able to show I can learn and do the tasks properly and on a timely manner, I will be okay going into the professional world.

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.

Reflection on The Deep End Apprenticeship Pattern

The Deep End is an Apprenticeship Pattern that encourages software apprentices to take risks, to challenge themselves, and to take opportunities they may not normally take. It makes sure to warn readers that this does not mean that they should jump into things that they are completely unqualified for, or do things with no thought or preparation. However, it is saying that we should be willing to take risks in order to further our learning, and should be willing to try things, even when there is a chance of failure.

I think that this pattern offers a very good way to ensure that we continue our learning, as stagnating at one job, on one project, is no way to continue our lifelong learning, tying into the Long Road apprenticeship pattern that I have discussed previously. We have to be willing to take risks and risk failure if we want to move forward (the same principle used in the Breakable Toys apprenticeship pattern). I also really liked the idea of keeping some sort of record of your own accomplishments, some archive of code we’ve written previously, how long it was, how many group members you worked with, and how large the codebase was. With this sort of history, not only can you track your progression and always look for bigger things and more learning opportunities, but you can also have a record of what you have done that you can go back to in the future, which also follows principles laid out in the Record What You Learn pattern. Being able to go back and see how you’ve changed can be an invaluable tool, and if you don’t risk failure, you will never be able to progress past a certain point.

This pattern has presented a great strategy as to how to keep track of my accomplishments and is great motivation to actually take risks in my professional career. I want to continue to grow my skills and grow, and unless I am willing to fail, I will never get anywhere. As for something I disagree with from the pattern, I guess the only thing I really disagree with is the idea that line numbers and team sizes are the metrics that your career should be based on. I think they can be useful to keep track of and consider, but in the pattern, it is kind of implied that these are the main metrics to measure your performance, and I’m just not sure they are the best ones. Regardless, I don’t think that invalidates the value of the point of this pattern.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Study the Classics

                Often when we as people begin our education in any field we tend to lean either towards readings and studying our predecessors, or jumping into a more practical hands on approach. I myself have often leaned towards a hands on approach to learning. I find myself learning best when thrown into real work rather than boring myself reading textbooks and taking note of the though process of our predecessors. This is exactly how I have honed my craft for a majority of my time as a software craftsman so far. While this method of studying has its merits, it has also hindered my growth by minimizing exposure to the thoughts and theories of others before me.

                Oshineye and Hoover go into detail within this section explaining how and why we ought to delve into the books written by those who came before us. Classics such as Rodney A. Brooks’ Robust, Layered Control System for a Mobile Robot” and Valentino Briatenberg’s “Vehicles: Experiments in Synthetic Psychology” have long been used in the world of robotics and for good reason. They present a series of theoretical ideas and thought processes that yield results that may have otherwise been unexpected. Briatenberg’s Vehicles guides people that are new to robotics into a mindset that inspires out of the box thinking.

Briatenberg’s vehicles are examined not for their capability, but for their behaviors and different configurations exhibit different behaviors. Along with this, one might read Brooks’ work and apply the idea of subsummation to one of Briatenberg’s vehicles. Starting with simple behaviors that are subsumed by higher level thinking can be applied to vehicles to ensure they at the very least can perform certain task such as avoiding collisions with objects while carrying out their main goal.

The goal of these theories and mindsets presented by classic literature is the same as the very text put together by Oshineye and Hoover. It will not directly help with your skillset as a software craftsman, but it can lead to utilizing what you do have in new and interesting ways. An adherence to a certain design philosophy and being willing to experiment in ways that may not have been directly taught to you is important in forwarding your own skills as a craftsmen as well as forwarding the industry when one becomes a master craftsman.

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 pattern: Expose your ignorance

I was reading chapter two on “Expose your ignorance” and got so caught up to it. When working with my team this semester, if there is something that I learned is to ask questions and not be afraid to show my “ignorance” like the book calls it. Sharing and exposing myself helped me understand that we should never feel less smarter than others just because they know better than we do, because learning and knowledge is open to everybody and it is not impossible to reach their level or even better, surpass them.

It can always happen to be caught up in the middle of a project that we do not know anything about. Some people might, and some might not. In that situation, we should let our ignorance awaken our curiosity so we can easily ask questions. People in general hate being seen as ignorant because we always want to show that we have knowledge, experience, skills required for the position or project. So, because of that, we find ourselves faking our knowledge and skills just to impress others. But software development does not work like this, it’s either we know or we don.t because the more we try to hide our ignorance, the more we’re sinking ourselves; And there will be a moment when it will be hard to get out of that place we got stuck on our own.

I love what the author said about the runner: ” She’s not training to have strong legs; she’s training to run. Like the motivated developer who after working on a Python for two years achieves a deep knowledge of Python, the marathon runner’s strong leg muscles are a means, not an end”. Craftsmen need to have the courage and humility to set aside their expertise and wear the “white belt” as they pick up an unfamiliar technology or learn a new domain.

One of the most important traits that a craftsman can possess is the ability to learn, identifying an area of ignorance and working to reduce it. As, software developers, we should not run away from knowledge and being shy or scared to expose our ignorance is not doing anything god to us. I am proud of asking questions and showing that I don’t have or I barely do have knowledge about a certain domain. And it is something that I do even with my team. When I am not familiar with something or don’t know how to do it, I just ask and the one that have the answer will provide it to me and help me understand. This is how I increase my knowledge and skills.

This is where “The long road” will take place. By exposing our ignorance, and then confront it. We will spin the missing threads much more quickly than we will by faking it in order to appear competent. And let’s remember that while we are exposing our ignorance, we are also exposing our team to our learning ability.

From the blog CS@Worcester – Gracia's Blog (Computer Science Major) by gkitenge and used with permission of the author. All other rights reserved by the author.

Be the Worst

When reading this chapter, I found it challenging because I asked myself who actually wants to be the worst? I tried to project myself and put myself in that specific position and I found it very hard to do. However, after second thoughts, deep reading, and analysis, I am very impressed and humbled by the content of this book and this chapter. They say: “You have to be the best”, “You have to master what you do”, “You have to always be the head”. However, we never hear the opposite of those sentences. We never hear: “Be the worst”, “It’s okay to start at the end of the queue”, “We all started from the bottom”. It is discouraging to know that nowadays when working as an apprentice, the expectation and the pressure is greater than the willingness to be understanding and people tend to forget that they have been there once and act as if they were the best from the start.

 There are points the author mentioned that I found important when being the worst in a team. He talks about couple of risks associated with it like brining the team down, the risk of getting fired when falling behind or inability to catch up and feel bad about ourselves. This part tells us that it is a great thing to accept being the tail of a lion. However, it comes with some risks that require hard work and regularly updating ourselves on where am I? Am I making progress? How much time the team is granting me and what happens if I don’t meet specifications? Being the worst is just a way to make us confident in the lion’s den, but we must really be motivated to learn, we must show the desire of doing better, bringing ideas that get us noticed with time.

The last interesting point the author mentioned was reaching out, asking to join a team and observe the team’s dynamics and ways of operation. For me, this is great because it shows the desire for personal growth and the team might be motivated to take you in because you have shown initiative and interest. I feel more confident now to “Be the Worst” in a team of professional software developers because that position will unleash my confidence, allow me to be myself, learn and improve at the same time in my craftsman’s journey.

From the blog CS@Worcester – Software Intellect by rkitenge91 and used with permission of the author. All other rights reserved by the author.

Nurture your passion

There is a saying that “if you love what you are doing, you will never work one day in your life”. Software engineer/developer is a job that requires patience and passion. Without passion, people would easily give up their work.
As I mentioned in “Sweep the Floor”, we need to willingly work the job that no one else would do as we first start to learn and to improve our knowledge. But there is a side effect to that. The side effect is that we work in an environment that stifles our passion for the craft.
In whatever situation, we would always need to look back, take a moment to think of our true passion for software craftsmanship. To become an excellent developer, we will need to have a tremendous passion for what we are doing. However, under some circumstances such as deadlines, corporate hierarchies, or bad management. It is hard for developers to grow under those conditions.
Finding something at work that interests you where you pour time and effort into it. Considering some extra time outside of work to build some Breakable Toys to help expand the knowledge. As Paul Graham said: “The key to being a great hacker may be to work on what you like…To do something well you have to love it. So to the extent that you can preserve hacking as something you love, you’re likely to do it well”. If we do something with love, eventually things turn out really. We build better software with great quality.
Start a weblog and read blogs. Write about the topic that interests you. Doing that also not only helps you to learn new techniques and technologies but also could become your side hustle. Participate in online forums such as Stack-overflow by answering questions that others might have. Read thoroughly others’ answers to learn more about the material with different approaches.
To grow your passion, set clear boundaries that define the sort of environment you are willing to work in. This means in some situations you leave work early, walk out of a meeting that becomes abusive, adjust your attitude, and refuse to distribute your code if it does not meet your minimum. Eventually, the result could be bad for pay raises, promotions, kudos, or popularity. But keeping these boundaries helps to keep your passion strong.
Needless to recite what I have said in the beginning about passion. In my opinion, passion is the only thing that keeps you moving forward, eager to learn, and the desire to explore. You would not need to work a day in your life if you work with passion.

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

Sweep the Floor

Everyone starts from somewhere. Nobody knows what they are supposed to do when they first start to do something at their new jobs. They start from small tasks with little experience to more challenging tasks with better experiences in knowing what they should be doing. Gradually, they become an expert and do their job better. “Sweep the Floor” shows us how developers should lower their expectations when they’re fresh out of college and take on simple tasks rather than picking up experiment ones.
The problem shown in this section is we are pretty much unsure of our place in the new team and the team would not know what to expect from us. This might cause bad consequences due to under-performance and bad communication. The solution for this problem is to willingly take on volunteer work. This does not mean taking on any kind of work but should be the work that improves our understanding of the team, the work, and gain experiences. A great method is to show that we could do a high-quality job even it does not seem to matter in some way. An example of this is one famous for his work as Uncle Bob Martin who volunteered to come into a room and took out the trash. The task seemed unfair and jaw-dropping for such a developer, but this job brought him admiration and devotion. However, acquiring an easy task does not mean that we should skimp on quality which might lead to trouble later.
Another problem is that some people think they are better than others due to their educational background. The hard truth is at the workplace, that does not seem to matter much. Workplace and school are contrasting when it comes to real life. You might do good in school but it does not guarantee you would do as well at your job. Having better education means higher expectations for you on the first day.
Yet, there are consequences for taking on an easy job. We might become the team’s gopher who get assigned the tasks that no one else would do. From that, we are unable to take on more challenging assignments. The better way is to advocate for yourself and look for every opportunity to prove yourself worthy with higher-level work.
After all, we should take on the tasks that everyone complains about, do it and do it well. Because that is the only way to show people that the can-do attitude and exceed people’s expectations.

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

Learn How You Fail

Ingenuity is often misunderstood. It is not a matter of superior intelligence but of character. It demands more than anything a willingness to recognize failure, to not paper over the cracks, and to change. It arises from deliberate, even obsessive, reflection on failure and constant searching for new solutions.

—Atul Gawande, Better

Learn how you fail is the second blog I’ll discuss from the Apprenticeship Pattern book. I’d like to begin this piece with a quote from Morihei Ueshiba: “Failure is a key to success, each failure teaches us something”.  Everyone wants to be successful, but not everyone is willing to accept failure. However, I will add that my greatest life achievement thus far has been learning to accept my failures. This is, at the end of the day, motivation.

Failure, according to Atul Gawande, is unavoidable since it will happen to all of us at some point. I hold the same viewpoint. We won’t be able to learn if we never make mistakes. We are called losers when we fail at something, but victors when we learn from our mistakes. Failure serves as a reminder that we are all the same, and that success is earned through hard effort and determination

It has been the same for me. I accept that I make mistakes and that I have learned from them. I didn’t understand how programming worked well enough. But I learned by doing, and I’ve made a few blunders along the way. I knew that to be an effective programmer, I needed to mix knowledge, attitude, and technical capability with soft skills when I initially chose my future job would be. I needed to apply my talents, which are methods and processes that supply computers with instructions on which action to execute, to prepare myself to be a computer programmer. But the most important thing I prepared for was that I would fail a few times until I arrived at the conclusion that I will be a decent coder.

One other thing that I would like to talk about, is also the solution given to this pattern. It is a good choice that when we are becoming conscious of the things that trip us up, we allow ourselves the choice between working to fix these problems or cutting our losses. I totally agree and for sure that we have to accept that there will be also some things that we are not good at. Also when we encountered by failing this “thing”, it will be a lesson on how to prevent it in the future. Only in that way we won’t fail again. But the most important thing we need to know is that the only thing we learn from is a failure and not success.

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

At Least They Have the Spirit

PREVIOUSLY ON MPEKIM.CODE…

So far, we have come to the conclusion that it is okay to not know everything. It is also alright to even be “the weakest link” of a team. What matters the most is the enthusiasm, the drive to learn more about our projects and programs. For Apprenticeship Patterns, this means that newcomers can be useful to a team if they provide morale and enthusiasm to expose and attack their ignorance.

To start, I believe that the book stating the idea of “repressing enthusiasm when it is not welcomed” isn’t entirely incorrect. However, I do believe that, unless an enthusiastic apprentice is drastically creating dire consequences for the team, then the members with lower morale should lighten up a bit. No one starts out “creating the next Linux”; if seasoned professionals are not held up to these high expectations, then it seems ridiculous (to say the least) that the newcomers will be held to it.

Interestingly enough, the controversial idea of repressing enthusiasm is supported by a factor of the pattern that I do enjoy: the idea of “experiencing diversity”. According to “Unleash Your Enthusiasm”, teams actually have the most efficiency when they consist of members who each have various amounts of experience. “Old farts” who have seen it all will likely be numbed and unaware of an issue that a newcomer will notice with their “fresh eyes”. Likewise, the more experienced will create sorcery, solving programming problems that the newbies weren’t even aware of.

As far as the future is concerned, I can say that I apply this pattern on a daily basis. While the book helps to reinforce this ideology, I am no stranger to “pumping up a crowd”. Unleashing enthusiasm is not only the idea of providing positivity and workplace morale, but it also involves taking the initiative. Even if they get shot down, we should always put our ideas out there – scribbles, doodles and random notes are never irrelevant. Some of the greatest ideas were the result of an accident (caused by an enthusiastic dreamer).

So far, in the grand scheme of my selected patterns, here is what I see as a “list” or “chain”:

  • Find a team that you are the worst on.
  • Discover and acknowledge your weak points.
  • Take the initiative and enthusiasm to work on these issues.
  • Give yourself the breakable toys needed to grow from mistakes.
  • Practice correctly, with feedback from professionals.

In retrospect, I find it amazing to take my previous blogs, and discover a path within them (similar to a graph data structure). Now, we must take the time to implement it….

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.