Category Archives: Week 11

Apprenticeship Patterns: Chapter 3

Sustainable Motivations

At some point while developing your skills while working on a project or a job, you’ll find yourself primarily focused on your current skills or focused on your work. During this you might find yourself in a bit of a rut and a lack of desire to continue working on those projects. Though you might want to take a break and try something new, you find that the project you are working on is paying the bills or giving you the validation of your skills. The conundrum comes down to do you keep at it even though your work is draining you, or do you strike out on something new to hone your craft.

Now obviously you need to continue your work, but you don’t need to be trapped by it. You can always on your own build something that you want to rather than something that you have to. In your job you may find that its not improving yourself and become monotonous. Nothing is stopping you at home from taking up a personal side project to grow yourself.

The thing I primarily learned from this pattern is the concept of the golden lock. It never really struck me before. The idea that my own motivation to work would be the one to lock me in place and prevent me from progressing. When thinking further, it does make sense. You have a motivation to work because it provides you with income or a status on showing your skill. Simply placing yourself into that mindset will lock you into that position and you’ll never make the time to improve yourself. That little golden latch holding you in place because this is what’s advancing your career. Your career is more of a side note to your progression as a software developer, its not the primary driving force. Your job is a job, but there might be something else out there that you can hone as a fine skill that barely anyone else can and could even lead to a new field you never considered for your career. Your passion for learning programming cannot be tied to motivations to complete your work.

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.

“Sustainable Motivations” Apprenticeship Pattern

Summary:

This apprenticeship pattern deals with the practice of working in real-world projects that may be rigorous, frustrating, or exhausting such that it makes the Apprentice question his motivations in the field. There may also be employment issues, bad leadership, or bad co-workers. Whether this programmer hates the job but desires a good income, is in a hiatus for his love of the field, or works on open source projects for a reputation.

One of my greatest fears in my career is a lack of interest in what I’m required to do. If I work at a company that shifts my work into something that I have no interest in or is very different, I run a real risk of burning out. Although, my favorite element of Computer Science and of programming stems from a certain love of creating things, a type that is not universally palpable in different fields. Hence, even though I don’t have a lot of peculiar interest in, say, creating a website, I’d do it if I need to and I’d probably enjoy doing it. 

I don’t agree or disagree with the action recommended in this apprenticeship pattern, however I feel as though more could be done in a situation like this. On top of writing the things that motivate you, you should try to think to yourself why you are motivated by the things that motivate you, and what is the common connection between all of them that acts as the catalyst. It may be that your motivations are either inconsistent or are the way they are for the wrong reasons. Shifting motivations to be more realistic or to make them fit more appropriately for a given situation can be very useful. On the other hand, if you’re in an untenable situation where you may become burnt out, forcing yourself to be in that situation while attempting to justify it may be harmful.

This apprenticeship pattern has at least caused me to be more aware of a situation that I may be befallen to in my future career. It may be better to move projects or companies if I’m in a situation where I may be burnt out working on something that I don’t like, whereas I could take some initiative and move to where I feel I’d be better suited.

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

Apprenticeship Pattern “The Deep End”

This apprenticeship pattern describes how we should approach our careers when we are put into a situation where we feel like we are stuck and don’t know where to go. This situation is different than plateauing where you know don’t know what to do next but still need to grow our skills in our career. What we need to do next is to “Jump in the Deep End” and take on situations that make us uncomfortable with the likelihood of failure. They give us an example with Enrique where he was stuck with working at a place where he didn’t feel like anything was being done with his life, so he took a leap of faith. In that leap of faith, he ended up in Nigeria where the original plan failed but was able to come up with a new solution. This story sets an example of how if we don’t try and fail then there is something we are not doing right. To avoid trying to be stuck in a rut, maybe we can try taking the work we’ve done and comparing it to one another so see where our careers are heading to and to maybe see what we can improve on in the next one.

What I’ve taken from this pattern is that we shouldn’t be scared from taking a leap into uncharted territories. If we have not failed then we haven’t attempted anything that’s been worth while for our careers. Being stuck and not doing anything about it would result in our careers being at a complete stand still and not a plateau. Growth only happens from taking on projects that are scary and will push you to your limits, and it’s that kind of work that will push you out of being stuck. When faced with a situation where you fail, it might open the doors to finding a new solution that you might be able to recognize.

