Category Archives: Week 8

Apprenticeship pattern: Expose your ignorance

I was reading chapter two on “Expose your ignorance” and got so caught up to it. When working with my team this semester, if there is something that I learned is to ask questions and not be afraid to show my “ignorance” like the book calls it. Sharing and exposing myself helped me understand that we should never feel less smarter than others just because they know better than we do, because learning and knowledge is open to everybody and it is not impossible to reach their level or even better, surpass them.

It can always happen to be caught up in the middle of a project that we do not know anything about. Some people might, and some might not. In that situation, we should let our ignorance awaken our curiosity so we can easily ask questions. People in general hate being seen as ignorant because we always want to show that we have knowledge, experience, skills required for the position or project. So, because of that, we find ourselves faking our knowledge and skills just to impress others. But software development does not work like this, it’s either we know or we don.t because the more we try to hide our ignorance, the more we’re sinking ourselves; And there will be a moment when it will be hard to get out of that place we got stuck on our own.

I love what the author said about the runner: ” She’s not training to have strong legs; she’s training to run. Like the motivated developer who after working on a Python for two years achieves a deep knowledge of Python, the marathon runner’s strong leg muscles are a means, not an end”. Craftsmen need to have the courage and humility to set aside their expertise and wear the “white belt” as they pick up an unfamiliar technology or learn a new domain.

One of the most important traits that a craftsman can possess is the ability to learn, identifying an area of ignorance and working to reduce it. As, software developers, we should not run away from knowledge and being shy or scared to expose our ignorance is not doing anything god to us. I am proud of asking questions and showing that I don’t have or I barely do have knowledge about a certain domain. And it is something that I do even with my team. When I am not familiar with something or don’t know how to do it, I just ask and the one that have the answer will provide it to me and help me understand. This is how I increase my knowledge and skills.

This is where “The long road” will take place. By exposing our ignorance, and then confront it. We will spin the missing threads much more quickly than we will by faking it in order to appear competent. And let’s remember that while we are exposing our ignorance, we are also exposing our team to our learning ability.

From the blog CS@Worcester – Gracia's Blog (Computer Science Major) by gkitenge and used with permission of the author. All other rights reserved by the author.

Be the Worst

When reading this chapter, I found it challenging because I asked myself who actually wants to be the worst? I tried to project myself and put myself in that specific position and I found it very hard to do. However, after second thoughts, deep reading, and analysis, I am very impressed and humbled by the content of this book and this chapter. They say: “You have to be the best”, “You have to master what you do”, “You have to always be the head”. However, we never hear the opposite of those sentences. We never hear: “Be the worst”, “It’s okay to start at the end of the queue”, “We all started from the bottom”. It is discouraging to know that nowadays when working as an apprentice, the expectation and the pressure is greater than the willingness to be understanding and people tend to forget that they have been there once and act as if they were the best from the start.

 There are points the author mentioned that I found important when being the worst in a team. He talks about couple of risks associated with it like brining the team down, the risk of getting fired when falling behind or inability to catch up and feel bad about ourselves. This part tells us that it is a great thing to accept being the tail of a lion. However, it comes with some risks that require hard work and regularly updating ourselves on where am I? Am I making progress? How much time the team is granting me and what happens if I don’t meet specifications? Being the worst is just a way to make us confident in the lion’s den, but we must really be motivated to learn, we must show the desire of doing better, bringing ideas that get us noticed with time.

The last interesting point the author mentioned was reaching out, asking to join a team and observe the team’s dynamics and ways of operation. For me, this is great because it shows the desire for personal growth and the team might be motivated to take you in because you have shown initiative and interest. I feel more confident now to “Be the Worst” in a team of professional software developers because that position will unleash my confidence, allow me to be myself, learn and improve at the same time in my craftsman’s journey.

From the blog CS@Worcester – Software Intellect by rkitenge91 and used with permission of the author. All other rights reserved by the author.

Nurture your passion

