Category Archives: Week 11

Unified Modeling Language (UML)

For this week’s blog post I have found a blog on Unified Modeling Language (UML). UML is an object-oriented modeling language. This has become a normal standard for documentation of a software system. It is a pictorial description of classes, objects, and relationships. It represents a plan that defines the working hardware or software system. For example, we can use a UML diagram to show what is going on in a three-class software system. For this example, the names of the three classes will be Student, Classroom, and Teacher. For each class, a box is used in UML to show the entire class with three lines separating class name, methods, and instance variables. Each variable is listed as the variable type and name separated by a colon (for example, String : Id). While the methods are listed as method name with parameters (if any) and the return variable type (if any) separated by a colon (for example, getId() : String)  Now if we wanted to show that the class named Class borrows objects from the student class, we would draw a arrow pointing from student to Class. If we wanted to show that it extends the class, we would draw a dotted arrow instead.

UML was designed and created back in the 90’s. This was a period where object-oriented languages (OOL) such as C++ were being used to build complex but compelling systems. The issue during this time was that we had complex systems but no good way of showing on paper what the system is doing. This was until in 1994 when software engineers Grady Booch, Ivar Jacobson, and James Rumbaugh of Rational Software created the UML language. This development of the language was finished two years later in 1996. Each of the designers came together to find a language they will reduce the complexity. According to Study Section, the website with the blog, they say on their process of reducing this complexity, “Booch’s method was flexible to work with throughout the design and creation of objects. Jacobson’s method contributed a great way to work on use-cases. It further has a great approach for high-level design. Rumbaugh’s method turned out to be useful while handling sensitive systems. Behavioral models and state-charts were added in the UML by David Harel.” (Study Section) In 1997, the Object Management Group (OMG) acknowledged UML as a normal language. They now are responsible for maintaining the UML language and updating with new languages that come out.  

History Of Unified Modeling Language (UML)

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

Benefits of Recording What You Learn

Photo by Ann Nekr on Pexels.com

Oftentimes when doing something repeatedly, whether that be some sort of skill or action which needs to be learned over time, it can become sort of “mindless” as you gain familiarity with the subject. So even as you become familiar with the idea or concept, you no longer think about doing it even as you practice or utilize it more and more often. Because of this, some ideas can feel like they are more “drilled” than actually understood and comprehended, losing the sort of comprehensive fundamental knowledge that would come from a more complete understanding. If you just learn something to use as part of a larger project or system, then it can be very easy to develop an incomplete perception of the concept, and this is an area where I found the pattern “Record What You Learn” to be relevant.

Discussed in chapter 5 of Apprenticeship Patterns, https://learning.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s06.html, the concept of “Record What You Learn” is concerned with the idea of writing down or ideas, techniques and technologies/skills which you might use throughout the course of projects or development periods. Relative to software development, sometimes an application can be made up of many smaller pieces or technologies (ie: a web-application consisting of Vue.js, Express.js, REST-API, MongoDB, running in Docker) which you might need to become familiar and competent with during development quickly. However, needing to learn about many different technologies at once can leave gaps in your overall understanding, and you might end up needing to reference manuals or guides often.

The benefit of writing these things down becomes apparent when you can look back to your own notes or documentation and reference them in the future, and as opposed to simply looking into the documentation written by the maintainers or developers of the tool in question, your own personal notes will likely contain useful context and explanation which could be lacking from standard syntax guides or official websites. Maybe you find a way to save time working in C++, when you write that time-saving measure down it becomes far easier to repeat in the future.

