Category Archives: Week-2

Code, Test, Refactor!

In my last post discussing testing and QA development, I went into depth about a project I was working on last year. I was developing an app that was supposed to track one’s financial history. It was the first project I had ever worked on that gave me free liberty to do whatever I wanted. I explained that it took a lot of my time and I ran into a lot of issues regarding the organization of the code, for the most part, I was most concerned about making something that worked rather than making something that worked effectively. Recently, I read a blog from Thesoftarch discussing how to write object-orientated code effectively.

The blog “Simple & Effective Way to Write Object Oriented Code” basically explains that most developers, like me, will only look to write code to reach functional requirements and not advocate for the technical quality of the code. The blog post explains that writing code to be functional can be acceptable during initial releases but can slowly turn complex if not managed correctly. So, it is important to maintain quality so that in the long term we can avoid struggling with maintaining the application. Different ways of writing effective, approachable code include making it simple to read, easy to test/verify, and having a low cost of change. The blogger goes by explaining the three basic steps of writing effective and well-designed code.

First, they go on to say that writing is easy but writing effective code is not easy, especially when you don’t have an approach. There are many design principles that developers go through in order to design good code. This includes SOLID, DRY, Design to Interface, and many more.

The second step is Unit Testing, as explained in my last blog post, it’s important to ensure that the code written works as intended. it’s best to write unit tests every time a method or class is created instead of writing the unit tests all at once.

The third and final step is to refactor. Refactoring is an activity to improve the quality of code without affecting its behavior. Making this a habit will help “maintain the code in the long run without adding much effort or risk.” As the blogger puts it, the coder should be able to identify “smells” in the code, refactor code to remove the smell and fix unit tests. Smells are certain structures that indicate violations of fundamental principles and negatively impact quality.

While reading this blog I’ve been able to keep note of what I need to do and look out for when it comes to developing a program. If I had read these steps last year, I think I would have had a better time developing my phone application. Reading this over I realized that there is a lot that goes into the development process and simply writing the code isn’t enough. It’s like baking a cake, everyone can follow the instructions to bake one but if key details are left out then it might not taste good, software development is the same way. It’s important that the code is designed in a way so that it can last. In my next project, I want to focus on refactoring for the most part. Code quality is very important and being able to make quality code will save me time and prevent any struggle.

Link to “Simple & Effective Way to Write Object Oriented Code”:

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

Third time’s the charm… (or not?)

My previous two attempts at getting my blog aggregated to the CS@Worcester blog have failed for one reason or another! (I assume). I must, however attempt posting once more and hope that through divine intervention, the aggregator decides to pick it up this time.

This situation reminds me of a quote by the famous pirate war-lord Vaas Montenegro: “The definition of insanity is doing the same thing over and over and expecting different results.”

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

Apprenticeship Patterns: Finding Mentors

We all have people we look up to, those who we see as guiding lights in the unpredictable lives we all live in. These special few, these mentors can be anyone, from friends, to family, to anyone in between. Having a mentor does wonders to the process of learning as well as providing a source of motivation and consultation when you find yourself struggling or at a dead end.

In ‘Apprenticeship Patterns’ by Hoover, Dave H., and Adewale Oshineye we see the pattern of seeking mentorship described in detail. Consider being an inexperienced software developer who has run into dead end after dead end while developing a new piece of software. Often we turn to those more experienced than us for insight into our problems and this case is no different. We seek out anyone who has had a similar issue and ask what they did in that situation.

Finding a master craftsman and learning from them is the goal of all aspiring apprentices and an ideal that we all seek. This however is often very rare today so many of us will find mentors who we can gather advice from regarding their own past experiences. Our field is relatively young and often changing, leaving few master craftsmen to teach those who are just starting out. Along with this many of these masters may not be physically available to you. This is where the mentors arrive to fill in the gaps.

Weather they are a coworker, a dear friend, or an anonymous individual online, a mentor can mean the difference for many software developers out there. They can offer insight on their prior experiences that may mirror your own, expose you to new ways of thinking, or just offer genuinely good advice. It is just another way to break your coding block when you find yourself stuck with a nonfunctional or misbehaving program you are attempting to get working.