There is a saying that “if you love what you are doing, you will never work one day in your life”. Software engineer/developer is a job that requires patience and passion. Without passion, people would easily give up their work.
As I mentioned in “Sweep the Floor”, we need to willingly work the job that no one else would do as we first start to learn and to improve our knowledge. But there is a side effect to that. The side effect is that we work in an environment that stifles our passion for the craft.
In whatever situation, we would always need to look back, take a moment to think of our true passion for software craftsmanship. To become an excellent developer, we will need to have a tremendous passion for what we are doing. However, under some circumstances such as deadlines, corporate hierarchies, or bad management. It is hard for developers to grow under those conditions.
Finding something at work that interests you where you pour time and effort into it. Considering some extra time outside of work to build some Breakable Toys to help expand the knowledge. As Paul Graham said: “The key to being a great hacker may be to work on what you like…To do something well you have to love it. So to the extent that you can preserve hacking as something you love, you’re likely to do it well”. If we do something with love, eventually things turn out really. We build better software with great quality.
Start a weblog and read blogs. Write about the topic that interests you. Doing that also not only helps you to learn new techniques and technologies but also could become your side hustle. Participate in online forums such as Stack-overflow by answering questions that others might have. Read thoroughly others’ answers to learn more about the material with different approaches.
To grow your passion, set clear boundaries that define the sort of environment you are willing to work in. This means in some situations you leave work early, walk out of a meeting that becomes abusive, adjust your attitude, and refuse to distribute your code if it does not meet your minimum. Eventually, the result could be bad for pay raises, promotions, kudos, or popularity. But keeping these boundaries helps to keep your passion strong.
Needless to recite what I have said in the beginning about passion. In my opinion, passion is the only thing that keeps you moving forward, eager to learn, and the desire to explore. You would not need to work a day in your life if you work with passion.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

Sweep the Floor

Everyone starts from somewhere. Nobody knows what they are supposed to do when they first start to do something at their new jobs. They start from small tasks with little experience to more challenging tasks with better experiences in knowing what they should be doing. Gradually, they become an expert and do their job better. “Sweep the Floor” shows us how developers should lower their expectations when they’re fresh out of college and take on simple tasks rather than picking up experiment ones.
The problem shown in this section is we are pretty much unsure of our place in the new team and the team would not know what to expect from us. This might cause bad consequences due to under-performance and bad communication. The solution for this problem is to willingly take on volunteer work. This does not mean taking on any kind of work but should be the work that improves our understanding of the team, the work, and gain experiences. A great method is to show that we could do a high-quality job even it does not seem to matter in some way. An example of this is one famous for his work as Uncle Bob Martin who volunteered to come into a room and took out the trash. The task seemed unfair and jaw-dropping for such a developer, but this job brought him admiration and devotion. However, acquiring an easy task does not mean that we should skimp on quality which might lead to trouble later.
Another problem is that some people think they are better than others due to their educational background. The hard truth is at the workplace, that does not seem to matter much. Workplace and school are contrasting when it comes to real life. You might do good in school but it does not guarantee you would do as well at your job. Having better education means higher expectations for you on the first day.
Yet, there are consequences for taking on an easy job. We might become the team’s gopher who get assigned the tasks that no one else would do. From that, we are unable to take on more challenging assignments. The better way is to advocate for yourself and look for every opportunity to prove yourself worthy with higher-level work.
After all, we should take on the tasks that everyone complains about, do it and do it well. Because that is the only way to show people that the can-do attitude and exceed people’s expectations.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

Learn How You Fail

Ingenuity is often misunderstood. It is not a matter of superior intelligence but of character. It demands more than anything a willingness to recognize failure, to not paper over the cracks, and to change. It arises from deliberate, even obsessive, reflection on failure and constant searching for new solutions.

—Atul Gawande, Better

Learn how you fail is the second blog I’ll discuss from the Apprenticeship Pattern book. I’d like to begin this piece with a quote from Morihei Ueshiba: “Failure is a key to success, each failure teaches us something”.  Everyone wants to be successful, but not everyone is willing to accept failure. However, I will add that my greatest life achievement thus far has been learning to accept my failures. This is, at the end of the day, motivation.