This pattern has made been insightful in how I should approach the future when I feel like I don’t know what to do in my career. It has also reminded me of time’s where I have been in ruts at the places where I have worked. In those situations I have felt as though with the work I was doing, there was nothing more than I could do and I was just comfortable doing what I always did. Not once did I even jump into the deep end and allowed for myself to be at a stand still for too long. If I jumped into the deep end at least once, I would have gotten out of there earlier.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Record What You Learn

You should not also underestimate the power of writing itself….You can lose your larger sense of purpose. But writing lets you step back and think through a problem. Even the angriest rant forces the writer to achieve a degree of thoughtfulness.

—Atul Gawande, Better

This pattern grabbed my attention. It looks interesting, as most of the patterns in this book. Apprenticeship Patterns is a book that in a way, teaches and gives more lessons on how to be a good software developer. In relation to the title, we are also every day recording what we are learning, not only by writing the blog posts of this special book, but even in all the sprints, we are working on GitLab, by solving different issues. All this time we are recording what we are learning.

When I started my studies here in the US, the first thing I faced that was totally unknown to me was the way of teaching and how the class organization works. Firstly, it looked like something I won’t learn, but at the same time, I was trying to fit in with everything. After some lessons, I understood that the professors here try to help with learning, based on different methods of teaching and sharing the materials for the students and making those materials understandable in different ways. The first thing I noticed, was the organization of the class into groups, after that, I remember last fall in software process management we worked on some cards, by using Flowban (Kanban Simulation). Another thing was the blog posts using WordPress, and the last one is the sprints we are working on Software Dev Capstone, as I mentioned before.

The flow ban cards for me were unfamiliar. It was something we were only learning in class, but at the same time, we tried to work for them. Then I understood that we needed for our future job on the companies we will be working on and that its role was to help the teams identify bottlenecks in a workflow process of work. Later on, regarding blog posts, I understood that their role was in one way to make us record better what we are learning during all classes. And also last but not least is the Capstone class that prepares us for our future job. During this sprint, we are working on a software project and learning how to manage it by sharing areas it works in companies.

Atul at this pattern gives some different solutions on how to record while we are learning. But the one I apply for is having my own private records. Perhaps writing everything in my own notebook is something I used to have since I have studied in my country. But it is something that helps me express more what I think than writing on the computer. And I think a notebook will always be the only secure resource, where I can record what I am learning.

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

Reflection on the Learn How to Fail Apprenticeship Pattern

The Learn How to Fail Apprenticeship Pattern is a relatively simple, and yet extremely important pattern to keep in mind at all stages of your professional journey. It states that we should learn what we are not good at, learn where it is that we fail, and learn what parts of that failure are worth learning how to fix and what failure we must just accept as something that we aren’t good at and move on to improve the things that are worth improving. It is about learning what behaviors, conditions, or habits lead us to failure, and learning how to get around them or just accept them for what they are.

I really liked the idea that they brought up about keeping a list of your skillset in your own personal wiki, that way you can always see what skills you have, and what skills you are losing over time. This way you can choose what is worth continuing to work on, and which skills are no longer useful to you. This is such a pivotal step to continuous self-improvement and learning that is a common thread throughout all the apprenticeship patterns. We need to be able to identify our weaknesses and learn why they happen so we can improve, and I think this is a really good way of going about it. I also really liked their action plan, writing code in a simple text editor, writing tests for it, and revising it without ever compiling or running it until it is perfect. I thought this was a really good way of testing yourself and finding the weak points that will follow you throughout every project you work on. I know that I have some weaknesses in my knowledge base, and some habits that will lead me to failure and moving forward I would like to take note of them and work on them as they come up in the future. I accept that failure is inevitable, but continually working on those failures and allowing myself to learn from my mistakes will make me a better developer.

