For my next post, I wanted to write about a problem later in chapter 3 titled Draw Your Own Map, which was referenced in the first problem of the chapter, The Long Road. This problem is about when you do not fit career paths given to you by an employer, and this problem could be applied to any possible employer. It can be a concern that your skillset may not match what your current or potential employer is asking for and you will either have trouble with the work, or have to move on to a different job. This problem stuck out to me because it is also a concern that I have for when I go into the workforce, that I may not be fit for some jobs that I thought I was. I feel comfortable with most of what I have worked on in computer science and think that I can handle it at an official job, but there are some things I am unsure about, or new things that I may have trouble with.

Going into the solution and action, I like the idea of making a roadmap for jobs that start with jobs that you’re first looking at, then jotting down branching jobs that can stem from it, and repeating a few more times until you want to stop and look at the jobs and how to get to that point. Considering other possibilities and keeping in mind that this is your path to choose will also be helpful. I also like the idea of starting with small steps in your planning and working your way to the bigger goals.

The constant idea to focus on this being your path is especially effective for this problem because the main thing to keep in mind is that this is your skillset and it not fitting some jobs is not a bad thing. I also agree that while you can get help or tips from others on how to decide on your path, it is your path to take and your future to decide on. It will also take time to make your map, and it is expected to be changed and updated over time as you continue on your journey.

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

Christian Shadis

In the apprenticeship pattern Be the Worst, Hoover and Oshineye explore the dynamics of skill level on a team as a software apprentice. They assert that while it may seem counterintuitive, it is a better plan to not be the strongest developer on a team, for that situation yields less opportunity for growth and learning. However, if you are surrounded by accomplished developers who are more skilled, there is far more to learn from them, and far greater space to grow.

Be the Worst, like The White Belt, seems to go against the average worker’s intuition, and are somewhat related to each other. One might think that being the ‘big fish in a little pond’ is a surefire way to distinguish yourself from your colleagues and get promoted, or maybe compete for more prestigious jobs. However, being that big fish increases your chances of stagnation. If you are already at the top, there is nowhere to go, and you may find yourself plateauing as a developer. It is more beneficial to contribute to a big pond and be a little fish, because the little fish can learn and grow more, and eventually start to grow larger than the fish around it, and eventually may become the biggest fish. Combining this pattern with The White Belt by accepting new methods and techniques unfamiliar to you will maximize learning potential at any position.

This pattern is likely to be rather difficult to me, having gone to a small high school and university, and finding myself as one of the “big fish” in both. It would be very unnatural for me to be the worst member of a team, but it would catalyze the learning process and motivate me to become a better teammate (or even the best). In turn, that growth and learning will open opportunities for more interesting and lucrative positions in the future.

I hope to use this pattern throughout my career, but more specifically I plan to implement this pattern at my first development job. I plan to work at a large tech company, and that company likely would hire largely candidates from more prestigious computer science backgrounds, with more dense portfolios and extensive experience. I could perceive this as a disadvantage in the job market but utilizing this apprenticeship pattern instead would motivate me to improve my contributions and prove myself as a competent and evolving developer.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Accurate Self-Assessment. 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.

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.

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.

                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.

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.