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.

Stay in the Trenches is about how you must stay on your path and focus on learning rather than promotions. If you are offered a promotion which takes you away from what you want to do, you should reject that promotion. This of course does not mean that you should never accept promotions or advancement, but you should always remain focused on what you want to do with your career. This pattern implies that you want to program, and I do, but I can see this pattern applied to many more disciplines.

Over the course of all these patterns one thing has been emphasized more than anything else: as an apprentice, your primary goal should be to learn. This pattern spells that out more than any other. This pattern is a very tough pill to swallow, but it is very good advice. Sometimes you need to be told things you don’t want to hear, and should listen to advice from people who have made mistakes before you.

I like this pattern since I am a very promotion oriented person. I can see myself taking the quick promotion and I needed this pattern to guide me on the right path. Throughout my working career I have taken the promotion when I should not have. This is different from what Stay in the Trenches is talking about, but it shows what kind of person I am. I need to be aware of that going into the future.

One thing I wonder about is when should I take the promotion? You are always able to learn, when have I learned enough? Fortunately I don’t have to worry about this for a while, and I think that it is an easier decision than I’m thinking it is. Right now I do not have the experience to tell what I want to do, and what I’m ok with not doing.

The pattern also suggests that instead of taking the promotion you should work with your employer to find other, more advanced tasks that you can take on. I like this idea since it allows you to continue programming, but it also might not offer the same pay or benefits.

Overall I like this pattern, it is one of the better ones I have read so far. I think my favorite patterns are the ones that tell me things I don’t want to hear; things I already agree with is not really teaching me anything. It is easy to take the advice of work hard, but not so much to pass up promotions.

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

One thing that the field of Computer Science is rather notorious for is that, for new learners, the entry level may seem incredibly low for someone who is interested in pursuing programming in any degree. Given the abundance of freely available resources for learning programming languages, this should not be that much of a surprise. It is easy for someone to find a tutorial online on how to implement inheritance in JAVA, with such tutorial presenting this concept through some oversimplified example. This, in and of itself, is not a bad thing; it is important to learn things in smaller steps. However, some software development apprentices may take to simply memorizing the knowledge they acquire and how to simply implement the tools available to them without much understanding, thus acquiring only a superficial understanding compared to a deeper, more thorough understanding, which in the future may become a habit that can interfere during the development of bigger projects. This situation is introduced as a pattern titled “Dig Deeper”.

What this pattern means for an apprentice developer is that, oftentimes, they may have found themselves in part of the development where their technical knowledge at that point in time may seem to be lacking because the superficial knowledge they have gained during the learning process was not sufficient to provide meaningful contributions in a project of a larger scale, especially in a professional environment. For example, someone who may be working on deploying a web-based application may run into this pattern. The apprentice, though they may know a bit about how REST APIs may work, they may still find themselves struggling because the project they are working on presents concepts that are impossible to cover in a simple tutorial. The apprentice may know how to implement functionality on the backend, but have neglected to get a  deeper, understanding of how such functionality may impact the frontend. Thus, when something in the frontend fails because of the backend, the apprentice may provide a solution that in the long-term does little to solve that problem. Overall, an apprentice who, regardless of their proficiency in their area of expertise, does not take the proper care to understand how such expertise may interact with other areas can hinder the long-term maintainability of a project, as well as have a negative impact on the apprentice’s own learning process.

While it is impossible to be an expert on every single concept and tool that exists ,not only within one’s area of expertise, but also for every single area that may constitute a bigger project, it is still important to take the time to gain a deeper understanding of how other areas work in conjunction to one’s expertise.

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.