#cs-448

The pattern I decided to read is titled “Record What You Learn” from chapter 5 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern starts out by giving context of a situation I know I have found myself in multiple times. This situation is one where I am relearning the same technical lessons over and over again. The proposed solution to this problem is to keep a chronological record of the lessons I’ve learned. This record can be made in the format of a blog or wiki, to name a few options. Additionally, these kinds of records can be made public or private. Public records are good for building connections since others can read them and private records are good for being painfully honest with yourself about your progress. The last section of the solution ends on discussing how your record keeping tool can be an example of a Breakable Toy and how this Breakable Toy can help you extract lessons from it as one grows from a novice to a more experienced developer. The actionable item this excerpt ends with is encouraging its readers to start immediately because these entries can become the basis for books, magazines, and blog posts in the future.

The pattern I decided to read is titled “Familiar Tools” from chapter 6 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The problem that this pattern presents asks the reader how they plan on completing a work project if there are so many new things to learn with each project (from the technical to non-technical aspects). The solution to this problem starts by informing the reader that they should have a reliable set of familiar tools to use for each project they start. However, the reading goes on to explain that readers should be weary about how they use these tools and how dependent they are on these tools. A larger message stresses the importance of how in the process of becoming a journeyman, we may need to painfully abandon some tools and learn new, better, more effective tools in their place. The text ends by encouraging readers to either build a toolbox they can bring to a project, or if they already have a toolbox, examine potential replacement tools.

Reading this pattern was surprisingly encouraging. I don’t think that was an intention of this reading but the reason it had this effect on me was because as someone who is in the beginning of their journey in software development, it can feel pretty intimidating to just be starting out when there are people who have been working in this field for years. And yet, that person and I may be in the process of learning some of the same things today. While the other person is likely to have much more experience in using tools than I am, it is comforting to know there are things we will be learning at the same time.

This pattern has changed the way I think about my work because it has gotten my wheels turning as to what five tools I would like to have in my toolbox and what tools I think I need to continue exploring.

The pattern I decided to read is titled “Expose Your Ignorance” from chapter 2 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern starts with throwing out a hypothetical problem where the reader is working for an employer that is expecting the reader to deliver a product but the reader is unfamiliar with the required technologies. The solution to this problem is in giving an honest response and building a reputation on your ability to learn rather building a reputation on what you know. This pattern also mentions how asking questions is a great way to expose your ignorance because you show what you are learning to your teammates. The pattern ends by discussing how exposing your ignorance is a trait of walking the long road because it means you are open to learning unfamiliar technologies and new domains. Whereas, experts tend to narrow their scope of learning, practice, and projects by specializing in specific things.

There were two instantly helpful pieces of information I gathered from reading this pattern. The first useful piece of information was how as I work on becoming a software craftsman, it is more useful to be known for my ability to learn things instead of being known for the specific technologies I am already familiar with. This piece of advice immediately affects how I think and how I will speak about future projects.

The second thought-provoking piece I read was how becoming an expert is a by-product of the long road I am on. This absolutely blew my mind but also humbled me because I should have known this already since I use a similar perspective for exercising in the gym. My goal of living a long and healthy life means that as a result I will have strong muscles if I am regularly going to the gym. I think one of the reasons this was so striking to me is because I feel like I have such a long way to go before I feel confident enough to call myself an expert in something. Therefore, hearing that becoming an expert is a by-product of the long road showed me how long this long road really is for me.

The pattern I decided to read is titled “Stay in the Trenches” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern spoke about how people often equate being promoted into a managerial role with success but how this can actually take you away from the craft of programming. The pattern goes on to talk about how we should work with our employers to see if they can reward us in other ways that keep us close to the act of programming. Next, the pattern discusses how it is easy to apply this pattern selfishly but that experienced developers will find ways to make choices that will help their co-workers as well. Lastly, this pattern ends with suggesting its reader to come prepared with alternative rewards in case they don’t like the rewards offered by their potential employers, especially if they take them away from programming.

The most thought-provoking piece of information I got from this pattern was the bit about how I should make choices that are in my best interest, but how those choices don’t have to be blind to the needs of those around me. It was interesting to hear this because in a pattern that I’m learning about negotiating and advocating for myself, I’m also being taught how I can still be compassionate to others on my team. This is refreshing to hear because it seems like developing can often be a cut throat and intense environment to work in.

As far as how this pattern has caused me to change the way I think, I would say it re-enforced some of the beliefs I had. In a way, I’ve learned first hand what this pattern has described. I started working in human services as a residential counselor and worked my way up to managing a group home on my own. I learned the hard way that by entering a managerial role, I did a lot less case management and had less time with the individuals I served than when I was a residential counselor. Because of this and some other factors, I decided to step down back to the role of a residential counselor which I personally find more rewarding. This realization I made is the kind of message I got from reading this pattern. If I am passionate about programming, I need to be mindful of the opportunities I may receive in the future and make sure they are aligned with my desire to be a software craftsman.