If I disagree with anything in this pattern, it would be that you should drop things that would take a disproportionate investment of time and effort to accomplish. I think that sometimes, even for a little improvement, it is necessary to sink way too much time and effort into certain things that are fundamental or are extremely important to a project. Not all the time, but it is important to be able to make that distinction for yourself and figure out what is really needed to improve, regardless of the cost.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

The long road

Warren Buffett once said: “The stock market is a device for transferring money from impatient to the patient”. However, I’m not going to discuss stock trading or how the stock market work. This post will concentrate on the similarity between the stock market and software craftsman is patience.

The world that we are living in focuses on overnight celebrity and ephemeral success. The majority of people these days talk about quick rich schemes. Developers back in old days were passionate workers who loved their jobs and dedicate to them. Developers nowadays get into this field because of the tremendous total compensation at big tech like Amazon pays their engineers up to 200 thousand, Netflix is 400 and Roblox is 1 million.

The problem is developers aspire to become master software craftsmen, yet the aspiration conflicts with what people expect from them. We are blinded by the money and promotion package. The job once was to deliver quality and secured pieces of software. But now we tend to distribute soon enough to secure that bonus or to meet the deadlines which allow us to have those bonuses. We sometimes sleep on the job and forget our purposes.

So, what is the solution? Be an outsider. Thinking outside of the box. Focus on the long term rather than get rich quick scheme. Value learning and long-term growth opportunities over salary and traditional notions of leadership. The outcome would be better with a rich set of abilities. We eventually become skillful at learning, problem-solving, and developing healthy relationships. We should keep in mind that it would be a long journey hence we should have low expectations and let them influence the jobs we take and drive the ambitious. Have a strong mindset and “can do” attitude.

With the entire career devoted to the craft, it becomes realistic rather than vain to think about surpassing Bill Gates or Steve Jobs. The opportunities will open as the time comes and we should make sure that when it comes, we will be ready. And the important thing is to love the work that we do, do it with our heart and passion.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

Rubbing Elbows

Rubbing Elbows is very closely related to Kindred Spirits. The idea is to actively observe the way people around you work, and to seek out people you can learn from. Most of the pattern is centered around pair programming, and it is certainly a very good example of Rubbing Elbows. When pair programming you want to find someone more and/or differently experienced from you. This will give you the greatest opportunity to learn; if you only stick with what you know and are good at, you will never grow as a developer.

This is actually something I am very excited to do. When talking to my classmate about potential job prospects, he suggested to me that I should do a remote job. I am very against this idea. I want my first job to be one where I am physically in the office surrounded by other developers who can help me out if I need the help. Pair programming is something that really appeals to me, especially if my partner is more experienced than me.

I worked at an internship where I was the only programmer. There was one other older guy who did programming, but he was mainly an engineer. I tried my best to learn from him, but the environment was not a professional development one. Working alone, I was not able to consult other people and could not determine if what I was doing was correct.

I cannot wait to enter the workplace and learn from other people. Rubbing Elbows is a great pattern, but honestly did not do much for me. I already wanted to meet people and learn from more experienced developers. In fact, when I wasn’t able to collaborate with others was the worst feeling ever. I think that I did good work, but cannot know until other people look it over.

My biggest fear as a developer is doing things wrong. There are many ways to develop software, and there are many ways to mess it up. I need the guidance offered by others; maybe not explicit guidance, but guidance nonetheless. Having someone to consult and learn from is one of my main goals as an apprentice. I am so new that I do not know what I don’t know. Rubbing Elbows with more experienced developers will help me along my path.

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

Kindred Spirits

Kindred Spirits seems like a good pattern if not taken forcefully. This pattern is all about joining a community of developers who have similar interests and/or skills to you. As an apprentice, your main goal is to learn. Working in a professional environment will not always provide this environment, and the mentors you gain along the way will have their best interests in mind – not your own. This is why it is important, as an apprentice, to seek out communities that you are drawn towards because they all have the same motives as you. The goal of these communities is to learn and experiment, and they will be the best place for you to do the same.