With that said however, we all ‘walk the long road’ at the end of the day (Apprenticeship Patterns Ch 3). and finding someone to guide you can be hard so I will leave you with a recommended course of action by the authors. Find a library, or community with an active mailing list and being observing any messages left there. Over time you will pick up on the values of the community and which members are patient and willing to teach others. At the next opportunity, seek them out and establish that first connection with them in order to see if they would be interested in offering any informal advice or lessons they have learned over their time.

Bibliography:

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Craftsmanship Log #1 – My First Language

In the first Craftsmanship post I made, I mentioned that I am reading through Hoover and Oshineye’s book named “Apprenticeship Patterns”, which outlines certain patterns that inexperienced software developers may adopt so that they may overcome any potential hurdles during their personal learning experience rather than providing technical solutions. In fact, in that very post I mentioned (though not by name) two of such patterns, namely “Craft over Art” (introduced in chapter 3) and “Record What You Learn” (introduced in chapter 5). Though I may expand on these two particular patterns in a later post, I want to first address my reactions to one of the very first patterns that are introduced in the book, namely “Your First Language”.

            Briefly put, “Your First Language” is a pattern that is meant to address a software developer’s potential issues that may arise due to the fact that, though they may know multiple languages, they lack sufficient fluency in one of them. As such, such lack of fluency may put the developer in a difficult position when they are needed to work on a project that needs to be in a specific programming language. In this case, the book suggests picking a specific programming language to learn and master, preferably one that is used by any experts one might know. Now, it is important to specify that “learning a language” is not simply achieved by reading some resources related to a specific language, but by using that language to solve problems and actually apply what has been learned. Thus, by continuous application, a software developer may hone their problem-solving skills, which then may help them in learning other languages as well.

            While I personally found this pattern to be particularly helpful when I first started studying Software Development, I feel like my experience has changed the way I approach specifically learning a programming language. Though becoming fluent in a language is important, I believe it is also important to be proficient in the learning process itself. In my case, while I was learning my first language, I also made sure to internalize what that language was composed of in terms of concepts and structures I could use so that, when there is a need for me to switch to a different language, I would have some expectations as to what concepts I should expect to encounter and only worry about syntax while learning the new language.

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

Find Mentors

Self-learning is one important quality of any programmer; however, self-learning is not always useful since the learner might not know what is waiting for them and if their approach is good or not. In this case, every learner needs mentors, those who already achieved what we are working on or at least, they have deeper knowledge about the topic that we are learning.

Whether a beginner starts out with a training course or is self-taught, the first step on the path to software craftsmanship is finding a craftsman to apprentice himself to”

–Pete McBreen, Software Craftsmanship, p.96

From my own experience, I find this statement can’t be more accurate as I find myself learning more productive when I have mentors to show me what I should do compared to learning by myself. However, as in the book illustrated, as an apprentice, it can be difficult to tell who is truly a master craftsman. Therefore, an apprentice should follow a set of mentors that each one will show them a bit of a huge picture. And the set of mentors here counts not only “real” people who we should have already considered them as our mentors to learn, our friends and our professor, but also the active community we could find online to exchange information with people on it.

Besides, according to what was written in the book, an apprentice shouldn’t expect their mentors to know everything and get disappointed if mentors don’t know what we are seeking for as the current mentors could be other’s apprentice, we are all walking on a long road. Because our field is huge, a person who can guide us through 10 in-built React hooks may not be able to show you how to design the API route and vice versa, these twos are completely different topics and what we probably need is to master a specific set of skills that we desired; but it’s obviously the more we know, the higher opportunities we’ll have.

In conclusion, what I learned from this chapter is that I should find a community and actively communicate with other members there. Luckily, I found myself on a discord channel of one of the biggest Vietnamese tech forums, J2Team, having a community of developers exchanging lots of quality contents.

A channel in J2Team server

Now, I should consider posting my first message here and seeing where it will lead me to. 

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

Unleash Your Enthusiasm Pattern