If you constantly reference your own notes it helps to reinforce those ideas more than referencing something written by an external source because you are rereading your own thoughts and ideas relative to the concept. I have recorded notes for things I have been learning in the past (HTML/CSS and web-development, Java, C#) and I think that it makes a difference to have your own notes with added context. The connection to your thought process and ideas helps the concepts sink-in, and writing them down makes you think about them more than you might otherwise.

Book Referenced:

https://learning.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s06.html

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

Sweep The Floor

“Sweep the Floor” is perhaps an Apprenticeship Pattern that I’ve seen most closely paralleled in the real world. The pattern proposes that the price of admission onto a team may be that the newly crested member start by doing the unglamorous jobs —hence the title of the pattern—, often this will be things such as differed maintenance or writing reports. This is manyfold: it proves capability, builds trust that you can work independently, allows for controlled and low-stakes contribution to the project, and will free up the more vested members’ time to teach you higher stakes tasks.

As I alluded to, this ritualistic humbling seems to be inevitable in any profession, particularly in what gets oft classified as skilled-work. When I was a mail processing mechanic, the first thing we new recruits were delegated was daily maintenance tasks such as changing rubber belts on a feeder assembly, or changing drive belts that were in the lower tiers of the mail processing machines; the latter considered the most uncomfortable —sometimes downright painful— task to work on. While I don’t suspect that updating documentation or eliminating technical debt will be nearly as dirty as being covered in paper shreddings and ink dust I felt this quote in particular was a very powerful way to bind the metaphor of back to software development:

“These sorts of fringe tasks benefit the team, but they will also benefit you as an apprentice, because such chores are often skipped in academic courses and by doing them you can fill in the gaps in your knowledge. This experience will serve you well as a journeyman too, because any master who takes you on will understand how valuable it is to have someone to do the unglamorous work. After all, if no one sweeps the floor, then the glamorous work can’t be done because the team is hip-deep in dirt.”

The authors made sure to mention my primary criticism of this learning style which is what they have called becoming the team’s gopher. If it were not apparent, a quick definition of a gopher is one who has become known to absorb the menial or painful work and thus gets typecast into that roll permanently, condemned to the strictly utility work which creates a lag on your understanding of current developments in the code base and hurt your chances of upward mobility. The authors’ prescription is relentlessly advocate for yourself, Nurture Your Passion, and Unleash Your Enthusiasm.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

The Tortoise Always Wins

“How long will it take to master aikido?” a prospective student asks. “How long do you expect to live?” is the only respectable response.

—George Leonard, Mastery

While reading chapter 3 of Apprenticeship Patterns, I stumbled upon the preceding quote. It resonated with me because I often get so caught up in aiming for perfection that progress becomes halted. Anything worth doing is worth doing poorly.  I have heard it said that perfection is the enemy of progress.  

This chapter focuses on the long road we all must travel to master our craft. The author talks about how we have all grown to desire immediate gratification, whether that be in notoriety, wealth, or the development of our skill. If we desire to become true craftsmen we must focus our attention on delayed gratification. Our skills will take time to develop, and the journey will be a test in endurance and patience. The problem presented in the text is of being stuck in a “golden lock” where our aim for further crafting our skill is at odds with our desire for a higher paying job. By taking the path less traveled “Robert frost” we can make all the difference in our development as craftsmen.

We must be patient and compassionate with ourselves along our journey. It is easy to get discouraged when we see how little we know in comparison to veteran developers or even peers. So long as we strive to continuously hone our craft, we can become the masters that future generations of craftsmen look up to. The long road means we do not grow into incredible craftsmen overnight. It takes long hours and is a slow process.  

When we take our time to mindfully develop code, asking questions about why and how code behaves the way it does, or why we approach problems a certain way, we deepen our understanding of not only the development process but our strategies for everyday living. We learn better problem-solving skills, we become more inquisitive into ways to efficiently meet the needs of ourselves, our families, and our communities. This is something I have struggled with as a CS major, trying to balance out good grades with deeper comprehension. Many students fall into the trap of just learning the information required to pass the class with a good grade, putting ourselves at a disadvantage. Our lives have only a finite amount of time, and sometimes we need to decide whether we should slow down and take time to comprehend the deeper truths of software development, even though it may take away from time available for studying the class materials.

If we desire to become true craftsmen rather than just working a 9-5 grind we need to recognize that the path we chose is neither easy nor short. Our field is growing exponentially with the constantly changing technological advances we are experiencing and will continue to experience. This path is not as straight and narrow as other fields, due to the continuous changing of technology. However, if we slow down and dig deeper asking the questions that lead to deeper understanding, we will see the commonalities that all software share, making it easy to adapt to the changing of software development. Traveling “The Long Road” can allow us to bring meaning and pride to our work rather than being another nameless cog in the machine for a corporation.

The tortoise always wins the race.

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog – Record What You Learn

For this week’s blog post, I read the section  “Record What You Learn” from chapter five of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The section started with a quote by Atul Gawnde in which it states: “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” This reminds me a lot of myself because I am usually the one that never writes anything down, Instead I will believe that I can remember it. However, later I forget it. As I get older, I realize that recording something is useful, for example, if we are doing a project sometimes it is a good idea to draw diagrams and analyze through writing which helps to organize and plan it out. The section mainly talked about the practice of keeping a diary or a journal that will be useful throughout your career. The author also mentioned avoiding falling into the trap of just writing down your lesson and forgetting them, which I have done several times.

Keeping a journal of what you learned and going back to read it regularly will help you review the materials and give you a vital resource to draw upon. I read in an article that Psychology research and learning experts suggest writing things down leads to better learning. When I think about it, it is quite true at least for me I learned better by writing the materials down. Another interesting insight I read on the section was “By reviewing your journal, you can switch your past and your present around to generate your future” This is such an amazing quote and I hope that from now on I can keep a journal and look back at the things I have recorded. This pattern changed the way I think, it has given me new insights and inspires me to start jotting down my thoughts. I hope Over time these entries help to write an article or even a book regarding the journey of my life.

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance – Apprenticeship Pattern

This apprenticeship pattern is called expose your ignorance and the name for it is kind of straight forward but it is an important matter for a software craftsman. Often times there are many things that a software craftsman does not know and the goal is to find out the things they don’t know and learn about. They need to gain more experience with the new technology and not be shy about learning. Exposing your ignorance means being able to put your ego aside and write down things that you currently aren’t capable of doing so you can move forward and learn about them. Also when working with teams, it is important to communicate to your client or product owner that the work you are doing requires a learning process and don’t just tell them you know what the technology is already. This way you will build stronger relationships over time. The goal is to find a balance between not knowing a certain thing and being able to learn it.

I think this pattern is important for software craftsmen because often times people will become certain and expert with a certain technology and want to only stay on that path. They aren’t willing to navigate in other directions but become more experts in that field. However, for craftsmen we need to keep on being interested in the journey and learn more things that we are ignorant about. The goal is to be able to learn things and as the journey goes along, you will be able to master things but it shouldn’t be the end goal. The people who are experts are aiming to be masters at the technology and learn the most they can about it because that’s their end goal and it is not about overall learning for them. This is why craftsmen need to expose their ignorance and find out things that they aren’t currently able to do. Then the next step is to figure out how to learn it and create a learning guide that will work for them. Overall, this is an important pattern for craftsmen to improve their knowledge.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Nurture Your Passion

The key focus of this pattern is founded in the all too familiar scenario where you fundamentally enjoy the subject matter you are surrounded by at your work; however, the work itself gets in the way of your passion for the subject. An example of this would be suppose you are really passionate about software design and you enjoy taking your time making a solid product using good code. While that is your passion, and rightfully so, you may find your job is more concerned about functionality and speed. They might prefer you create shoddy code in a quick amount of time that works, rather than doing the job properly. As you might imagine, if your goal was to be employed to create solid code the way you always have, this might hurt your motivation.

The proposed solution to this predicament is to search around at your work and find something that properly interests you. Involve yourself in it and put in as much time towards it as possible. Outside of work, do the same. Find and work on interesting things that satiate your passion. I would continue the prior example to demonstrate how the solution works, except that its a pretty good example for why it doesn’t. I’m sure that in the right situation, the proposed solutions are good options. In situations such as above, however, it isn’t really possible to change what you do at work to better suit your passion. If you already work in software for the company, and the software isn’t up to your standard, where in the company can you go that is up to your standard?

Many companies have a fixed structure. Often, if you attempt to either move yourself around or change the structure itself, it is easier for the company to simply let you go and find someone else. That’s one of many problems that come from jobs being rare and workers being abundant. If jobs had to compete with one another for workers, overall conditions for workers would improve. As a quick aside: in my opinion, if the government weren’t trying its hardest to support major corporations (due to being bought out by them) and got rid of regulation that solely hurts small businesses, maybe in a more free-market economy where almost anyone can start up a company jobs could be abundant and would have to compete for workers. Speaking of idealistic views that might not actually stand up in real life, a second component to the proposed solution is to work on personal projects in your free time.

This is similarly not a valid option for many situations. Often, people simply do not have the time to work a full-time job and fulfill other responsibilities. Bringing up my example once again, you can work on quality software all week long in your free time, but writing code you know is bad and that you know could be better with just a little bit more time will always drain on you. Sometimes and for some people, it can be pretty easy to work on something you don’t enjoy. It can be easy to create something worthless and bad, but it depends on the situation and, more so, the person in particular. I personally find it extremely hard to work on things I don’t care about; even if I just have to do it badly.

It can be hard to have a strong passion for something and then have other people not allow you to do it. It isn’t even a matter of them letting you do it; it would be enough for them to do nothing. But often times, they directly work to oppose what your soul wants you to do. That said, you can’t just vilify them for it. You ended up in a bad situation but in the previous example, for instance, you wouldn’t be stuck. Maybe you misunderstood what they want or maybe they misled you. But if it’s a matter of your soul, so to speak, you can always leave the job. It isn’t always that simple; we have responsibilities and bills to pay. That’s why I personally believe that if you have the opportunity, build up your savings and investments. Sacrifice some of your standard of living now so you can afford to make a change like this in the future. Do your best to prevent yourself from getting trapped in life.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Study the Classics

            In the “Study the Classics” learning pattern of the Apprenticeship Patterns book, the focus is on catching up with the well-known literature or practices in the field when your knowledge of theory is more limited. Luckily, I feel as though Worcester State has prepared me well with a mix of theory and practical, technical skill, but this pattern stood out to me, nonetheless. Sometimes, when talking with peers or reading online from people more experienced than I am, I find I can get bogged down in references to things I have no knowledge of. This usually detracts from what I was initially trying to find out about. There’s more than enough “good” material out there for many, many lifetimes worth of learning. What concerns me is finding the right material and learning about it in the best path. Even if I can find all the proper materials for my learning goals, working through it can be difficult or impossible if I don’t go about it in the correct way.

            As the pattern mentions, exposing your ignorance is as essential part of opening yourself up to learning. This is something I don’t think I really have a problem with, as I usually try to put my ego to the side when taking on new tasks. What I really need to start doing is also mentioned in the pattern: keep a reading list and read constantly. I’m not great on this front. Perhaps these are particularly difficult tasks for college students because most of our work comes outside of our courses anyways, but I could definitely stand to try more, especially once I’m out of college.

            I also find difficulty in using the classics to inspire more current learning. I do feel confident applying my knowledge to new topics (I feel confident that my knowledge is translatable) but discerning the relevant material from the outdated in the first place can be difficult. This is a very handy skill and I think it probably comes with an expanded knowledge base anyways. As long as I get on the road of continued learning and studying the classics, I think this skill should develop.

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

Apprenticeship Patterns: Learning Languages

I am once again impressed with the relevance of these patterns, covering many issues that I have been struggling with recently. For this week I chose to focus on the Your First Language pattern. This might sound strange, as I am a senior and at the end of a pretty significant part of my journey as a software engineer, and yet I feel as though I have yet to become an expert on any particular aspect of programming. In terms of programming languages, I have found myself vaguely utilizing many without fully understanding how they work. This is exactly the issue discussed in the pattern.

This pattern focuses on a few different tips for learning a new language well. After choosing a language to focus on this pattern advises you to focus on creating a useful feedback loop with whatever type of work you are doing. This can be through a variety of methods, being finding existing communities of practice online or someone you know who is an expert themselves. As for how to learn the language, there are a few different methods recommended. The overarching method is to have a specific problem to solve rather than just solving small examples present online and in books. I have often ran into this exact situation myself, finding my initial excitement in learning a new language stopped abruptly by some frustrating example problem that has little relevance to what I want to do with the language. Instead, what is recommended is to think of a larger problem you would like to solve with a program. Starting from this very general level try to break it down into smaller components and, after getting to the most basic component to work on, start from there.

Personally I once again had little to disagree with. I have realized that learning new languages seems to be a critical skill for software developers, as there is such a variety available. Each language generally has its own advantages and disadvantages, with some having specific use cases, like html for web design. Thus it is important to know how to go about successfully learning a new one,  as it is its own little road on your greater path to becoming a software developer.

Source:

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch02.html#your_first_language

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Be the Worst

There is a saying in China: Better be the tail of a lion than a fox’s head! There is another saying: Better be the head of a chicken than the tail of a phoenix.

 

Surround yourself with developers who are better than you. Find a more robust team where you can be the weakest member and have room to grow. In the beginning, you may not feel confident in your life, but the process of developing and learning in the workplace that makes you stronger is lovely. In this society, no one will care how beautiful and challenging your strategy is. The most important thing is the result. Have you grown and become stronger during this period of enduring learning?

Remember, the probability of being rejected or thought strange by a potential mentor is not high, and the potential payoff is enormous. Even if the person isn’t interested in taking you on as a full-time apprentice, asking her out to lunch can be a valuable investment of time and money, like why dinner with Warren Buffett was auctioned off at such a high price. An early-stage businessman, or an established businessman who has achieved success in a particular field, is all vying for this opportunity. Do they care about the meal? No, they need to learn something from talking to Buffett. Such as looking at the market, investment vision, and the future development trend of business. In computer learning, the principle is the same. By talking with the people above us or the successful people, we can get the information and direction beneficial to our future development. Opportunities are for those prepared, and the accumulation of experience and insight in life will make you soar when opportunities come.

Ask lots of questions.

Tasks such as maintaining build systems, product support, responding to maintenance requirements, bug fixes, code reviews, eliminating technical debt, creating project wikis, updating documentation, acting as a sounding board for other people’s ideas, and so on. Typically, you focus on the less risky edges of the system rather than the core, which often has many dependencies and a lot of complexity. Jean Lave and Etienne Wenger look at apprenticeships in different industries and find that “in the workflow, the tasks of a novitiate are often placed at the end of a branch, rather than in the middle of a series of clips of work” (Situational Learning, p. 110). These fringe tasks benefit the team and you as an apprentice, as they are often skipped in school classes and fill in the gaps. The experience still helps when you become a skilled worker because many of your mentors understand how important it is to do the tedious work. After all, if no one cleans the floor, the team can’t do the glamorous work because it is Mired in a mess.

What’s the most grubby task your team has been putting off for months? It should be the one that everyone complains about, and nobody wants to fix. You solve it. Don’t hold your nose and force yourself to do it; See if you can solve the problem creatively in a way that exceeds people’s expectations and is fun for you. Many people feel that this is a job that is not worth their time. If you don’t do well, you will help the team take the blame. If you do well, the team will take the credit. But you grow as you solve what the team can’t do.

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.