After completing my apprenticeship introduction blog post and two different patter reviews, I am excited to keep reviewing more. For the next pattern from the textbook that I have chosen to review, I chose the “concrete skills” pattern. The book describes a situation in which you are trying to work with a group or at a job in which you do not have a very strong background in yet. This is ofter one of the most inconvenient thing when looking for starter jobs. Most jobs want individuals who have a good background so they know you will be a good fit for the job. The book also supplies us with a great solution to this problem however. Basically, it states that you will have a better chance getting the job if you can prove that what you lack in background work, you make up for in your ability to learn quickly and work hard to learn new things on your free time as well. The more jobs and projects you can accomplish/work on, the better your portfolio and background becomes overtime. Eventually you will find it easier and easier to get where you want to get, and it all starts with your first several projects/jobs. This specific apprenticeship pattern resonated with me primarily because I personally do not have a great background yet and am trying to create a good one. The advice from this section was super powerful, and to be honest, this might be one of the most important concepts discussed in the entire textbook!
This post will be about the “Sweep The Floor” apprenticeship pattern from the book, Apprenticeship Patterns by Adewale Oshineye and Dave Hoover. This pattern is about finding your place on your team, contributing to the teams work to earn their trust and respect, and growing as a developer. The pattern suggests taking on the undesirable peripheral tasks when joining a new team/project. This will help you learn more about the project, development as a whole, and will keep you away from the core of the project. These tasks are often overlooked in education so this can help you fill in the gaps of education while working on something low risk. This does not mean lack in quality though. keep good quality, as bad quality on these portions of the project can become troublesome later on.
There are some problems with this pattern mentioned by the authors that I agree with. One is that you may become the guy who they use to do such dirty work, lacking in opportunity to work on more challenging tasks. Another problem is that you may become intimidated by anything that isn’t the easy yet boring work. Although you learn from this work, there becomes a point where you start to plateau from lack of challenge. The authors solution for these problems are to advocate for yourself and look for every opportunity where you can show them you are capable of contributing to higher tier work. Showing them enthusiasm and skill should make them realize that you are ready and capable to move on to more skillful tasks.
I found this useful because everyone has this starting point where they’re at their first job in a profession and need to gain the trust of their team members. Showing them that you are there to contribute can go a long way and nothing shows that better than when you do the tasks that no one wants to do. Although I already had an idea of this, the book really gave me a solid idea of what to expect to do at my first job as a developer and how to get my team to welcome me.
Breakable Toys is a very interesting pattern. It talks about doing and undoing something. You must learn how to break it in order to unbreak it again and really learn its inner parts and how does it work. As the author clearly states, “failure is merely an incentive to try a different approach next time.” Breakable Toys is more about deliberately creating opportunities to learn by stepping beyond your boundaries and single-handedly building complete software projects.
I´ve applied that pattern repeatedly, sometimes breaking it too much that I would take hours to unbreak it, but at the end, taking with me a greater knowledge. This way I learned computer languages. I have a project with requirements, and I must translate it into code. Nothing works with the first try so you have to break your classes over and over again until you get it right. At the end what you gain is experience in that language and knowledge that you can share and use it in the future.
This pattern made me understand that is ok to break and fail. In the apprenticeship pattern book, in the chapter about the breakable toys, the author writes that Only by attempting to do bold things, failing, learning from that failure, and trying again do we grow into the kind of people who can succeed when faced with difficult problems. I am one of those persons who is afraid to break it because it might damage the whole thing even though it might need that.
Breakable toys is one of those patterns that need to be in your mind all the time. You need to remind yourself that the road to learn something new is not easy and has a lot of failures, but what is important is that you do it with passion. It really doesn’t matter what you decide to do, as long as you experiment and learn.
You can’t do anything well unless you love it, and if you love to hack, you’ll inevitably be working on projects of your own.
—Paul Graham, Hackers & Painters
For my Computer Science Software Development Capstone course, we are reviewing the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. Before discussing different patterns themselves, I would like to review and discuss the introduction chapter and the smaller introductions to the first six chapters of the text. The entire beginning of the book attempts to explain and introduce us to what exactly we will be learning throughout the semester. It goes over what apprenticeship patterns are and where they came from. It tells us what exactly software craftsmanship is and what apprenticeship is. Lastly, it tries to answer the question “what next?” after learning these things. To start, the book makes it clear that there is no simple definition for software craftsmanship (at least how it is using it), and it tries defining it as a “community of practice united and defined by overlapping values.” To see those values, I would read page four and five in the text. Next, the book defines what it means to be an apprentice. It states for the most part that it is the state of looking for more efficient ways or better solutions including looking for better resources to help because anything being done could be being done faster or better. It defines apprenticeship as the state of learning the craft (in this case, software development). In the conclusion of chapter one, the book discusses where apprenticeship patterns even come from and what we should be doing with them. It claims they come from “many working systems that have used the same solution to solve similar problems.” Basically, after learning all of these patterns, I should be able to take what I have researched and mix and match the patterns where I see fit in real life as if I am the apprentice right now and the book is my tool for learning my craft. Before I conclude this blog entry, I would like to briefly discuss the introductions to the five chapters after this first one (especially since I will be reviewing patterns from them over the course of the rest of this semester). Chapters two through six will cover patterns ranging from self-assessing, resilience training, working patterns, working with others, perpetual learning, and constructing my curriculum, etc. I am extremely excited to get into my assessments of these different patterns and learning about my craft. I actually have researched a couple of the subjects covered in these chapters and it is incredibly valuable information for my future as a software developer. I look forward to reviewing at least eight (if not more) of the different patterns and sharing my experience learning them with anyone who will be reading these blog posts now or in the future!
The second apprenticeship pattern from the textbook that I would like to discuss is the one described as “Unleashing your Enthusiasm.” For the most part, the book is trying to say that some students learning software development are not up to speed with knowing all they need to know yet but have great enthusiasm towards the subject. This often times holds them back in succeeding and learning primarily because of others with countering attributes. Many people have more knowledge of software development but much less enthusiasm toward it, and these people sometimes will hinder the success of the less knowledgable enthusiastic learners. The book primarily describes examples of this hindering with the different members of groups having less enthusiasm and not appreciating the ideas of the others. Groups in software development tend to think normally and about finishing their sprints and nothing else. The extra enthusiasm and ideas from the member of the team is often seen as just an annoyance to the other members when they are in a rush to finish their work. The book describes ways of getting around this by talking to people you trust about your ideas and edging them to give their feedback. Suppressing your enthusiasm and ideas is the worst thing you can do because you could have small amounts of knowledge and lose your enthusiasm entirely. Do not let your possibly great ideas go never proposed. It is your job to energize your team and not let them fall into the lapse of simply doing the work to do it.
The following post will be in reference to Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye chapter 1 and the introductions to chapters 2 to 6.
“Most people won’t have an opportunity to work in a formal apprenticeship where they are being mentored by software craftsmen. In reality, most people have to claw and scratch their apprenticeships out of less-than-ideal situations. They might be facing overbearing and/or incompetent managers, de-motivated coworkers, impossible deadlines, and work environments that treat novice developers like workhorses, storing them in small, rectangular stalls with a PC and a crippled Internet connection. (Apprenticeship Patterns)”
This is an incredibly true statement. Due to the current state of the economy, it is very hard for people to gain work experience in any field, let alone in software development. One will frequently see requirements for years of experience in an entry level position, but how can one achieve years of experience if every entry level job requires it? In my opinion, this is the product of many things; moreover, it is an incredibly complex issue, as all issues are. One such thing is the abundance of college degrees. As with many of these possible causes, they are often both positive and negative. Every good action has negative consequences and every negative action has positive consequences.
The positive that comes with the abundance of college degrees is likely self-evident – average people are educated and have more opportunities. However, consider the issue of student loan debt. Many people put themselves into massive debt to get a degree they might not even use. Anyway, it is basic economics at play; you cannot fight supply and demand. The hiring process is simple. Now, the world we live in isn’t perfect but suppose it were an actual meritocracy where everyone has equal opportunities. How can we hire? If we assume that someone who has spent years in college dedicated to studying a topic we work with, we can discriminate based on degree in order to discriminate on skill set. It is important to note that discrimination is not inherently bad. In a meritocracy, discrimination is necessary; in fact, in any value hierarchy where object A has more value than object B, discrimination is necessary. The problem with discrimination is when we discriminate based on irrelevant characteristics. For instance, race has no influence on a person’s ability to be a good doctor. So it is unfair to discriminate based on race when deciding a doctor. However, suppose you need brain surgery and you have the choice of a doctor with twenty years of experience, or a new hire without any experience. In that case, in order for society to function at all, it must be considered fair to discriminate based on experience since that directly affects the chance of success and, in this case, survival. Thus, jobs fairly discriminate based on perceived ability and understanding to find the best for the job. However, the more people that have a degree, the less worth a degree has relative to employment. Having a degree is less of a discriminating factor and so jobs have to create other means of determining skill – hence the absurd amount of experience required.
It is a catch-22; employers use college degrees to discriminate to determine those best fit for their position so average people push their kids to go to college. Then, college degrees become worth less but people still think they are necessary so despite the immense cost, they push their kids to go anyway. Obviously, college is not bad. However, their is a failure to have the necessary discussion with kids. They have to decide whether the career they want is going to be worth the investment. They also need to consider that they might not even find a job in their field after college. It would help the issue if parents and schools viewed college as more of a tool rather than a necessity, and if they introduced kids to trades. Trades also aren’t for everyone, but they are a very founded career path. What society needs overall is a balance and a discussion. In my estimation, the entire education system needs an overhaul; but that is for another blog post.
I would go into the other things I think are causes of such a job environment, but I’ll save that for another day. Instead, I’ll focus on the immense power of environment. First and foremost, people like to view their environment as separate from their minds. However, just think about it. As an example, when you’re lazy, you create clutter in your environment and when your environment is cluttered, it can cause stress or discomfort. Your environment affects your mood and your mood affects your environment, so the distinction between the two isn’t as clear as people might like to think it is. A good working environment is crucial to doing good work. Think back to primary or secondary school and think about the old books and uncomfortable desks with pencil carvings in them. It might go without saying but, if you want to improve your work, put some effort into ensuring your work environment is designed for you to be productive.
“Apprenticeship Patterns.” Accessed February 22, 2021. https://learning.oreilly.com/library/view/apprenticeship-patterns/9780596806842/#toc-start.
The book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye gives great solutions/patterns for problems often faced by software developers, mainly apprentices or beginners of the craft. I have enjoyed reading up to where I have gotten so far (Chapter 1 plus 2-6 introductions) and it has taught as well as clarified many ideas and methods. One thing I have never thought of is how your first language will affect how you will think and learn other languages in the future. While this may be the case, the more diverse knowledge you have, the more you will improve upon this fact. For example (given by the book), people who are more comfortable with object-oriented languages should explore functional languages. This will broaden your understanding and problem solving. Another pattern I found interesting was the Be The Worst pattern. This discusses your environment and its relation to your growth. Being on a team where you are the best or most skilled does not give you much room or motivation to improve as you will not be learning from your peers. It suggests keeping yourself in an environment/team where you are the least skilled. This forces you to catch up to your teammates so that you don’t hold them back as well as forces the habits, ideas, and information of your higher skilled teammates upon you. A few patterns that addressed things I already “knew” but clarified the process at which I should take are Expand Your Bandwidth and Reading List. If you want to be a software developer then you should already know that you will be constantly learning. Expand Your Bandwidth gives solutions on how to learn more than what your job teaches you. It gives examples such as joining online academic courses, following influential developers on social media, contacting authors and more. This gives you a starting point from which you can come up with your own ways of learning or just to boost you in the right direction. The other pattern, Reading List, gives great methods on organizing your book backlog. The first suggestion is to not only keep a list of books you wish to read but the ones that you have read as well. This allows you to keep track of the books you’ve read from which you can review and find gaps or trends in your learning. This can direct you/help decide what you should read next. The pattern also suggests that you keep your book list as a priority queue. If you find a book on a topic that would be more useful or has a higher urgency then put it at the top of the list. If the bottom of the list gets to the point where you will probably never read the books in those spots then thats okay because it clearly is not a priority. I like the way this book structures these patterns too. The authors organize these patterns into Context, Problem, Solution and Action. This makes it easier to understand rather than if they were just put into normal paragraphs.
In reading the introduction to the Apprenticeship Patterns book, I found a great deal of the material to be interesting. Looking at the learning curve of a software developer in the style of the apprenticeship to journeyman to master stages provided a much better framework for progression than I had seen before and putting it in these simple and recognizable terms makes a career feel more tangible. Beyond this, I was quite interested in a couple of the chapter introductions. Chapter 4 focuses on “Accurate Self-Assessment,” specifically the concept of complacency of being a big fish in a small pond. I do a fair amount of reading online about careers in software development, mainly focused on entry-level positions, competitive internships, etc. It stands out to me that many people in the field push and push to start at the highest level that they can, which makes sense in such a competitive environment. Whether this means working at a FAANG company or maximizing total compensation as fast as possible, the focus tends to shift away from becoming the best the one can be and instead on landing in what is generally perceived as the best environment/position. While I can’t say this is at all unreasonable as people have themselves to worry about and not just their software development skills (I know I definitely have this focus too), it can come to the expense of their long-term career. By this I mean we find a place where we want to be in the present and allow this to perpetuate for however long, not to the detriment of our skills as a developer necessarily, but not really broadening our skills either. The book elaborates on this, saying, “You must fight this tendency toward mediocrity by seeking out and learning about other teams, organizations, journeymen, and master craftsmen that work at a level of proficiency that an apprentice cannot even imagine.” This means that getting comfortable is easy, and for most, it’s preferable to be within one’s comfort zone. Getting outside of our comfort zone is so valuable though. I think it’s inevitable to play the game of comparisons with one’s immediate peers, even at our level of being students. It’s saying, “Well, I could go on and learn x, y, and z, but I’m doing better than most of the class at the current topic, so I don’t really need to.” It’s a trap I’ve definitely fallen into. But our class, our little sector of the computer science world is just that: a tiny little sector. It’s more valuable to focus on what we don’t know than what we do know at any level of skill. I love this concept, intimidating as it is, and it provides great motivation.
Software Craftsmanship raises some of the thorniest and most sensitive questions about software development and comes to the controversial conclusion of finding answers in a system that has thrived for hundreds of years: technology. Software Technology is a systematic expression of the author’s ideas and attempts to answer the difficult questions that have been plaguing the software industry. How should we restructure the process of building software, such as we want it to be effective?
The author of Software Craftsmanship has been emphasizing the role of the craftsman in the project. Craftsmen sounds is a very old word, the craftsman in other industries is a what kind of person I want to say, must be done in the field of a good man, I explain the below mentioned software process artisans do what kind of person, craftsman is mentioned there is a very rich in the process of software development experience, after years of development, products are well received by customers, has a certain reputation, they can submit a robust, high quality of the user application. A good craftsman can make or break a project. This shows that the human factor plays a very important role in the development of the project. Someone I have been thinking without learning software engineering in software development has a very important role in understanding of software engineering make me realize software can also like assembly line engineering, development mode, people do not development process, mainly the development process of software engineering control, a relatively fixed process, as long as people do some mechanical work can complete this project. In the current environment, software engineering ideas are still dominant, but software technology ideas also have their base of support, such as workers in the open-source community.
Software technology of the main pressure is a very important role in the whole project, software process is very strict requirements of the team, the team first small number, no more than 15 people, the general team is three people, but for the team of personal ability request, the other teams also are in high demand of health, a more stable team, team members can develop the tacit understanding.
The book Software Craftsmanship gives us a good development model, but many projects in the current environment are developed using software engineering ideas. Why is this? In my analysis, the main reason is that software technology requires too much of the team, and there are too few excellent craftsmen, so it is difficult for many companies to organize such an efficient team. Right now, the idea of software craftsmanship can only be seen in the open-source community, where many of the true craftsmen are gathered.
From the blog haorusong by and used with permission of the author. All other rights reserved by the author.
We are at the point of life that in a few years we all be fully working adults. It is crazy to think that 4 years of college just flew by so fast. This semester the software capstone class will be the most interesting and challenging I believe. When it comes to reading a book, I have no patience at all, but after reading the introduction, something about this book: Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman is making me want to read it appropriately. It is possible to be that I can relate to this book on so many levels and it is relevant to me. After just reading the introduction I feel like it changed the way I think and view my profession.
All the patterns in the book are interesting and powerful in a way that we can adapt and combine these patterns in many ways and situations. One of the patterns that stood out to me the most was “Be the worst” from chapter four. The author has explained the concept very well in which it states that “Surround yourself with developers who are better than you. Find a stronger team where you are the weakest member and have room to grow” This statement Is very interesting and when I think deep into it, I believe that being worst in a team at least for me is a motivation to work hard and grow to improve. The goal is not to stay the weakest but instead work my way from the bottom to the top.
The author also talked about the risk factor that associates with being worst in the team including dragging the team down, good teams do not tolerate you, and the risk of being fired. Although I do agree that in situations all these scenarios could be possible but on the positive side this can motivate a person to improve and build a mindset that helps the individual. I do not think I disagree with any aspects of the pattern but, these patterns and the whole book have certainly changed the way I think about a certain aspect of software development. I realized that I need to work even harder and push myself to the limits for me to get where I want in life.
From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.