Author Archives: rtrembley

Sprint Retrospective 3

This last sprint I feel as though I went backwards. I am not too happy with my results. I spent the majority of my time working on semantic-release for the backend, frontend, and api branches, which I was only able to partially complete. Reflecting on this sprint, I should have absolutely given up and started work on something else. If I had given up someone else might have tried, and one of my team members might have had a different way of approaching the problem and solved it. If I were to look at this optimistically, its good that I messed up in class rather than in a real job. I was also able to write my findings in the issues I was working on so that the next student to take up the issue won’t be starting from scratch.

When working on the backend and api branches I was getting errors that did not make sense to me. I believe that there is something wrong with the repositories since that should be the only difference between the backend and api. I communicated this in my issue descriptions.

If I had to say something good about myself I really do like my issue descriptions. I am not sure if it will be helpful for the next students, but I really hope it is. I even tried to suggest possible solutions I was thinking of. I knew that I had to try hard to write good documentation because when we inherited this project from the previous group, there was little documentation for us to go off.

Something I think my team could have done better is to check in with each other more often. Sometimes I did not know what my teammates were working on, which is something you never want when working in agile production development. We slacked off on our daily standup meetings; if we didn’t I could have communicated my struggle with semantic-release. We could have made more of an effort to perform out standup meetings correctly, and I know that would have definitely helped me, and probably others as well.

Something that I could have done better relates to communication as well; I could have asked for help. I am not sure why, but throughout my struggles with semantic-release I did not ask my group for help at all. I did ask other people, but if I had gone to my group they would have known about my problem, been thinking about solutions, and they would care about fixing it since it directly relates to them. For whatever reason I kept believing that I could solve it myself since I got it working on the frontend, but now I realize this was a mistake.

I am not going to lie to myself; I did worse this sprint compared to sprint two. I think it is important to look at your own work objectively and critically in order to improve. Like I said before, I am grateful for this learning experience while still in college. I know that an employer will expect me to make mistakes, but I am not the kind of person to be satisfied producing sub-par products. I will do my best to learn from this experience and try to not repeat the same mistakes in the future.

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

Craft over Art

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

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.

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.

Breakable Toys

The idea of Breakable Toys is that you can only really learn when you are given the ability to fail. When you are working in a real environment, you cannot afford to break anything. This limits how much you can learn, since the best part about messing up is learning from your mistakes. The main suggestion of Breakable Toys is that you should work on your own personal projects where you are able to make mistakes without affecting anything important.

If I’m being completely honest, I don’t like the idea of this pattern. I understand it, I realize why it is a good pattern, but I am not the person to work on programming in my free time. I have done it before, and the personal projects I worked on were fun, but I enjoy doing other things with my time. I enjoy being able to turn off work when I get home, and feeling like I need to continue to work is going to haunt me.

I do realize what this pattern is trying to say though, and I am not against that at all. The pattern says that you should work on something that you enjoy, and it shouldn’t be considered work but more of a hobby. I have been thinking about this ever since I began programming, but I feel like most of my ideas are outside of my skill level. Breakable Toys suggests that you should create a wiki about whatever you want so that it is personal to you, but as of right now I don’t want to do anything.

I am not too worried about the fact that I don’t really work on personal projects; I do when I feel like it. It is great to practice in an environment where you can try experimental things and build things for your own personal use, but I really do not want to feel obligated to do work on my own time. Overall, I think this is a very good pattern which is a hard pill for me to swallow. I know it will be good for me, but I cannot shake the feeling that I feel like I need to work on my own time.

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

The White Belt

The White Belt is a pattern all about expanding your horizons. When learning how to develop software, it is easy to be overly confidant in how experienced you have become. It is easy to become competent at one area of expertise, but that experience should not be translated to other areas. Other areas of expertise have different skills and methods which work best for them, and that may not align with what you already know. You should always take an unexperienced approach when learning new skills, since your previous experiences might interfere with how effectively you learn.

I can personally relate to this one a lot when working on the capstone project. Despite my Java knowledge, I barely knew how to use Docker, API calls, and have never used JavaScript before. Trying to learn JavaScript is difficult since I keep trying to impose my Java habits upon JavaScript. Java and JavaScript are both very similar, but are not the same language.

I like this pattern because it makes you reevaluate your level of expertise. With software development there is so much to learn, and as an apprentice you will never know how little you know. I hope to keep this with me throughout my entire apprenticeship. It is too easy to become comfortable and confidant with your abilities, and I plan to always learn new skills throughout my career.

In my experience, it is scary to learn new things. Once you get comfortable working one way, working any other way is difficulty and confusing. Trying to learn something new is always more difficult than doing what you’re already doing, and staying with what you’re already doing is too easy to do. This is why it is so important to try and learn with an open mind, since trying to force one mindset into another application is not going to work.

Overall I think this is a good pattern but not the most important pattern. It is certainly important, but when working in such a drastically different environment you will almost be forced to work differently. It is definitely important to keep a beginner approach when learning new skills, but I feel as though in most cases it will come naturally. When you are working in a very similar environment, however; it is very important to remember that you are in fact working in a different environment and should work differently as a result.

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

Sprint Retrospective 2