To be completely honest I had no intention of doing this prior to reading the pattern, and still am against it. I get why it is good, and I am not against having friends of course, but I am not sure I want to join a community. I guess the point is that you only go when you want so I could just abandon a community I don’t like. Like I have said in previous blog posts, I do not want to focus on programming as a hobby. I do enjoy it, and I am not against joining a programming community if I want to, but I am not the type of person to code for fun all the time.

That being said, I do see the benefits of Kindred Spirits. Of course it is good to have friends in the industry with similar goals, and I do plan on making friends. Having someone to talk to about something I am working on will give me a new perspective and may solve a problem, and helping someone else will test my knowledge on what I actually know. They say the best way to learn is to teach, and to have someone ask me a question I supposedly know the answer to will help me as much as it helps my friend.

Overall, I do like Kindred Spirits. Friends and community are always a benefit. I don’t like the feeling of being forced into friendship and community, but I don’t think that’s what the pattern is saying. I believe it is saying to keep yourself open to new opportunities, find people who you get along with, and use your fellow apprentices to your advantage.

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

Confront Your Ignorance Pattern

For this week’s apprenticeship pattern, I did a reading on “Confront Your Ignorance”. Confront Your Ignorance is about how to start the process. What I mean by this is to pick a tool, skill, or technique and use it to fill in the gaps of your knowledge about it. Confront Your Ignorance is overcoming your lack of knowledge in an area and doing your best to learn more about it to become knowledgeable about it. This pattern ties close together with Expose Your Ignorance pattern. However, implementing this pattern is a bit more doable since it is less of a challenge on your pride since it can be done privately. Other solutions besides learning on your own would be to ask your mentors or anyone that you know that may already have the skill and is willing to share what they know.

My initial reaction after reading this pattern is that it is a reflection of what I am currently experiencing. I have mentioned before that I have limited experience in the professional field of software engineering, I am constantly trying to fill in any gaps of knowledge to make me more of an ideal candidate to companies compared to those who have multiple internships under their belt. The reading was quite interesting and very useful. Interesting because I can relate to what it is talking about and useful because it helps me with my current job hunt and figuring out ways to tackle this issue. Even before reading this pattern, I’ve been trying to find ways of attaining skills and knowledge that I haven’t gained before.

The pattern has not changed the way how I view my profession because I know going that transferring from school life to being a professional Software Engineer, there will be a gap of knowledge I won’t have. I know that I am going to be required to research and learn new things in my career. Therefore, I am constantly practicing my skills and working on side projects to help myself get a good grip on how each technology works and how to incorporate it in what I want to do with my professional career.

From the blog CS@Worcester – Michael's Developer Blog by michaelchaau and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Concrete Skills

Christian Shadis

In the apprenticeship pattern Concrete Skills, Hoover and Oshineye explore the importance of developing discrete, demonstrable skills with specific technologies. This is an important pattern to implement as a young programmer because often in the hiring process, your skills are often more surface-level, and your value lies in your potential. Developing concrete skills makes you a more valuable candidate and thus more likely to receive an offer.

This pattern makes a lot of intuitive sense. My skills (outside of specific languages) are top-level, and I do not have a lot of projects to demonstrate specific skills and value that I can immediately provide to the company/team I am joining. Currently, my appeal as a candidate lies primarily in my successful academic career and ability to quickly learn, and secondarily in the skills I already possess. In order to successfully find a job, supplementing my portfolio is necessary.

This pattern coincides well with the Breakable Toys pattern in that building those personal, low-stakes projects will allow the developer to demonstrate their skills in a discrete, specific, and demonstrable environment. The toy can then be used in the hiring process, or to develop a demonstration for the hiring process. Having that project available to demonstrate during the interview process will reassure employers that not only does the candidate have potential to contribute greatly as time passes but can also contribute immediately.

I hope to use this pattern throughout the next several months while trying to secure my first career position. I have identified the biggest weakness in my resume to be my lack of full projects to display my skills. I have worked on multiple programming projects that I can use, but they all seem too simple to truly impress a hiring manager. I have a great academic record, but little to concretely prove my development skills. In conjunction with the Breakable Toys pattern, I will look to develop a full-stack project over the coming months that I can add to my portfolio and increase my chances of being hired.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Emptying the Cup. 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.