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.

This apprenticeship pattern talks about how software developers should jump into the deep end. Many developers take small, safe steps in their career, and this sometimes leaves them unsatisfied. This dissatisfaction could leave developers feeling like they are in a rut, and not just a plateau. When someone is on a plateau, they are consolidating their skills through hard practice in order to reach the next level. However, when a software developer is in a rut, their bland competence eventually decays into mediocrity. To avoid being in a rut or staying in one, a software developer needs to grow their skills, confidence, and portfolio. They need to take on more responsibility, do bigger projects, tackle more challenging tasks, work in larger teams, or try new places.

This apprenticeship pattern discusses how developers should do just that, they should jump right into the deep end. What software developers should not do is sit around and wait until they are ready, that’s a recipe for not doing anything. Instead, when software developers are faced with a challenging role or position, they should grasp it with both hands. This is because growth only happens by doing things that push you out of your comfort zone. If you only do what you are comfortable with, then you are not pushing yourself hard enough.

Of course, doing something like this comes with great risk. If bite off more than you could chew, then things could backfire. This apprenticeship pattern specifically mentions that jumping into the deep end does not mean lying about your qualifications to take a job that you can’t do or doing tasks without adequate preparation. Instead, it means taking on the promotions or the foreign assignments that you were offered. The key is that when taking on a new opportunity, you should assess the risk and difficulty to make sure that your head is above water.

Personally, I think this pattern is something that all apprentices are going to need. Everybody in our craft needs growth to stay on top, and growth doesn’t come without trying new and challenging things. It’s important to take that leap forward if you feel like you’re in a rut. However, when considering new opportunities, it is vital to evaluate the risk. If you find yourself with your head underwater then that means you took on too much risk and you’re drowning. To offset some of the risks, it would be wise to find mentors and kindred spirits who would give you advice and help when needed. It would also be wise to create feedback loops.

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

For this week’s blog post, I took a look at the ‘Craft Over Art’ pattern. Now shifting from how to improve your skills as a developer, this pattern describes using your skills to make something that is useful for a customer. The pattern encourages us as craftsmen to mainly prioritize function over form. As stated in the pattern, “The things we build for customers can be beautiful but must be useful,” meaning one should try to maintain a balance between the two. Customers will usually value a quality working product over something impressive but unusable, so it is important to not put personal interests before a customer’s request. A good mindset to have is to be able to sacrifice beauty in favor of utility.

For the most part, I think that this pattern makes sense. Reflecting on myself, I am usually the type to write code to meet specifications as opposed to writing extraneous code that only does the same thing. The pattern mentions the tradeoff between beauty and utility. There will be times when you make the wrong decision and will need to go back and fix the mistake. As mentioned in the pattern, “fixing that mistake by rewriting the system from scratch may not be in the customer’s best interest. In those situations you will need to develop the ability to refactor and repair.” On the other hand, if you cut corners, you will end up with a subpar product by trying to dish out a program in as little time as possible. With the little experience I have in this profession, I can say that customers expect high-quality code and a fast turnaround time. Making such mistakes can be stressful especially when deadlines are involved.

When writing a piece of software that is useful, it is important to maintain the level of quality it should have. One of the ways I can think of that makes code higher quality is to utilize the principles of clean code. In doing so, I end up writing higher quality code that is arguably better to have than having something beautiful. Having clean code will be beneficial in the long run when I will eventually have to refactor my code. As I continue down this path to become a software craftsman, I want to culminate the skills that it takes to consistently produce high-quality code for customers.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Stay in the Trenches

As you progress in your skills and your career as a software developer, you’ll find yourself in the position of advancing your career due to your successes. You’ll take on a managing position or even a position and find yourself coding quite bit less. You’ll see your path as improving but it’s advancing your career in that company and not in your abilities as a software developer.

It’s imperative that regardless of all duties at the company, you try to stay in the trenches. Keep building your skill-set and training yourself around software development. Your company might not need that manager role in the future, your company could go bankrupt if it fails, you might be put into an even higher position that pulls you even further and further from any actual coding. The path of the software developer doesn’t have to diverge from your career path.

