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.

This pattern is as clear as its tittle. Here’s the context given: you have realized that you’re not the first person to walk the path and that you are spending a lot of time exploring blind alleys. The problem is that you’re walking along a path with no idea of what’s around the next corner or how to prepare for it. You need help and guidance. The pattern doesn’t fail to recognize that our field is very young and therefore has few recognized masters. The solution is then to seek out those who have gone ahead of you and strive to learn from them.

I agree with the pattern because finding a mentor or someone that can supervise the work of an apprentice saves so much time and helps with building confidence. The pattern mentions how hard it is to find mentors sometimes and I can relate to that as I have found myself trying to find a mentor but it has always been hard. That being said, joining online forums, discord servers and being on “Tech” twitter has helped me make meaningful connections. I have come to understand that it is extremely important to find a community and put myself out there.

Another interesting fact they mentioned is that when trying to find mentors, an apprentice must remember that we’re all walking The Long Road and no one knows everything. It can be tempting to feel that your mentor must be a master because they know so much more than you do. That temptation must be resisted, because you do not want to become so disillusioned with your mentor’s inevitable weaknesses or blind spots that you feel you can no longer learn from someone who still has much to offer.

Something to remember is that your apprenticeship is unlikely to happen in isolation, and just as there will be people ahead of you, there will also be apprentices who have not yet reached your skill level. The other side of your search for mentors is that you must be willing to provide mentoring to those who seek it from you. Passing along what you have learned from your mentors is one of the ways in which you can begin the transition to journeyman status.

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

For this week, I chose to read the pattern ‘Create Feedback Loops’ from Chapter 5: Perpetual Learning. The name is pretty self explanatory as to what the pattern will be on, finding feedback on your progress. I chose this pattern because chapter 5 had the best info to digest, in my opinion, because I’m at that stage in my software craftsman career that where these patterns are the most relatable to me and will only prove to be more useful to me as time goes on. The context for this pattern is, not being able to tell if you’re unaware of how unskilled you actually are. By being unaware of your skill level, you are worse at assessing your own skills and when you do receive feedback, it’ll come as a surprise to your self assessment instead of a support mechanism to help you improve. I thought the context of this problem was spot on, the Dunning-Kruger effect came into my mind when I read this, sometimes people are too falsely confident of their own skills and clearly haven’t been told their real skill level on a certain subject matter. Ever since I became aware of the Dunning-Kruger effect, I’ve been trying to be more open minded to discussion and debate if I’m wrong on something.

For the problem of this pattern, it says your self assessment is only relative to the abilities you used opt have, you will always lack objectivity. I was not sure what this meant at first and I still don’t, however the next few parts that it describes I can relate to. It describes how being in a above-average team will make you feel like a superstar when in reality you’re more of a back up dancer, and how being on a below-average team will make you feel complacently smug. I can relate to this because in class, the backend team for the guest info system, they are definitely gonna go far in life as software craftsmen, I feel like they know what they’re doing which in turn makes me feel like I should know what I’m doing but, I’m just a back-up dancer.

For the solution of this pattern, you want to create mechanisms to regularly gather more or less objective external data about your performance. You will also want to be able to process the raw data from these mechanisms in order to get useful feedback about yourself. Honestly, the solution for this pattern was kind of confusing at first, I didn’t understand some of the mechanisms described but I’m sure in practice it is better than it is described.

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

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

The ‘dig deeper’ apprenticeship pattern imagines a scenario where you have familiarized yourself with a number of tools but only enough to be able to implement them into your own system. You do not take the time to properly engage with these tools, and you only ever learn enough about a tool to get through your own individual work. This superficial understanding of your tools can lead to issues, and you may have trouble recognizing and solving bugs that arises because of a given tool. The solution is to take the time to acquire a more in-depth understanding of these tools and technologies. This will give you a good foundation to build off as you learn other tools and will give you a more holistic understanding of the systems you work on. You should learn enough about the tools you used to be able to solve any issues, but you should not completely devote yourself to becoming a specialist in those tools.

I think this apprenticeship pattern is interesting. I am interested specifically in the Hoover and Oshineye recommendation to become familiar with debuggers that show you your running program, become familiar with wire-level debuggers, and be willing to read specifications. I knew that different types of debuggers exist, but I was never sure in what situations you would use them. I should follow this advice and do some in-depth research on at least the debuggers they mention. I also thought it was interesting that they recommend reading through specifications for tools; I do try to do this whenever I am introduced to a new tool.

