A very important apprenticeship pattern to keep in mind is Draw Your Own Map.  The pattern discussing the importance of planning out the next steps that you need to take in your career.  It is important to talk to your bosses and others that have been in the field longer than you about the direction that you need to take to advance your career, but it is important to note that while you should listen to what they have to say and take it into consideration do not blindly heed their advice.  When you do this, you are no longer in control of where your career and to a degree where your life is headed.  You need to sort through all the advice you are given and decide if it is in your best interest to follow said advice. One thing that I have always believed in and kept in mind when following advice of others or handing out advice of my own is that it is very easy for someone else to tell you what you should do because they don’t have to wake up and deal with it tomorrow.  By this I mean that ultimately the path you choose and decisions you make will impact your day to day life, career, and happiness.  Most of the time while your advisor may care what happens and worry about if you will succeed they don’t have to feel the pressure of what happens or the negative or even positive consequences from that decision.  You need to remain in control of your own life and career.  The best way to do this is to draw an actual diagram of where you want your career to head and what you need to do to get from point a to point b.  Life isn’t that simple though and things change so it’s important to constantly examine the map to see if you are on the right track.  If not see what you need to do to get back on track, or maybe things changed and you want to take a new direction either from a new-found interest or responsibility change in your life and then it’s time to redraw your map to have a plan of your next steps.  No one else is going to do it for you or care as much about the success of your career as you.

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

Following this link will bring you to the apprenticeship pattern called “Expose Your Ignorance”: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch02s05.html

I really enjoyed this apprenticeship pattern because I have always been a strong believer in asking questions. That is what this pattern is about. Asking questions to people who have more experience, sharing the ideas you have and telling them when you do not completely understand.  I also enjoy the emphasis on exhibiting learning ability. I think that the most important part of working is improving yourself and never limiting yourself to the information you might learn.  Being open minded is important to learning. You always have to be looking for another way to solve a problem and work around obstacles. Without proactively learning you will fall behind in no time.

One thing in the pattern that really made me think about my process of learning was the paragraph that starts with “Expertise is a by-product of the long road we’re all on, but it is not the destination.” I never really thought about it that way. I always thought that expertise was my goal, but it doesn’t have to be. Going deeper into the passage, I think what they’re trying to say is that expertise is something earned int he process of learning. As long as you are capable of learning well, expertise will come to you in time naturally in something that is required or interests you.

One thing that I thought about while reading this pattern was “what about those people who hate questions?” In my opinion, I think that someone who gets irritated by (good) questions are close minded and don’t have much to offer. While they might have expertise they probably don’t have the skill to relay their information and therefore get frustrated.  Unfortunately, sometimes those are the only people you have for guidance and you may need to look elsewhere for extra help. Of course this pattern doesn’t take into account the person who you are asking question to and I didn’t expect it to, but it is something to think about.

This pattern has opened my eyes to the true learning process. Both parties learn from someone asking questions, so don’t be afraid to Expose Your Ignorance. I know I will be exposing my ignorance more!

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

https://www.codingblocks.net/?powerpress_pinw=2994-podcast

This week I listened to the CodingBlocks Podcast Episode 67 titled “Object Oriented Mistakes.” Over about two hours the three hosts, Allen, Michael, and Joe discuss common mistakes and various programming problems that are easy to run into. I chose to listen to and write about this podcast because all of the programming I’ve done so far has been object oriented, so this was an easy opportunity for me to learn.

I picked up on one example they used early on while talking about the concept of BaseBean. BaseBean is when a class is implemented without falling under the category of “is a” for the parent. The example was if you were creating a car class including physics based attributes such as speed and weight, then creating a bullet class that inherits from it. This saves time in the short term since a bullet has attributes like speed and weight as well, however, a bullet is not a car and therefore you can easily run into problems later. Say you now wanted to put a new attribute into a car, like seat belts which no bullet should ever have yet it is inherited anyway. This can also be confusing for other developers looking at your code, assuming that bullet is some type of weird new very very small fast car for ant people. A good work around this common mistake is to only inherit things that fall under the “is a” category for the parent.

Next the hosts talked about how it is common to wrongly call the super method. Having to call super means that there is something in the parent class that is meant to be changed by its children. A common inefficiency occurs when a programmer sees they must remember to always change some common inherited method from the super class. Quoted by Martin Fowler, “Whenever you have to remember to do something every time, that’s a sign of a bad API.” This can be fixed by implementing template methods with the concept of the Hollywood principle, “Don’t call me, ill call you.”

So what I’ve learned from this podcast is in the future, I will remember specific common errors like these and know how to solve them. There are many other topics the hosts of CodingBlocks talk about in this episode, so i suggest you go listen to it if you want to hear more. Their content is interesting, their personalities are likable, and they have plenty of episodes to choose from with more continuously coming out.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

The blog post this is written about can be found here.

