Hello!

This week, I read about the Sustainable Motivations apprenticeship pattern from “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye.

The context of the pattern is that while we’re still starting out as an apprentice, we have to explore many different things to expand our skillset. Because of this, we come across a rocky path of handling new projects with tough demands to address and things we are unsure of how to approach. Even though you have some love for your job, this exploration gives you troubles and you find yourself feeling pressured, stressed, and even doubtful of your career path.

The pattern also brings up an example of some people being trapped, wanting to move on to something else, but being held back by their motivation of money–they want to switch careers but their current job pays well. It spotlights the importance of matching up your motivations to those that will help you in the long run– to reach mastery.

The action you can make for Sustainable Motivations is to concoct a list of things that motivate you. You should then leave some time to write some additional motivations later on. You should also take the time to reflect on the motivations that you yourself really want versus what other people think. Analysis of the motivations should be done to figure out how much of these are truly what you want and which are the five most important motivators of your life. The list can be referred back to when you find yourself struggling again. 

I think that this was an interesting pattern. I do find myself doubting where I’m heading at times, especially when I face some difficult new tasks and need to branch out to something completely new to me. I like that this pattern brings up that we do find ourselves loving/feeling passionate about our job/what we’re working on, but there’s also a mix of that and being unsure of what we’re doing anymore. I find that more relatable because there’s times where I find myself loving how everything gets put together in the end, and working on certain tasks, but sometimes the process feels really discouraging. From now on, I think I’ll make a list of motivations to keep me going and know that I shouldn’t let my motivations keep me from growing as well. I think more self-analysis wouldn’t hurt. I don’t disagree with anything in the pattern. It’s a good reminder to prioritize your values and where you want to go.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

These past few weeks, I’ve been getting myself refamiliarized with UML Diagrams. These diagrams have made a frequent appearance in my CS career. From my complete understanding, they are a great way of analyzing one’s code from the top down. At first, I thought it was just another hassle. Some of these UML Diagrams can get rather difficult to understand, and with all terminology and ways to draw out these charts, it can get pretty hectic to understand how the code works. I learned to take in the information given one at a time. In the blog “Types of UML Diagrams” by Lucid Content Team, it explains that when it comes to any formal code training, UML diagrams are essential but take some time to build and become really out of date fairly quickly, in an Agile environment. But they are very useful for quick visual documentation so that employees can give stockholders a quick overview of the system so developers don’t waste time in meetings.

UML stands for Unified Modeling Language, which is a way to visually represent the architecture, design, and implementation of complex software systems. It is supposed to keep track of the relationships and hierarchies within a software system. It’s hard enough to keep track of thousands of lines of code and so the UML diagram is supposed to keep track of all these components of the software. UML diagrams can be used with basically any programming language and so all software developers should be able to understand it. UML diagrams keep things productive and focused, and they are very helpful to engineering teams. This can include bringing in new team members or developers up to speed, source code navigation, and planning out new features before programming them, and it helps communications between a non-technical audience more easily- which means that most people will be able to understand the process regardless of programming experience.

There are many types of UML diagrams. The first is structural UML diagrams, which show how the system is structured, with classes, objects, packages, and the relationships between them. The component diagram is a more specialized version of the class diagram, which breaks a complex system down into smaller components and will visualized the relationship between the components. Deployment diagrams show how software is deployed on hardware components in a system. Composite structure diagrams are essentially blueprints for the internal structure of a classifier. Object diagrams show examples of data structures at a specific time. And package diagrams are used to show dependencies between different packages. Obviously, this doesn’t even cover half of the UML diagram spectrums since we didn’t even Behavioral UML diagrams which are used to visualize how the system behaves and interacts with itself and other systems.

I’ve come to realize that UML diagrams can be very useful, it’s important to read code from the source but that can be rather time-consuming sometimes. UML diagram is a lot easier to take in and can explain how the software works in just minutes. In my future projects, I want to be able to utilize UML diagrams so that I can better explain my own work to others. I feel it would have been very easy to explain my past projects to people if I was able to have one. The blog was quite interesting because it explained the many types of UML diagrams that exist and their practical uses.

Link to “Types Of UML Diagrams” by Lucid Content Team: https://www.lucidchart.com/blog/types-of-UML-diagrams

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

This week I read a blog post titled “SOLID Principles every Developer Should Know” by Chidume Nnamdi. Chidume taught me the important things I should know about SOLID and gave good examples to help make it more clear. SOLID stands for Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle.