Failure, according to Atul Gawande, is unavoidable since it will happen to all of us at some point. I hold the same viewpoint. We won’t be able to learn if we never make mistakes. We are called losers when we fail at something, but victors when we learn from our mistakes. Failure serves as a reminder that we are all the same, and that success is earned through hard effort and determination

It has been the same for me. I accept that I make mistakes and that I have learned from them. I didn’t understand how programming worked well enough. But I learned by doing, and I’ve made a few blunders along the way. I knew that to be an effective programmer, I needed to mix knowledge, attitude, and technical capability with soft skills when I initially chose my future job would be. I needed to apply my talents, which are methods and processes that supply computers with instructions on which action to execute, to prepare myself to be a computer programmer. But the most important thing I prepared for was that I would fail a few times until I arrived at the conclusion that I will be a decent coder.

One other thing that I would like to talk about, is also the solution given to this pattern. It is a good choice that when we are becoming conscious of the things that trip us up, we allow ourselves the choice between working to fix these problems or cutting our losses. I totally agree and for sure that we have to accept that there will be also some things that we are not good at. Also when we encountered by failing this “thing”, it will be a lesson on how to prevent it in the future. Only in that way we won’t fail again. But the most important thing we need to know is that the only thing we learn from is a failure and not success.

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

At Least They Have the Spirit

PREVIOUSLY ON MPEKIM.CODE…

So far, we have come to the conclusion that it is okay to not know everything. It is also alright to even be “the weakest link” of a team. What matters the most is the enthusiasm, the drive to learn more about our projects and programs. For Apprenticeship Patterns, this means that newcomers can be useful to a team if they provide morale and enthusiasm to expose and attack their ignorance.

To start, I believe that the book stating the idea of “repressing enthusiasm when it is not welcomed” isn’t entirely incorrect. However, I do believe that, unless an enthusiastic apprentice is drastically creating dire consequences for the team, then the members with lower morale should lighten up a bit. No one starts out “creating the next Linux”; if seasoned professionals are not held up to these high expectations, then it seems ridiculous (to say the least) that the newcomers will be held to it.

Interestingly enough, the controversial idea of repressing enthusiasm is supported by a factor of the pattern that I do enjoy: the idea of “experiencing diversity”. According to “Unleash Your Enthusiasm”, teams actually have the most efficiency when they consist of members who each have various amounts of experience. “Old farts” who have seen it all will likely be numbed and unaware of an issue that a newcomer will notice with their “fresh eyes”. Likewise, the more experienced will create sorcery, solving programming problems that the newbies weren’t even aware of.

As far as the future is concerned, I can say that I apply this pattern on a daily basis. While the book helps to reinforce this ideology, I am no stranger to “pumping up a crowd”. Unleashing enthusiasm is not only the idea of providing positivity and workplace morale, but it also involves taking the initiative. Even if they get shot down, we should always put our ideas out there – scribbles, doodles and random notes are never irrelevant. Some of the greatest ideas were the result of an accident (caused by an enthusiastic dreamer).

So far, in the grand scheme of my selected patterns, here is what I see as a “list” or “chain”:

  • Find a team that you are the worst on.
  • Discover and acknowledge your weak points.
  • Take the initiative and enthusiasm to work on these issues.
  • Give yourself the breakable toys needed to grow from mistakes.
  • Practice correctly, with feedback from professionals.

In retrospect, I find it amazing to take my previous blogs, and discover a path within them (similar to a graph data structure). Now, we must take the time to implement it….

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

Object Oriented Programming

OOP is used to structure a software program into simple, reusable pieces of code blueprints (usually called classes), which are used to create individual instances of objects.

