Category Archives: Week 11

The Deep End

For this week’s pattern, I decided to go with the deep end. The last pattern I wrote was about rubbing elbows and that pattern was all about how you have reached your plateau of your skills and how to get out of it, while this pattern “the deep end” is the other side of that plateau where you begin to fear that this isn’t a plateau but a rut. On a plateau, you consolidate your skills through diligent practice in order to attain the next level while in a rut, your bland competence eventually decays into mediocrity.

The problem is that you need to grow your skills, your confidence, and the portfolio of successful work. Talking about successful work, when I sent my resume to a mentor/friend to review and ask them for their opinion about how my resume is, he said my resume will not get me anywhere. I had decent projects such as discord bot, android app, website, etc. I thought this much project was enough to set my foot into IT field, but my friend asked me one question which left me speechless, “the projects you built, how has this helped you or anyone else?”. At that moment, I realized that I have just been wasting my time. My projects have done nothing. It was solely built for my own interest, and it had no impact to anyone or not even myself. It didn’t have any positive results where it catches recruiter’s eye. I began to think that I need to challenge myself with bigger things, bigger projects, larger teams, more complex tasks.

The actions are to ask yourself a question such as what is the biggest successful project you have eve worked on in terms of lines of code and number of developers. What is the biggest codebase you have ever built on your own?. The answers to these question will show you other dimensions of project complexity and other ways of measuring your projects. Use this metrics to measure every project you have ever been involved in and draw a chart. After a while, you will be able to use this chart to track down where your career is heading and even start to make choices based on the chart.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Use the Source- blog 8

The pattern I read about this week is called Use the Source. This pattern is intended to show apprentices how to take advantage of the open source era. In the open source world, the ability of self-learning by reading and understanding source code is much more important than asking and waiting for answers from others. That is because only the code can tell you the truth, “the programmer’s intentions are irrelevant if the code disagrees”. That means it is always best when you can understand the code yourself without anyone telling you. However, the problem with this pattern is how to use the source, how to know if it is a good source and how to know if your work is good or bad when there are no exemplars or experts around you.

To answer those questions, the author has made many suggestions to help apprentices use the sources effectively. I can summarize them into two main ideas that an apprentice should adopt to become an expert. First, it’s about self-learning. All apprentices should seek out other people’s code to read and see the difference between the code written by all programmers. When you find any good programmers, you can learn to program like them. By reading the code, you should find out the intentions of the programmers, once you understand the codebase you can try to refactor them to ensure that you can build the projects independently. Taking the time to read and learn code written by other programmers is how you make other people’s tools your own; and that is also how you build your own toolbox, which is used to solve most of your career problems quickly and easily. Second, besides educating yourself from all the open source, you should learn from your community where you might have someone interested in reading your code and give you feedback. On the contrary, you should also be willing to read their code and be able to give them correct feedback or also be able to learn from their code.

In my opinion, Use the Source is the pattern that every programmer or every apprentice should use to develop their programming skills. That’s because I believe that reading the source is how you learn everything on your own; and this is also an opportunity for you to expose with other programmers to see their works and to also share your works to grow together. Moreover, as the author said that the software development field is lacking teachers; and there is no shortcut to learn all the tools for solving all the problems. So, I think open source is one of the most essential elements that no programmer can live without.

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

Apprenticeship Pattern “Learn How You Fail”

I am choosing to write about this section this week because I can feel like I can relate to this topic deeply. In one of the opening statements of this section, the author talks about how people who have never failed or say that they have never failed have avoided pushing themselves or have just glazed over their failures. I agree with this statement. Another point that author brings up and I agree with is reflecting about your mistakes is not about ranting about the mistakes that we have made but rather it is a matter of character. We should be reflecting on our mistakes so that the next time we do something similar, we can make something better. This is a sentiment that I can really relate to because whenever I finish a project or assignment, even I did it correctly, I would look back at it afterwards and analyze my work to see what I could have done better or done instead. For example, if I barely finish something before the due date, I might look back at it and think to myself, “I wish I had more time and added this feature” or “this feature took a lot longer than I thought it would and that I should have managed my time better”. One point I disagree with is ranting about our mistakes. I think being able to identify the mistakes that we made is very important and when I talk or rant to someone about the mistakes that I made during a project, I am able to identify more mistakes that I had made that I did not realize before. Another topic that the author brought up in this section is the importance on certain skills or goals. I am finding myself agreeing more with this statement each and every day. I used to do the opposite and try to identify all of the skills that I am not good at and tried to get better at all of those skills at once. This did not end well. I often found myself spreading myself too thin. I found that I was spending too much time on one topic and not enough time on another. This led me to feeling that I had mastered no skills at all because I was trying to learn and master too many things at once. So, I am going to end this post by echoing something that was said in this section. At some point we need to realize we cannot excel at everything and that we need to know and accept our limits so that we can focus what we know we can improve.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

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.