In this section, we recall that the best motivation for programming is enjoying the activity itself. However, real life work conditions tend to get in the way of this enjoyment. The solution proposed here is essentially to stick it out for the sake of your long term goals.

I liked the quote from David Hoover at the end. I think it’s a pretty apt description of what it’s like to have fun doing meaningful work. I also really liked the brief description of Obie Fernandez’s career, in which he became much more successful and talented by diversifying his skills. As someone with a lot of different ambitions, I find it pretty aspirational.

As far as how this has changed my thinking, I’m not really sure how to or even if I want to integrate this idea into my career. This is mainly because I don’t really know what I want to do, exactly. I think I might want to generalize it a little more.

My takeaway then would be to have more general goals that guide the specific ones. I don’t think that’s really a good way of explaining it but I don’t really have anything better.

What I mean by that is trying to connect general things I want, like financial stability or a reputation for talent, with actionable goals and actual things I can do. I tend to struggle with tunnel vision sometimes. It usually takes some thought to recall that the class I hate isn’t just what I do day to day, but also part of my degree. While I think what I’ve said above sounds kind of trite, I do feel like this section has helped clarify my thinking.

I’m also not sure if I agree with the dichotomy the authors give here, of writing easy, fun code versus writing difficult, but financially rewarding code. It seems pretty backwards to me. Personally, I think solving difficult problems is the most important and most rewarding thing a programmer does. When I imagine a terrible, unrewarding software job, I imagine one with no difficult problems. A position where the only thing to do is stitch together various APIs with no room for creative solutions or much thought at all.

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

Summary:

This pattern is based on newer programmers that have not had as much experience in the field not having reference to earlier works that were instrumental in the development of the field of software development. The newer programmer will have less reference in understanding the context of how things are the way that they are in the industry, and will be surpassed by his colleagues who know the literature and understand laws and phrases used.

What I find most useful about the studying of classics in a field like software development is emphasis on trends of the industry. Programming languages and projects can come and go, but if classic literature can be used regardless of the time period that is read it implies that there is general education that can be done that transcends simple programming or development.

This apprenticeship pattern has somewhat changed the way that I think. I know that I would probably have to learn terminology that is important to software development, especially when working with teams. This apprenticeship pattern has, at the very least, made me more interested about learning classical literature in the field. Although on the other hand, it seems a bit difficult to me to disambiguate which type of classical book to read, and which type to not read. The pattern references “When you pick up a book and the first thing you wonder is how out of date it is, you’re reading the wrong kind of books”, but I’m not entirely sure how to come to that conclusion. Although I’m assuming that I can gain proper reference via an article.

I do disagree with this pattern a little bit. Studying a lot of classical literature seems to me like a dedication that can take a lot of time and energy. I think if I want to expand my education on classical matters such as Brooke’s Law, it may be more beneficial to read a second hand source that aggregates classical laws and their contexts rather than reading some of the classics cover to cover. While my view here might be ignorant since it is only based on this short pattern, it is the impression that I get from it.

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.

For this third and final sprint, we were the most efficient and organized thus far. It is really neat to look back to the first sprint and see how much we improved as a team. From us in the first sprint not really knowing much about how to work as a team in sprints, to now working well together as a team for many weeks and understanding the sprint structure pretty well. Though the structure seemed somewhat daunting at first, I have grown to like the sprint structure and the entire workflow throughout my time of working on the Reporting System. I think that the best way to learn anything, especially for me, is through experience, so diving right in and getting first-hand experience with sprints, sprint planning, sprint retrospective, etc. really helped me to understand how it works, not only in theory, but in a practical sense.

The first thing that we improved upon over time, and even more so with this sprint, is the sprint planning. At the beginning, judging what we thought we could get done during a sprint was mostly just guessing work, but as time went on of working on issues, we were better able to judge how long an issue would take to work on and the weight that should be assigned to each issue. However, even with the first sprint, and definitely now, we were good about finishing as much as we wanted to during each sprint. This means that we did a good job of judging how long it would take to work on each issue, and how much we could get done.