I am definitely guilty of only learning a tool enough to use it in my own project, but I want to get better about understanding the tools I use. I think the advice in this apprenticeship pattern is very useful in this way, particularly the advice to obtain information about your tools from primary sources. I think being able to read through, parse, and fully understand specifications and defining theses would be beneficial to my career. I would feel a lot more confident working on a system with tools that I can comprehend the workings of. I think this is a good way to develop my skills and prepare for my future career.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

This apprenticeship pattern is all about expanding your knowledge about the tools you use and that if you find yourself in a situation where you are facing problems on the applications and different utilities that you have picked up over time has started to become a burden. This can be due to you using an unreliable source when learning about this product or just not going deep enough into the tool and only using what you needed at the time. This then can lead to troubles when you are put to the test or see a problem you have never faced before. The solution to this problem requires you to go beyond and start looking at the different nuances and inner workings of the programs you are working with.

Here this problem can be seen when you are perhaps interviewed and they ask you about projects that you have worked on. They then ask you about what you did and you can say that, but you don’t know exactly how it works all together, you coded some part of the backend but can’t exactly explain how that section functions. The background knowledge of the project is lacking in areas that could be problematic when you need to work in relation to that knowledge This is a problem and that you should instead take the initiative in understanding more about what you are working with to boost yourself and be prepared for a situation when this knowledge is required.

I myself could devote much more time into learning more about the tools I use and more about the projects I am working on. I could perhaps put some time into learning more on what is going on with the LibreFoodPantry and how the other groups are working to get a better idea of the situation. The job listings and internships out there are expecting more than just basic knowledge of the tools they list and use. There is much more with docker that I could be doing and figuring out issues that pop up from time to time if they are even fixable or not.

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

The sweeping the floor pattern is all about earning your dues. It’s a rite of passage for any apprentice to earn their place in their respective workshops. Over the years I’ve gotten my haircut countless times. In a barbershop, you’ll likely come across a younger individual who all the barbers are always cracking jokes on. This individual also has a very important role to play within the shop. Although the shop’s main attraction is the barbers, the individual or individuals who sweep the floor are the unsung heroes. They allow the barbers to continue doing their work without having to spend the necessary time to clean up after themselves. The work the sweepers do come with a couple of benefits. Allowing them to earn some cash, as well as giving them an opportunity for them to learn how to become a barber. With all the time they spend in the shop, they get to watch closely from the sidelines as the barbers portray their skills. This relationship can also be seen in apprentices who wish to become software developers.

The authors make mention of things you can do in terms of earning your keep at your internship. Picking up the grueling time-consuming tasks that seasoned members of your team don’t like to do or don’t have the time to do is not only a great way to learn something new, but it also helps your team out. Although your contributions may take significantly less skill, your contribution is still valuable. The message here is to make the most out of each opportunity that you’re given.

While I agree that these sorts of things should be taken up during an internship or apprenticeship, I do not believe that taking up these sorts of tasks as an employee is a suitable thing to do. There may be times where picking up less technical work may be necessary, but always taking up these types of tasks on your team could allow your teammates to feel comfortable with giving you bottom of the barrel work regularly, which could speak for how competent your teammates think you really are.

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.

Christian Shadis

In the apprenticeship pattern Use the Source, Hoover and Oshineye explore the importance of learning from reading code from open-source projects. They start by explaining how young programmers often struggle to self-assess their code, since many have not seen enough professional-grade code to understand how theirs stacks up. Luckily, all the open-source code you could ever want is freely available to any developer. Hoover and Oshineye encourage the reader to use these resources as much as possible to gain a better understanding of code inside its context in a working software system.

This pattern closely resembles the advice I recently received from a software engineer family friend. She was transitioning from test automation to full-stack Python development and offered some insight into her job search process and some strategies to use for myself. Her main piece of advice was to browse GitHub for code written by other engineers – open-source projects, employees from the company at which you are applying, or anything else which could prove useful.

I started my Computer Science journey later in my academic career than I would have liked to, having switched into my school’s CS program toward the end of my freshman year in college not knowing anything about the discipline. I am still learning what good and bad code looks like, and how to take the concepts from classes and implement them to scale in deployed software systems. My time in a traditional classroom setting is quickly coming to an end, and I must transition my focus to self-education

I hope to use this pattern throughout my career, but especially so in the first few years. Since I started my CS journey, Git has been a good friend of mine, and I have always been interested in getting to know how it works so well. As such, it would be fitting to start by looking at the code for Git, focusing on the use of data structures. I still feel as though my biggest weakness as a developer is understanding how small microservices and programs interact in a much larger environment. Looking at the source code for distributed systems will give me valuable insight into how the puzzle pieces fit together.

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.