The Single Responsibility Principle is a class should only have one job. This is because if a change is made it can affect more than just the one class that was meant to be altered. The Open-Closed Principle is software entities such as classes, modules, and functions should be open for extension, not modification. This makes sense especially with dealing with larger programs. If something new has to be added to a function it makes more sense to extend it than to edit the function. In larger programs, the function might need to be edited a lot which could fill it with if statements which can get messy. The Liskov Substitution Principle is that a sub-class must be substitutable for its super-class. This basically means if a subclass is called instead of a parent class the code still should still work properly. The Interface Segregation Principle is “Make fine-grained interfaces that are client specific”. This is done so that clients are not being given interfaces that contain parts they do not use. Finally, there is the Dependency Inversion Principle. This principle is that dependency should be on abstraction, not concretions. This basically means abstractions should not depend on details and that details should depend upon abstractions.

I selected this blog because it seemed like it was easy enough to understand and had code examples to demonstrate the principles in action. There was a lot of information to gather from this one blog post but it was well worth the read. Chidume does a good job explaining each principle and the pieces of code uses throughout the post helped clarify any confusion. I think following these principles will be a big help in the future when coding, especially larger programs that could easily become messy if I did not follow the SOLID rules. I think it will take some time and practice to be able to implement these rules in all my programs but it will be worth doing in the long run. I think that focusing on one rule at a time will be the easiest way to master these principles since it looks like it can be a lot at once if all of them are needed in a single program. 

Link: https://blog.bitsrc.io/solid-principles-every-developer-should-know-b3bfa96bb688

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

The Craft over Art Apprenticeship Pattern describes how despite us as software developers wanting to make artistic code, we must always prioritize utility over artistry. It is important to make code that serves its purpose over code that is technically challenging or code that has extra features. If we aren’t meeting what our customers want then we are no longer craftsmen.

I think that this pattern is pretty important to keep in mind. I often find myself trying to make code that is interesting or that I think will do a better job than what I am being asked to do, but this sort of over-engineering is not what isn’t what I am being asked to do. Despite wanting to do what I find more fun, the needs of the assignment or customer come first. Function over form. Most of my friends are artists, and my dad is an artisan over being a craftsman, so to me, this isn’t something that comes naturally. Moving forward, I need to make sure to keep in mind that what the customer is asking for is what they want, not what I think would be better. I really liked the emphasis that they put on utility as being paramount. Something that is technologically brilliant but has no utility is ultimately not the job of a craftsman, and not really what we should be looking for as software apprentices. They aren’t saying that we shouldn’t still strive for beauty though, which I am sure I will never quite be able to shake, but just that we need to prioritize the function. I think that this mindset will serve anyone well, especially in this profession. People that can’t listen to what the customer wants won’t last long in any professional field.

I do disagree with the idea that all software must be crafted for utility though. Technologically brilliant software, beautiful software, has a place and is ultimately important to the future of this profession. If developers never thought out of the box to create something truly amazing, we’d still be living in the dark ages. But I do agree with the overall point of function over form. Even in that mindset, however, I think that we should take creative liberties when it is appropriate, and allow ourselves to be shown in our work. Much like the world without art, code without beauty is miserable.

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 pattern I have chosen this week is the pattern about being the worst. This pattern is all about the situation you are in and the mentality you have. The idea is that you shouldn’t find yourself in a position where your learning is stagnated due to how good your team and that you don’t push yourself to learn because of this. You should instead always have that mentality of where you need to learn and continuously improve or else there will be problems down the line.

The pattern of being the worst was quite an interesting and relatable read to me. The idea of staying in the mentality of “being the worst” in which one is always trying to catch up to their peers around them. I usually like to see myself as the worst one in the team and that I have a ton of work to do to catch up and to improve myself. This does have its risk if you are actually the worst one in the team and causing issues to the team and yourself as it says in the reading. The pressure of being the person holding the team back sometimes look unsurmountable in which one just needs to keep a cool head and keep working hard on improving. In my current team, I have the same feeling of needing to improve to make sure that I am not holding them down.

The action of willingly joining a team to be the worst member instead another team that you might provide better benefit to right out of the gate is an interesting idea to think about. It can be hard to keep such a mentality up for every team you join and other people around you might be skeptical on your process and just try to put you on a different team you they think fits you in better. It’s as it says in the book being a selfish decision in which you might be bringing the team down for your own gain so it is important to contribute as much as you can to help mitigate this.

From the blog CS@Worcester – kbcoding by kennybui986 and used with permission of the author. All other rights reserved by the author.