The next thing we improved at over time was the sprint retrospective. This ties into how we were able to do well with the sprint planning, because only through discussing what we did well, and what we could improve upon during the sprint retrospective could we focus our efforts upon improving specific areas and keeping up with what we were already doing well. This is why I think that the sprint retrospective is one of the most important parts of the process. This is because even if team members are individually good, only by discussing with other team members about your strengths and weaknesses can you assist each other, and improve as an individual, as well as overall as a team.

I think that the most impressive thing about our achievements over the 3 sprints is that we now have either a working, or very close to working system. While at the beginning of the sprint we only had some of the backend, we now have a working backend, frontend, and API. Additionally, we have the endpoints and functionality in place for the ultimate goal of the system, generating a report. It is really neat to think that we as a team achieved the goal of having the system generate a report, and all the components coming together to do so, as well as the functionality in place for RabbitMQ to interface with the other systems. It is also really neat to think that future teams will be building upon what we did, using the code that we wrote, and using the documentation we wrote as a roadmap. In this way, we had an impact upon the future of the Reporting System, and the whole food pantry project as a whole.

Commits:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/commit/7ddbba9a43a71fa588c8b34f3ca1a16d43c39709

Updated backend to include more detail, including the containers and images used, and the endpoints available.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/commit/c0a121daa6e5d45ec00fa01642289677119d658a

Updated API to include the methods for the endpoints, as well as what parameters are required.

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

Expand your bandwidth is an apprenticeship pattern that teaches the idea that as well as learning and improving at tasks that we are comfortable and familiar with, we need to be able to learn about completely new and novel ideas in order to excel in our fields. The pattern mentions signing up for online blogs, newsletters, and online forums as a way to learn about new ideas. The authors also mention that while this pattern is important in order to excel in software development, its also important to know when to use it, and when you should instead focus your efforts on the task at hand. Their approach to this is to try to designate time every now and then to learning new things, but don’t spend more time than necessary on that learning.

I agree with this pattern and I think it is a good approach to the idea that people are meant to be lifelong learners. It isnt realistic to expect us to always be learning new things, as that constant influx of new information can be jarring and oftentimes unnecessary in the things we are currently pursuing. This approach teaches us that its important to set aside time for learning new things, but not in a way that it interferes with our current tasks. As a college student I have been introduced to plenty of novel concepts throughout my undergrad program, so I understand the importance of learning new ideas. Likewise, once I go out into the work force I will most likely specialize in a specific set of tools, and my learning will narrow down to mainly encompass those tools that I will end up using. Looking forward into this future I can see the issues that the authors mention in this pattern, where not expanding your knowledge base can prevent you from becoming the best you can, and I agree that the solution is to periodically go out of your way to learn about new ideas and concepts.

I have not really applied this apprenticeship pattern much in my life as of yet. A lot of my learning has come from my undergraduate program, and as such I have had the privilege of being exposed to a wide knowledge base. I do however, plan on incorporating it in my future career, since I believe that acquiring new knowledge will be important if I want to have a successful career as a developer.

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

The first question that interviewers ask candidates these days is about team experiences. They look at many different factors but working as a team is always an important one. If that person cannot work with a team, that is going to be a red flag. There is a saying that “if you want to go fast, go alone. If you want to go far, go together”. Team work gives people the ability to improve their communication skills, to be more efficient in building products and also to motivate each others.

We may have mentors and kindred spirits that we meet along the way, but people tend to think that software developers usually work independently. The problem is what if the product has reached its limit, the learning is struggling and the feeling that there are superior techniques and approaches to the craft that are eluding us.