I found this one interesting as it makes sense. I have thought, what do managers of programming teams do in their spare time? I only figured they would take up coding something related to the company or even just taking up spare coding work from other teams. It never occurred to me that someone in that position might take the ramp off the long road of software development and instead focus their career on gaining a higher position in the company that they work in. This in of itself is a perfectly fine choice to make for their career, but the desire to code is likely how they ended up here and I find myself wondering why they might give that up.

It could be a little tempting if I am being honest. It’s kind of strange to me at least that those higher up in the company still end up getting paid far more than those who do the actual work to make the project physical and marketable. At the same time the actual workforce you need to get a project like that built requires several people and if all of them were getting the highest tier of payment then the company probably wouldn’t be profitable. Money in modern days is very tempting as those who have experienced hard physical labor understand how tempting it is to earn a six-figure salary and in essence get paid to attend meetings, write emails, and manage a team of programmers. I don’t imagine myself taking one of those positions though. If I’m not actively doing something while working, physically or mentally, I find myself incredibly bored and frustrated. I don’t think I’ll have many issues if I end up in a higher position. I likely would have followed this principle without even knowing about it.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

My next post is on the problem Sweep the Floor from chapter 4, which has to do with when you are getting started on a group project and want to be able to contribute to the team and grow your own skills. This problem got my interest the most in the chapter because it is a problem that I have when I am in anything that needs a group effort, usually projects, and I think this is a common problem for people. Whether it be a project for school or work, a team based sport, or other activities that involve teams, contributing to the activity and earning trust from your team are the main concerns.

I tend to worry about not doing well and holding the team back, and the solution offered matches what I usually do to prove myself. The recommended solution is to start with the “simple, unglamorous, yet necessary, tasks” and work your way through your tasks to show what you’re capable of. When it comes to contributing and earning your teams trust, the two concerns usually go together because it will be your contributions that help you earn trust, and you can improve yourself as you work and do your share of the workload. The type of tasks you do are also important because what you complete can show your capabilities, and you will want to do some of them that you may not enjoy but are necessary for the project to show you are willing to do them.

While it is important for you to contribute to the team, you want to avoid getting to the point where you end up doing more work than others, or are the only one working on the “simple” tasks that the others do not want to do. Either you are the one stuck with those tasks, or those are the only tasks you are doing and are not doing any of the higher level tasks and can’t improve yourself. It can be difficult to contribute that way, and you won’t learn that much. Team projects can be beneficial to the members working together and improving them all at a higher rate than working alone, but it can also be difficult to divide the work and for new members to the team to contribute.

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

Craft over Art is a drastic change in tone from the rest of the patterns I have covered. All of the previous patterns I have read have been about how to advance myself as a developer, while this pattern is more how to act as a developer. Craft over Art stresses the importance of providing a useful product for a customer instead of a wildly experimental one that might not work. I would argue that this still is about advancing myself as a developer, but in a different, more practical way.

Obviously I should continue to do everything else discussed in these patterns, but I feel like Craft over Art will be the most immediately useful. This pattern can be implemented day one of your first job. It also is the most important pattern for your employer, since they care about actual products. I would imagine many apprentices are very excited to enter the industry and make something amazing, but this is simply not the reality of the profession. Real customers want products that work, do not need complicated maintenance, and are industry standard.

Craft over Art then goes on to explain that when you are rushed to deliver a product you must make compromises between beauty and utility. These compromises will inevitably lead you to a mistake, and you will need to fix it. This is a good thing, the pattern argues, since only by fixing things do we realize which compromises are the correct one.

This idea is a liberating one for me. The fact that I need to mess up in order to learn means that people will expect me to mess up. I feel like this takes a weight off my shoulders. The stress of working on real products with real customers is one I think is very common.

I am glad I read this pattern for my last blog post. I did not plan it, but it was a very nice surprise. Over the course of a semester reading about how I should improve myself, it is a nice shift to learn about how to provide a useful product for my customers.

From the blog CS@Worcester – Ryan Blog by rtrembley and used with permission of the author. All other rights reserved by the author.