The pattern I decided to read is titled “Nurture Your Passion” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The line that I think best summarizes this pattern is the one that states, “The people who walk The Long Road are not the heroes who sprint for a few years and burn out—they are the people moving at a sustainable pace for decades.” I really liked this quote because I’ve heard so many stories of young software developers who do amazing work at their first couple of jobs, but suddenly stop working because they are not feeling fulfilled. I think part of the reason for that is because many software developers enter the field and work themselves to the bone without really thinking about the “why” behind their work.

The reading adds that the jobs can foster a highly competitive, fast paced, and toxic work environment that further leads to developers burning out. The reading provides some potential solutions to this problem:
1. work on something you like
2. seek out kindred spirits
3. study the classics
4. draw your own map
5. set boundaries

One of the most thought-provoking things I took away from this reading was how by setting boundaries in my first job as a developer, I may get passed over for pay raises, promotions, kudos, or popularity. But on the other hand, by taking care of myself I am less likely to burn out and have a more sustainable career.

Therefore, I would say this pattern has indeed caused me to change the way I think I will work in my profession. While I want to be seen and known as a hard worker, I also think it is important for me to be mindful of how I am working and find balance.

Overall, there isn’t anything that stands out that I strongly disagree with. In fact, this pattern alluded to some other patterns that I am now more interested in learning and reading about to help me make sure I nurture my passion as I enter the software development field.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

This week, I read a pattern called Find Mentors. This pattern may occur with every apprentice when they have no ideas of what to do during walking on their own paths. So, finding a mentor is a good solution to help apprentices become more confident to walk on their paths. It is because you can easily learn a lot of knowledge or experience from your mentor who have gone ahead of you. However, this pattern also emphasizes that everybody have to walk on different long roads, so apprentices should know that “no one knows everything”. When you have a mentor, you need to resist the temptation of expecting your mentor to be a master of everything. Instead, you should  have a proper behavior to show your respect or appreciation for what you have been taught by your mentors.

Furthermore, there are many different types of mentors. One of the luckiest case is that you can find a mentor who can watch your development, talk to you and teach you face-to-face. On the other hand, there are many cases where your mentor is not physically available. However, you can certainly gain knowledge by reading their books; or you can also get inspired by their achievements, their stories, or their speeches. Furthermore, besides finding a mentor, an apprentice can also become a mentor to other apprentices at a lower level. That’s how an apprentice performs his transition to a journeyman.

In my opinion, Find Mentor is one of the best shortcuts when it comes to your long road because an apprentice can inherit many lessons that are available without him having to fail as many times as his mentor to get it. However, I agree with the author that it is very difficult to find a mentor that fits what you want to learn and is also willing to guide you. So not many people are lucky enough to find a truly mentor to take a shortcut. On the other hand, I also agree with the author on the point that apprentices can also find their mentors who are not physically available. I believe that, through this concept, the author suggests many other easier ways for apprentices to find a mentor. As for myself, I want things to be easy, so I choose to learn from people who are willing to teach me or give me advice to solve my problems. Furthermore, watching tutorial videos on social media is another way that I find my favorite mentors.

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

The Breakable Toys describes how to set up a situation where you can continue to learn and make progress with your career without unduly affecting your performance as a developer on your “day job”. The idea is to create a home-based work environment where you can develop product to enhance your skill set by making small products on your own. If these fail, or turn out to be flawed in some way, there is no downside, because you are expected to have learned lessons on your own. Although most work-paces are reasonable when your coding doesn’t come out perfect the first time, it certainly is much better for your career if you develop working, useful, optimal code in a reasonable time frame.

Many developers don’t have the time or inclination to do this, and turn out to be productive employees, but those who guide their own career by making their own products on the side are much more likely to succeed both intellectually and financially.

Throughout my career, I have always been motivated to keep up with the current journals, attend classes and conferences, and to always have a product I was developing on my own. In the 1990’s I developed a music-based utility program for guitarists called “Guitar Companion”. It’s most impressive component was a notation editor, but it also had a metronome, tuning fork, band manager component, and 3 CD’s with Video Guitar Lessons. I wrote it in Visual C++. But over the years, converted it to new technologies, and sold it through a website I had constructed fo4r this purpose.

From 2010 to 2015, I developed a number of Android applications for musicians. The one that turned out the best I sold on Google Play and had over 20,000 downloads.

This was all great for my career growth, but I would have never done this if I were not passionate enough to put in the time and effort. I highly recommend this approach to anyone who really loves to code. You are your own CEO. You call all the shots. You become sought after by companies, because you have developed depth in your code base that few can attain working under the strict protocol of working for someone else.

It also works in reverse. I would incorporate functionality into my “Toy” products that I learned at job-sites, as well as using things I wrote at home into my work products. It is pretty great when a boss asks during a scrum “who knows how to do X”, and you raise your hand. “ I do”.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.