The pattern I decided to read is titled “Draw Your Own Map” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern was about taking ownership of your professional career as a software craftsman. We learned that in many jobs, you may get pigeonholed to do one particular thing when you may be passionate about learning or doing something different. This passage reassured its readers that they had options and didn’t need to feel trapped, or stuck. By spending some time reflecting  and drawing your own map, you can make career choices that feel empowering instead of limiting.

One of the most thought-provoking points that was brought up in this reading, has been mentioned before and I think I have highlighted in a previous blog post but I would like to reiterate it here because it continues to resonate with me. This pattern mentioned how sometimes it is better to “move into a less hierarchically impressive role in order to stay “on the map.””. Especially if staying on the map is, “more congruent with your goals and will lead you to greater heights in the long term.” This resonates with me because I want to make decisions that are aligned with my goals and beliefs in my professional career, even if that means making some temporary sacrifices.

As far as how this pattern has caused me to change the way I think about my profession, it has encouraged me to either make career choices that open up opportunities or help me  pick a specialization I am passionate and confident in. While my first job after graduation is likely going to be something to get my “foot in the door”, after some time in my first job, it is important for me to spend some time thinking about what the next best step is going to be. My first job is likely going to teach me a lot about what I like and don’t like and it is a place where I can see my interests developing as a software craftsman.

The pattern I decided to read is titled “Nurture Your Passion” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The line that I think best summarizes this pattern is the one that states, “The people who walk The Long Road are not the heroes who sprint for a few years and burn out—they are the people moving at a sustainable pace for decades.” I really liked this quote because I’ve heard so many stories of young software developers who do amazing work at their first couple of jobs, but suddenly stop working because they are not feeling fulfilled. I think part of the reason for that is because many software developers enter the field and work themselves to the bone without really thinking about the “why” behind their work.

The reading adds that the jobs can foster a highly competitive, fast paced, and toxic work environment that further leads to developers burning out. The reading provides some potential solutions to this problem: 1. work on something you like 2. seek out kindred spirits 3. study the classics 4. draw your own map 5. set boundaries

One of the most thought-provoking things I took away from this reading was how by setting boundaries in my first job as a developer, I may get passed over for pay raises, promotions, kudos, or popularity. But on the other hand, by taking care of myself I am less likely to burn out and have a more sustainable career.

Therefore, I would say this pattern has indeed caused me to change the way I think I will work in my profession. While I want to be seen and known as a hard worker, I also think it is important for me to be mindful of how I am working and find balance.

The pattern I decided to read is titled “Craft over Art” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The line that best summarizes this pattern is the one that states how the programs we create can be beautiful, but must be useful. This pattern starts off with a quote by Richard Stallman in “Art and Programming” that defines programming as, “a craft, which is a kind of art, but not a fine art.” This distinction is important because it shows how making beautiful programs is a good thing, but how its beauty should never outweigh the utility of the program that has been created. This pattern ends by giving us two tasks. The first task asks us to find something to do where we can prioritize usefulness over beauty. The second task is a reflective one that has us think about times we have chosen artistry over utility in our craft.

One of the sentences that I found interesting was the one that described how “utility and beauty are not opposed to each other, but interdependent.” This sentence stood out to me because although there is no denying that programs must be useful, it reminded me that I can not completely neglect the aesthetics of my program either because it goes hand in hand with how it is used practically.

As far as how this pattern has caused me to change the way I think, I would say that this pattern has made me be more mindful about the kinds of choices we make in our capstone project. We have already had a couple of conversations around this topic and I’m happy to say that our team has erred on the side of practicality over aesthetics. One of the things we have said in our team is that we should focus on setting the foundation of our project, and if we have enough time, we can come back and worry about our application's appearance some more.

The pattern I decided to read is titled “Concrete Skills” from chapter 2 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern starts off by discussing how hiring managers have no incentive to hire someone who can not directly contribute to a team’s workload. Hoover and Oshineye ask the following rhetorical question from a recruiters point of view: “If we hire you today, what can you do on Monday morning that will benefit us?”. In short, the solution to this problem is to develop and maintain some concrete skills. We learn that with time we will become less dependent on our concrete skills and get hired through the reputation we have garnered from notable projects. This pattern ends by giving the reader a recommendation on how they can begin developing some concrete skills.

The thing I found most interesting from the reading is that at some point in my journey I will become less dependent on my concrete skills. My portfolio and “deeper qualities” will be what matter more. This was interesting to me because in a section that stresses the importance of learning concrete skills in the beginning of my professional journey, I am still getting a message that soft skills are important. This shows me how there is an important balance of maintaining the hard skills I’ve learned in addition to being a team player, having good communication, being empathetic and having many other traits that fall under the soft skills category.