For this sprint we did much better as a group. Communication improved and we are comfortable with the project now. After the first sprint I was worried about how we would perform but now I am much more confidant in our abilities. I am excited for what we will achieve during the upcoming sprint.

Over this past sprint we have gotten the backend to work, added commitlint, updated config files and pipelines, and learned how to use RabbitMQ. I personally did the commitlint for the backend, frontend, and API projects, and worked on the pipeline. I am happy about how everything turned out, and I feel like I learned a lot about how commitlint and the gitlab pipeline works. When working on commitlint I decided it would be cleaner to work in a separate branch since I needed to push to gitlab in order to test my work. I am happy about how it worked in the frontend project, but in the backend I accidentally worked on the main branch instead of the commitlint branch. When working in the future I must always be aware of which branch I am working on and review my work before pushing, since you should not orphan public commits.

When working on the frontend I ran into a problem that was not present for the other projects. I found a solution on stackoverflow and made a comment about it. I am not sure that this is the best place to explain myself since I wonder if people will be able to find my comment in the future.

One thing that I am happy about is that I have increased my workload. I still want to do more in the future, but I am happy that I am doing more to help my group out. I think this is something we could all work on as a group. Most of our work is done in class which is ok, but we would get much more done if we all worked outside of class. One thing I think we could do to improve this is to schedule out-of-class work sessions where we would work for a few hours.

One thing that I think didn’t go well was branching. We made many branches this past sprint, and I do not think we used them properly. In my case, I made a useless branch since I did not use it at all. I feel as though using many branches, while useful, can contribute to confusion with our team and future teams. I do think we should be branching, but I feel as though we could do it better.

Overall, I am happy with the progress we are making. I am glad that the backend works finally, and I am glad that the gitlab project is coming along. I am excited for the upcoming sprint since we have almost finished refactoring, and we can begin working on new features. I am concerned about making new features since I do not have any ideas as to what to do, but whatever we decide to do as a group will be fun to work on.

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

Reflect As You Work

Reflect As You Work is a pattern which requires retrospection. When working it is important to actually gain experience and not just go through the motions. Quoted from the pattern, “The goal is to extract the maximum amount of educational value from every experience by taking it apart and putting it back together in new and interesting ways” is an excellent quote which I think encapsulates the entire idea of the patten. As apprentices we want to learn as much as possible since not doing so will start us on a road to complacency.

One thing that I will implement into my work is the idea of Personal Practices Maps. This seems like a very useful tool which will aid in retrospection. Right now I know my strengths, but I do not know my weaknesses. Using the Personal Practices Map will allow me to observe trends in what I do and help with my retrospection.

Another thing that I enjoyed about Reflect As You Work was that it mentioned how good experience directly leads to career opportunities. When Dave learned about a new pair programming technique it directly lead to him writing an column for While I don’t expect to be writing any columns, I do hope that the skills I gain will lead to other employment opportunities in the future.

Reflecting as I work will help with Drawing My Own Map. While navigating the map I should be acquiring new skills which will shape the future of the map, which will lead to even more skills. Over time these skills will drastically improve my marketability, which will have a much greater impact on my map as opposed to earning a lot of experience at a single company.

Reflect As You Work is a good pattern which, while not flashy, is very important to remember throughout the entire apprenticeship. As an apprentice, the goal is to learn. It is important to always learn from your experiences and grow as a developer; if not you will become stagnant. My goal after reading this pattern is to begin reflecting on my work and actively try to improve myself, because if I don’t no one else will.

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

Draw Your Own Map

Draw Your Own Map is all about defining your career path and how it aligns with your values as a programmer. When working at any job it is always important to keep in mind your goals and aspirations; don’t let a company’s goals supersede your own. Sometimes it may be tempting to stay with a company that doesn’t fit your map since they offer promotions and raises, but it will benefit you in the long run to find a more suitable job.

I think this is a fantastic pattern for apprentices to learn since it is very tempting to stay with a job to peruse promotions. I worked at Taco Bell, a job I didn’t like, for four years because I accepted a managerial position. If I had learned about Draw Your Own Map before I began working I wouldn’t have stayed with Taco Bell so long.

When choosing between fast food jobs there is not much difference between work environments, but when choosing between software development jobs there is a huge amount of difference between two companies, let alone the entire industry. This is why it is so important to Draw Your Own Map wisely and choose the right path, because you do not get a second chance.

Your path compounds on itself, as shown by Desi’s experience. She began work as a system administrator, but found that she wanted to program. Few companies would hire her since she had a lot of systems experience, but little programming experience. This is why it is so important to always stay on your map and make sure the experience you gain is experience you want. Eventually Desi found a company which hired her, and is much happier at her current job.

Reading this pattern has definitely changed my perspective on my future career path. Draw Your Own Map suggests to set small goals for yourself since achieving these goals will help you create new ones. I’ve been debating if I should (professionally) hop around jobs, and this pattern has convinced me to do so. Hopping jobs will allow me to experience what the industry has to offer, and to decide what I want to do based on personal experience rather than my own thoughts about what software development is. I thoroughly enjoyed Draw Your Own Map and I think it’s insights are invaluable, especially to someone like me.

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