This week I decided to read about the apprenticeship pattern ‘Unleash Your Enthusiasm’. The meaning behind unleashing your enthusiasm is that there may be something that is holding you back. Just like the pattern says, you have so much enthusiasm that’s ready to be release. The example that the book uses, is that software developers, you will more than likely be working as part of a team. Usually when working in groups, there is something called a norm which is what everyone follows. No one tries to stand out or if they did, they would find themselves in an uncomfortable position.

My initial reaction to this pattern is that it can relate to more than just software development. It can be compared to the outside world. For example, who you choose to have as your friends. In my instance, I used to have a circle of friends I used to ‘confine my enthusiasm’. Eventually I learned that they were holding me back from furthering my life from being greater. Once I started being myself, things naturally got better for me. My life got overall got better ever since I hold myself back. Just like how some new software engineers that start their first professional jobs confine with the norms. They become held back because they don’t want to speak up and voice their own opinions which then results in them becoming an ordinary worker who doesn’t stand out.

After reading the pattern, it has definitely made an impact to how I view myself working in a professional environment. I tend to be a quiet person when working in teams but lately have been more active and more vocal in the teams I am in at school. By doing this, I believe it will help me get out of my comfort zone and allow myself to ‘unleash my enthusiasm’.

This pattern can be applied to not only for software developers, but to their personal lives as well. I would agree with what have been said in this pattern because the meaning behind it, is to just let loose your ambitions. In order to grow and further your career, you can’t become a person who holds themselves back. There are times when staying in the norm is okay, but overall, it’s better to stand out because that is how you will get recognized.

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

Breakable Toys- log 3

This week, I read a pattern called Breakable Toys. This pattern occurs when an apprentice needs an environment where the apprentice is allowed to fail and redo his projects as many times as possible. The main purpose of this environment is to make apprentices or software developers feel free to make mistakes and they can learn from failures until they succeed or until they have a deep understanding of a concept. To solve this problem, the author recommends to his readers a solution called Breakable Toys which can be broken many times; and the consequences of the failure will not affect anyone else, except the person playing with the breakable toys. The breakable toy here can be anything that an apprentice can use to practice techniques, try out new ideas, or to learn new things. Furthermore, breakable toys should be relevant and useful to your life, such as building a wiki, calendar, address book, or game. A breakable toy also should be fun to ensure that you enjoy playing with it and can stick with it long enough to learn everything you need and to enhance your essential skills.

For myself, this pattern is really interesting because it is similar to a method I have taken to learn a new concept or to practice a technique. However, after reading this pattern, I think I have used breakable toys to learn computer languages ​​in the past. To learn the Java language, I wrote some programs that are used to manage a coffee shop or a bakery. My programs would take input from the customer to place an order, then print a receipt, but at that time I didn’t know any tools to store those data into a system. Fortunately, I had the opportunity to learn about MySql, a tool that helps me store and manage data of a system. So, I tried to develop those programs to link them to the database in MySql. That way, I can play with the Java language and also gain a deeper understanding of how to use MySql tools. Furthermore, I have also applied the breakable toy method to learn python language. I wrote some of my own games in python with simple ideas after watching a few tutorial videos on YouTube. Although they are just simple games, it is a great environment for me to play with what I want to learn. On the other hand, I can also freely break the code at any time without worrying too much about the consequences. In conclusion, I believe that breakable toys is a good method for software developers to learn and to experience any tools from zero to hero.

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

Expose your ignorance

This week, I chose to write on the pattern “Expose your ignorance.” This pattern describes how a company pays you to work as a software developer and expects you to know what you’re doing. The issue is that you are inexperienced with some essential technologies, and the manager and staff require assurance that you will be able to deliver the software on time. Everyone around you, including your management, client, and coworkers, as well as yourself, is under a lot of pressure to provide software. When individuals ask how long feature X will take you to complete, you can sense their demand for assurance in their eyes. Asking questions is the most obvious method to reveal your ignorance. This is easier said than done, especially when the person asking assumes you already know the answer.