Building blocks of OOP:

  • Classes are where we create a blueprint for the structure of methods and attributes. Individual objects are instantiated or created from this blueprint. For example, we can look at Duck class covered in class activity.
  • Objects are instances of classes created with specific data, for example rubber duck is an instance of duck class. It is crucial to remember that class is a template for modeling (a duck in our example), and an object is instantiated from the class representing an individual real-world thing (a rubber duck in our example).
  • Methods perform actions; methods might return information about an object or update an object’s data. The method’s code is defined in the class definition. In simple terms, methods represent behavior. For our Duck example, ducks had methods like fly() and quack(). Duck’s had different behavior. Rubber duck did not fly and did not quack but squeaked. These behaviors are specified in methods.
  • When objects are instantiated, individual objects contain data stored in the Attributes. State of objects depend on data in attribute. For example, Rubber duck is handled differently than a mallard duck based on the information in attributes.

The four principles of OOP:

  • Inheritance allows classes to inherit features of other classes. Basically, child classes inherit data and behaviors from parent class. In our example, Rubber duck inherited display() from duck class.
  • Encapsulation is containing information in an object and exposing only selected information to other classes. Private methods and properties are accessible by other methods of the same class. Public methods and properties are accessible by methods of other classes too.
  • Abstraction is using simple classes to represent complexity. It uses simple things to reduce complexity. Abstraction means that the user interacts with only selected attributes and methods of an object. Abstraction is used in interface. In FlyBehavior we had abstract fly() which was defined in concrete classes as flyWithWings or flyNoWay.
  • Polymorphism uses inheritance. Objects can override shared parent behaviors, with specific child behaviors. In method overriding, a child class can provide a different implementation than its parent class. In method overloading methods or functions may have the same name, but a different number of parameters passed into the method call.

Abstraction reduces complexity and constant overriding of method. Inheritance gives reusable structure across program. Polymorphism allows for class-specific behavior and objects of different types to be passed through the same interface. Encapsulation helps us prevent unwarranted change of important data by developers. Also, Prevents greater security risks like phishing that we face today.Advantages of OOP will never die out. Therefore, I have written this blog explaining OOP and I hope it has been useful.

Sources

https://codecoda.com/en/blog/entry/object-oriented-programming

What is Object-Oriented Programming? OOP Explained

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Code Smells

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

 

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Code Smells

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

 

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Code Smells

Hello everyone and welcome back to my blog. This week I wanted to go more in depth about code smells because having smelly code can lead to issues in the long run. Code smells are not bugs or errors. Instead, they go against the fundamentals of developing software that decrease the quality of code. A code smell is a surface indication that usually corresponds to a deeper problem in the system. Code smells are typically easy to spot. Just by giving the code a quick glance, you can usually see if there is a large issue. 

A frequent type of code smell is called a bloater. It is code that is being added over time and then turns into a huge chunk of code, like a big block of code. Examples of this are long methods and method bodies as well as long parameter lists. A “God Line” is a term used when you write an excessively long line of code. Another smell you can have in your code is having too many comment lines. Sometimes comments are necessary, but having too many comments may confuse yourself or others later on. Sometimes you may also accidentally write duplicate code that does the same thing you already coded before. You should practice DRY or do not repeat yourself in order to not have that code smell. 

There is also dispensable code. This is code that does not get used when the code gets executed. Since they are not used when the code gets executed, there is no reason to include them in your code. Duplicated code is an example of this. But you should also know that code smells do not always mean there is a problem in your code. Sometimes, you do need long methods or long bodies of code in order for you code to function correctly. If it does not function, then you just need to look deeper in the code to find the problem. 

Code smells are just an indicator of the problem rather than the problem themselves. To get rid of a code smell, developers usually try to do refactoring to the code. Refactoring is when a developer changes the inside of the code but on the outside, the code still does the same function. Code smells can be present even in code written by experienced programmers. It can reduce the lifetime of the software and make it difficult to maintain. Expanding the software functionalities also gets difficult when smelly codes are present. Code smells can go undetected a lot of times. Programmers should avoid and fix code smells to make their code cleaner and maintain functionality.

https://deepsource.io/glossary/code-smell/

 

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.