From recent conversations with friends and professionals I’ve had genuine one-on-one discussions with, a common concern people have is whether they will continue to actually enjoy what they do. Today I’m going to discuss the Sustainable Motivations apprenticeship pattern. This pattern pretty much goes over scenarios people may run into throughout their careers in technology. There will be great days where people may be amazed that they are getting paid to create things and there will be rough days where people may be doubting if it is the right profession for them at all.
The points brought up remind me of a recent article from the New York Times titled Wealthy, Successful, and Miserable. What happens when the new-ness of what started as an exciting role to join in a company wears off and you are left off with unsettled feelings? It is up to individuals to keep going until they find what they love again or shift what they are doing a little to stimulate something new.
I like how the pattern encourages people to come up with a list of things that motivate them. It then tells them to reflect on what those things means or if there is a noticeable pattern from the things they have chosen. Having a list like this around to remind people of what they are working for is a reassuring way to keep them going. It reminds me of a post on LinkedIn I saw where someone kept a sticky note on their monitor screen that just had a number like “-$237.25” because it was to remind them of how much they had in their bank account when they started their job.
The pattern has caused me to think about the way I intend to work as someone who constantly likes to change things up or is not afraid of change. I do not disagree with anything in the patterns as it tells us to keep pushing and persevering by thinking about The Long Road, which is another apprenticeship pattern.
Overall, I think people interested in this pattern should read the NYT article I linked as well because it gives insight on the difference it makes when people do something that makes their work feel more meaningful.
In my software design course, I recently learned about how using design patterns helps you code better. I thought it would be a good review to go over the concepts this article introduces and potentially link it to things from class and maybe even add some things we did not get through during class.
The three categories Frederico Haag, a computer science engineering student at PoliMi, wrote about are creational patterns, structural patterns, and behavioral patterns.
Based on the design pattern I chose to work on for my individual assignment, I wanted to focus on the facade section–which is a structural pattern. The main take-away of the facade is how it “provides a simplified interface to a larger body of code.” I like how the name itself actually relates to the word facade’s definition: “an outward appearance that is maintained to conceal a less pleasant or creditable reality” (Dictionary.com). As a person who likes the aesthetic side of things, this seems like a convenient design pattern, especially if people who are not working on the code end up seeing it; it may be less overwhelming to some.
Another one of the options my class had for the same assignment above is for the decorator class–which is also a structural pattern. This “adds behavior to an object dynamically without affecting the behavior of other objects from the same class.” For some reason, when I imagine this concept, I think of a decorated cake. Since it is useful for adding the same behavior to many classes; it’s like when you add a spread-out layer of fondant or frosting to a cake, it could either cover the whole section(s) of cake or just some, but it doesn’t mess up the inside of the cake.
Overall, I found this content very useful to reiterate what I had learned and Haag incorporated visual UML diagram examples along with actual snippets of code to help us compare and contrast what he was showing. The content has not changed how I think about the subject because there is no arguing here, it just shows different ways people can structure their code overall. I do appreciate how Haag also listed “typical use cases” for some of them as it makes it easier to imagine.