Category Archives: Week 11

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.

Expose Your Ignorance

The explicit context of this pattern is that you’re a developer on payroll and you have been tasked with successfully delivering an artifact of software to your employer but unfortunately you have not previously developed software with some requisite technology for the project ahead of you. The solution prescribed in this Apprenticeship Pattern is a bold one that leans on previous rapport with your superiors; it insists on radical honesty where one admits that they do not presently know all of the information necessary to deliver on the project and to appeal to their previously established competency and ability to learn new technologies.

What I find most elegant about this approach is not only the ability to tailor current expectations using honesty but also the renewability inherent in this approach:

“In this way, your reputation will be built upon your learning ability rather than what you already know.”

The implication there is that if you stick the landing on delivering the necessary code, you will have created an evergreen approach to setting expectations and earned yourself the reputation of being not somebody who is valued for their finite pool of knowledge but rather their ability to tap into an infinite pool of knowledge. The authors cite Carol Dweck’s work, particularly how the need to appear competent is a mindset (no pun intended) that has proliferated throughout industrialized societies and is hard to break through. They insist that, while this embarrassment may be hard to overcome at first, your peers will have to notice your rapid progress and moreover they may find that by you forcing the issue they may have new realizations about their intelligence; after all people like to solve problems and feel intelligent.

I enjoyed the juxtaposition the authors make between those who become experts as a result of the perhaps not being as inquisitive or less confrontational with their inadequacies and so-called craftsmanship-seekers who become experts just by virtue of interest. While the first group may not be as ambitious or aggressive in their pursuit of knowledge there is no need to disparage this group and I appreciate that the authors did not decide to punch down where many other snobbier tech experts certainly would have.

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.

Don’t Talk to Strangers

The Law of Demeter was proposed by Ian Holland in 1987. During the development of a system called Demeter using oriented object programming, Holland and his colleagues realized that the code that fulfilled a series of rules was less coupled. Although it is called The Law of Demeter, it is not really a law, but more of a guideline to help reduce coupling between components. When applying LoD to object orientated design, there is a set of four rules that formalizes the “Tell Don’t Ask” principle;

You may call methods of objects that are:
1. Passed as arguments
2. Created locally
3. Instance variables
4. Globals

A great example of this is:

    class User {
        Account account;
        ...
        double discountedPlanPrice(String discountCode) {
            Coupon coupon = Coupon.create(discountCode);
            return coupon.discount(account.getPlan().getPrice());
        }
   }
   class Account {
       Plan plan;
       ...
   }

Here account.getPlan( ).getPrice( ) violated the LoD. The most obvious fix is to delegate/tell:

    class User {
        Account account;
        ...
        double discountedPlanPrice(String discountCode) {
            // delegate
            return account.discountedPlanPrice(discountCode);
         }
     }
     class Account {
         Plan plan;
         ...
         double discountedPlanPrice(String discountCode) {
             Coupon coupon = Coupon.create(discountCode);
             return coupon.discount(plan.getPrice());
         }
      }

Each function should have a limited amount of knowledge as opposed to knowing about the whole object map so our neighboring objects need to know what we have done in order to depend on them to propagate that message to the correct location. Following this rule is hard, which is why it is called the “Suggestion of Demeter” by many because it is so easy to violate. Following this rule, though, is extremely beneficial because any function that “tells” instead of “asks” is decoupled from the rest of the code around it.

The blog I retrieved this information from was https://hackernoon.com/object-oriented-tricks-2-law-of-demeter-4ecc9becad85. The information was extremely easy to follow and understand. The coding examples given to show the difference between following the LoD and not following it were simple and clear. I also found the explanation of LoD given to be simple and to the point. Going forward with coding, although understanding that following LoD can be hard, I plan to utilize this guideline in order to enhance and simplify all of my future codes.

By following the LoD in future coding endeavors, my code will be easier to test, I can reuse classes more easily, the amount of coupling and dependencies between classes will be reduced, my code will more flexible when I make changes to it and it will be more maintainable.

Information gathered for this blog:
https://medium.com/better-programming/demeters-law-don-t-talk-to-strangers-87bb4af11694
https://hackernoon.com/object-oriented-tricks-2-law-of-demeter-4ecc9becad85
https://en.wikipedia.org/wiki/Law_of_Demeter

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

REST API’s

This week on my CS Journey, I want to look closely at the topic of REST API Design. I know We have been doing several activities regarding the topic in class and the homework assignment is associated with it, however, I wanted to be very knowledgeable on the topic, so I decided to do more research. REST is an acronym for Representational State Transfer. A REST API is a way for two computer systems to communicate over HTTP in a similar way to web browsers and servers do. Let start by looking at what An API is,  An API is an application programming interface. It is a set of rules that allow programs to talk to each other. The developer generally creates the API on the server and allows the client to talk to it and the REST determines how an API should look like.

Now let’s look at the anatomy of a request is, An API request has four main important parts: The endpoint, The method, The headers, and The data or body. When an API interacts with another system, the touchpoints of that communication are considered endpoints. Each endpoint is the location from which APIs can access the resources they need to carry out to do their function. The way APIs work is using  “requests” and “responses.” Meaning that each URL is called a request while the data sent back to you is called a response.

Generally, when it comes to methods it has five types. Which are: GET, POST, PUT, PATCH, and DELETE. These methods provide meaning for the request you’re making. They are also used to perform four possible actions that are Create, Read, Update, and Delete also known as CRUD. Next, the Headers are used to provide information to both the client and the server. It can be used for many purposes, such as authentication and providing information about body content. Lastly, the body or the data is what contains information you want to be sent to the server. This option is only used with POST, PUT, PATCH, or DELETE requests.

Overall, I learned a lot from this blog. The source I used explained the topic very well. I highly recommend everyone to check it out, because it has a variety of examples and documents that you need to know about REST APIs to be able to read the API documentation and use them effectively. It also goes deep into the methods and the request meaning of each of them, I think it is very important to understand those concepts because companies all over the world are using APIs to transfer vital information, processes, transactions, and more.

 

Source: https://www.smashingmagazine.com/2018/01/understanding-using-rest-api/

            https://www.sitepoint.com/developers-rest-api/

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