This blog post by a software engineer working at Facebook outlines several anti-patterns, including examples, why they’re bad, how to avoid them, and why it’s difficult to avoid them. I chose it to read because of the obvious connection to the course material, my continuing desire to avoid bad practices, and the fascinating connections the blogger makes to the cognitive biases that explain why we fall into these traps.

Some of the anti-patterns are time-wasters, like bikeshedding and analysis paralysis. Bikeshedding is described as the tendency to spend a disproportionate amount of time debating unimportant details. The blogger suggests flipping a coin or voting when you notice this problem arising. You can resolve to revisit the decision at a time when it’s more relevant, as long as you get the decision over with quickly and move onto more important ones.

Analysis paralysis is analyzing so much that it impedes progress. The blogger suggests that this anti-pattern crops up due to information bias and validity bias. Information bias is defined as the belief that you can make better decisions the more information you have, regardless of whether the information is relevant to the decision. Validity bias is overestimating how accurately you can predict an outcome based on a set of information, even if that information is unreliable or outdated. These can lead us to the belief that more analysis will be useful, even when it won’t. His solution to this anti-pattern is more iterations of code. If you go ahead and try something, you can see actual outcomes and modify your code accordingly, instead of endlessly speculating about outcomes.

I also took note of several class-related anti-patterns. These include the god class, a class that knows about and/or controls too many classes; fear of adding classes, the avoidance of adding classes due to a misconception that they will make designs more complicated; and the poltergeist class, a useless class that ought to be eliminated. The solutions for the first two seem to contradict the solution to the last one, but taking all three into account leads to a clear picture of how to properly use classes.

For the fear of adding classes, the blogger gives a useful example of a tangled ball of yarn to represent too few classes. Adding classes can instinctively feel like adding complexity, but simplifying your design with additional classes is akin to separating the yarn into individual strands. Similarly, the god class can be broken up according to the single-responsibility principle, giving classes only one clearly-defined responsibility. Poltergeist classes lack a clear responsibility; they often only call other classes or add a layer of abstraction that isn’t actually necessary. When you create a new class, you should make sure it actually has a valuable role and simplifies the design.

Hopefully, having read this, I will be able to recognize these anti-patterns in the future and apply their relevant solutions.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Today I read an article on coding-geek.com about HashMaps. I have used HashMaps before in Data Structures as well as Unix systems and have found them to be a very resourceful way to store and retrieve data. Most developers know about HashMaps but don’t completely understand how they work, in todays blog we will be cover HashMaps in JAVA.

HashMaps have an inner class called an Entry Class which holds the key, values and will return a value at the end. Two important main methods in the class are put() and get(). put() associates the specified value with the specified key in the map, it checks if the key given is null or not. If the given key is null, it will be stored in the zero position. The next internal part of the put method is that it fits the values inside of the limits of the array. The get() method is very similar to the put method but instead of storing, it returns a value. Get() gets the hashcode of the main object and finds the location of it in the array. If the right value is discovered, then it returns the value but if it cannot find it then it returns null. Put() and get() are two major internal parts of HashMaps and looking back at some of my old projects with HashMaps I now fully understand what is going on internally when I execute the program. I will use HashMaps more frequently in my projects now and I hope that after reading this you will be able to understand HashMaps better and will be able to give them a shot.

Source: http://coding-geek.com/how-does-a-hashmap-work-in-java/

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

In this blog post, Marcus Biel gives his thoughts on clean code, what that is, how to implement, estimate, and accurately design good software that does exactly what it should and nothing more. What is clean code? The author writes,

“It’s the idea that your code should be precise and as close to perfect as possible. If you have more code than you need, it shouldn’t be there.”

This concept relates to YAGNI (you ain’t gunna need it), and is an essential part of having clean and readable code. Adding features that might be needed later is a good way to bloat your code and run into bugs. Clean code requires time to fully understand the problem, this is sometimes tough when working in an environment where you are being pushed by those who don’t understand what goes into software design. Sometimes you will be asked to meet deadlines that will make you rush, in turn you can end up with poorly written code. The language and wording in code is also very important, using variables and names that are clear and make sense help others read and understand what is going on in your code. I selected this resource because having clean code is a huge part of being a good programmer, along with tips on clean code, the author has tips on designing code by running tests first, working with co-workers and clients to understand what features are most important, and what features are not beneficial.

“To me, being a software craftsman is about having a focused attitude and about taking responsibility for your code, your job, and your time. So, from beginning discussions to end results, your one focus should be on maintaining your own high standards and creating the best possible product for your client.” – Marcus Biel

This post had a good amount of information and insight on clean code, and being a good developer in general. Important aspects from the post I think are being clear when naming variables, methods, and classes, leaving out code that is not needed (YAGNI), and making accurate timelines for projects. Rushing to write code before you fully understand the problem can lead to more problems down the road. I expect to use concepts of clean code in my professional career, I believe it’s very important to make a good product that will benefit you, your company, or your client.

The post Clean Code Principles appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.