This pattern, in my opinion, is critical for anyone who wants to or is now working as a software developer. At first, I assumed that becoming a software developer was all about learning which programming languages and which ones are the best.
But, in the end, it’s all about how quickly you can solve the problem and provide the finished software. I liked how this pattern encourages people to ask questions even if it means sacrificing their pride and dignity, and I believe it is the most significant thing I learned from it. One of the most significant skills a craftsman can have is the ability to learn new things, identify areas of ignorance, and seek to eliminate them. Ignorance, like dry areas in a garden, can be reduced by planting seeds of knowledge. Experiment, practice, and reading will help you water your seeds. You can choose to hide these bare patches from the light, embarrassed by their size, covering them to keep your pride intact. Or you can decide to expose them, being honest with yourself and the people who are depending on you, and asking for help. I really liked this pattern as it says to get rid of your ignorance or find your ignorance even if it means to sacrifice your pride. It is all about having the ability to learn new things from others and asking for their help in need. By the end, you will have in depth knowledge of a few threads of technology. With these threads, you can weave together robust software applications on a few platforms and domains.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Be the Worst

For this apprenticeship pattern, I chose Be the Worst. This pattern is about joining a team with much greater skills than yourself in order to learn from them, and as to not stagnate your learning by being on par, or more knowledgeable than your other team members. The issue with this concept is that if you join a team of members much more knowledgeable than yourself, you could be seriously behind and unable to complete any of the tasks required by the team, thus becoming deadweight and dragging the team down. The solution it proposes to this problem is for you, as a less knowledgeable member of the team, to do the more menial tasks.

I think this is a really clever solution to this problem for a few reasons. First, it allows you to still help the team, and not just be deadweight or an observer. If you were actively slowing the team down, or worsening productivity, then they would want you off the team, so it’s important for you to still be contributing something worthwhile, even if it isn’t huge. Second, since you’re doing menial tasks, it’s likely stuff that other team members don’t like doing or would rather someone else do. They would be better off using their time for more advanced tasks, so by doing the menial tasks you’re helping them and saving them time. In this way, it actually leads to more productivity for the team. Lastly, by doing menial tasks, as long as they aren’t too difficult, it means that you can still conserve most of your energy towards learning from the other team members.

I think this apprenticeship pattern presents strong and useful information, and I couldn’t find anything I disagreed with. I could relate to this pattern because I have been on teams where I was either the most or least experienced, and I didn’t like either one. Being the most experienced, you will always have to help out the other team members, while you could maybe be more productive doing other tasks. Being the least experienced, you often feel like you aren’t doing or contributing enough. This pattern has changed my view, as I now think that being the least experienced is better than being the most experienced, and I used to think the opposite.

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

Reflection on the Long Road Apprenticeship Pattern

The Long Road is meant to temper expectations. It lays out the path to mastery of software development as one of lifelong learning, and not one of chasing wealth or position. It is about taking jobs and opportunities that will help you continue your journey to gain more experience and knowledge and to prioritize this over promotions and salary raises. It is about finding the knowledge at the heart of software development.

I think that not only is this pattern good advice to software developers but offers good life advice as well. I personally believe that life is about the journey and that new experiences and gaining more knowledge is far more important than gaining more monetary wealth. I don’t care too much about money in general and I think that having this mentality about moving forward in my career lays out a life that will leave me a lot happier and more content when it comes time for me to leave it all behind. I didn’t get into computers to take a middle management job, I came here so I could enjoy what I do and get really bloody good at it. I just found the part about growth over wealth to be such a good way of looking at software development, and I think is kind of the opposite of why a lot of people get into it. I feel like a lot of people get CS degrees because they want to make money, and not so much for the love of the craft, and I think that’s just a path to disaster. I hope I’m wrong, but if you can learn to love the journey I think you’ll have a lot more fun along the way.

However, I do disagree with the notion that this pattern (and this book, as they say) is not However, I do disagree with the notion that this pattern (and this book, as they say) is not for people that want to take different paths. I think it is entirely reasonable to believe that even those who don’t want to continue a software development career for their entire lives still want to master the craft and continue their development journey even if they choose not to continue down a career in it. There are many people who don’t pursue full-on careers in software development, but still love coding and want to continue to grow their skills. Hobbyist game designers or developers are out there, and I think that that choice is completely valid and that this pattern still applies to those that choose something else. I just don’t like the gatekeeping nature of that comment in this pattern. Mastery does not necessitate a career in development. Do what you want, and enjoy the journey.

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.