The best solution is to find a way to sit down, have a talk with colleagues, and work together on a project. There is always something that we could learn from each other. The case that was mentioned in this “Rubbing Elbows” is Dave, who found an ally in Roman and then literally rubbed elbows over lunch as they learned together about technologies like the Ruby programming language and Eclipse plug-in development. Even though Roman could have not been that kindred spirit but Dave would still have benefited by working next to a talented programmer. There is always a certain technique that we could learn from others because we are not perfect. Therefore, it’s critical for us to be open to learning and willing to take it in. While paring programming can be an excellent technique for learning, it’s a complex activity and is not always an inherently positive experience. And sometimes it is a pain. If we feel chronic behind, week after week, and we’re beginning to despair, then it’s time for a change. The rotation may help jiggle us out of trouble. Ping-Pong programming to increase our participation is also a good way.

The final thought is to find someone we know who has already expressed an interest in starting an open-source project. Spend one day or an evening a week working together on that project. See how things would go, and seek motivation from each other. If motivation never return, it is up to us to seek new partnership where we can learn new thing. Because the best way to stay in workforce of this industry is to keep up with new technology.

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

So this is a pattern that I’m entirely unfamiliar with, as I don’t consider my understanding of a majority of the material sufficient enough to be able to reliably pass it on to another person. However, the pattern immediately addresses this by noting that every little nugget of knowledge can be valuable to someone who might be unfamiliar with it. And as a result, that bit of understanding can thereafter be passed on again, and cascade from the little help that I might have given a fellow programmer. In some ways, it may even be more beneficial to learn tidbits from a peer, as the author mentions that we would be speaking the same language in terms of familiarity. 

While the pattern references the fact that people may not appreciate what you share, I wholeheartedly agree that properly teaching somebody else will solidify the techniques in one’s own mind. If someone is struggling but isn’t willing to hear what you have to offer, they need to improve over several areas in their own right. 

I find it fascinating that the author mentions to be cautious about what you share, as you might be stepping on the toes of a higher up, and unintentionally disclose something that was valuable to an employer. It’s certainly something I’ve never considered before and will take into account going into the future. I’m also glad he mentions the fact that sharing a lesson could be interpreted as conceited or aloof, because from personal experience I’ve lost respect for people like this faster than a Hello World program executes. All in all my takeaway is to temper what you say and read the room when deciding when or when not to share; quite the valuable lesson. 

In the Action portion, I don’t necessarily agree with the recommendations made. Of course there’s no problem with writing blog posts and sharing workshops, but I regard the most important lesson to be to think about how you would engage with someone treating you the same way, if you were approached by them in the same situation. Teach in engaging ways and foster curiosity in your peers, but only if they are willing to accept your olive branch. It’s ultimately a waste of time to preach at someone who isn’t really listening, and worse, judging you for engaging with them.   

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

My biggest takeaway from this is to simply build more things that don’t work, so later on I have the knowledge to make things that do actually work. The quote of the three ball juggler not attempting to push the limit to five balls during a performance is an analogy that really spoke to me in that regard. 

I think the idea of building a personal wiki would be a phenomenal practice for my growth, as I’m constantly forgetting general syntax or git commands that sometimes slow my production rate to a crawl. I built a game for another class that emulated the classic Flappy Bird from a few years ago, and getting that to function would have taken my ages and ages without the help from my groupmates. But reflecting on the experience now, the amount of times we broke that game and the thrill of being able to actually PLAY what I made was something I’d never experienced. Nor with any other art, as I’ve never been one to share any of the sparse create projects I seldom try to come up with. Reading this pattern has kind of put that creation process in a better context for me now, and I hope I retain that going forward as I expand my portfolio to apply for career positions in the future. 

I also like the idea that I own these broken things, but that they will stay with me wherever I go. Just because I can’t make something work at first, doesn’t mean years or months down the road I can easily slap on some extra padding and see how much I’ve grown as a creator. 

Reading on, the Action section really sums up everything that I just reflected on. Especially the wiki idea, which will be the first thing that I try to implement. I know I’ve kind of been harping on very similar patterns, as referenced in the See Also section, but I think this is the biggest area of improvement that I need to work on. For my last post I’ll be sure to expand into a more diverse pattern just to expand the repertoire, but I think it was important for me to recognize the importance of my harping on these specific topics.

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.