Similar to how code and design smells were covered in class. I was interested in digging more into code smells and seeing how they influence development of code and how they can be rectified. I found that this would be a useful topic to further delve into because being able to pick up smells from your code will help prevent further mess in the future. To supplement my learning in this topic I got around to watching a seminar or conference video on code smells in java, which was hosted by Stanly Lau, a software development coach/mentor and also someone having experience of looking at companies code and giving advice on code smells and refactoring. In his seminar he basically went over code smells and refactoring techniques used to remove to code smells; in the seminar this is done by an example he goes over with the participants.

Besides going over code smells, what I really like from this seminar, was how he explains the significance of catching code smells in our code; he explains this via system diagrams to show that code smells are in a reinforcing loop relationship with bad code, and bad code is in a balancing loop with developer motivation; because of this we need to reduce bad code via refactoring. Refactoring is important because it instigates flexibility and helps to remove bad code or code smells. And flexibility is important in order to deal with change and he states “[i]f you cannot deal with change or how to improve with change easily, then you are probably in the wrong business”. The was a powerful I really appreciated, that change is inevitable in programming and in order to deal with change we must make our code more flexible, and that is where finding code smells and refactoring comes in.

I also enjoyed watching Stanly going over his example code of detecting and refactoring the code smells. His methodology appeared that he would look at the code and try to understand what is going on with the code (reading before coding) and then would see if he can detect any code smells such as comments, duplicated code, feature envy, long methods, primitive obsession, or magic number. Afterwards he would choose a means to refactor that code smell; the aspect of refactoring that he describes as ‘making small steps without breaking the code for too long’ is what I found helpful and will incorporate next time I am reviewing my code. Rather than just choosing a technique such as extraction method, I should be compartmentalizing steps to fix a problem and then work on improving on that refactoring. Overall it was a supplement for my learning in code smells as I was able to see a demonstration and also learn some more techniques use ide’s as well.

I attached the links to video as well as the diagram that explains effects of code smells in a developers environment below.

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.

For this week I’ll be covering the pattern, Breakable Toys, from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. The breakable toys pattern uses small personal projects to teach new techniques. When in a professional environment, playing and learning with the project is not an option. To keep ourselves learning new skills after college, the best thing to do is to create personal projects that allow us to make mistakes and grow as developers. These projects, or breakable toys, are chosen by us and will likely hold more interest than work projects. By working on these projects, we can learn the workings of a project without the fear of consequences of our mistakes.

This pattern is a bit obvious, but I still think it is worth reminding ourselves of. I sometimes find myself tired of working on a needed project and begin to lose some enthusiasm. A breakable toy is always a fun and educational way to lift my spirits while still progressing my skills. To me, breakable toys are more than just a consequence free environment to develop in, breakable toys renew my enthusiasm in the craft.

When I just started learning programming back in ’08, I felt like a whole new world had opened up. There was so much to see and learn, and I was psyched for what I was to learn. My first breakable toy was a text-based game. It was terrible, messy, and bugged but I learned a great deal in the process and because the project was personal, I could do whatever I pleased without concern. While I have not worked with that project in over a decade, I can still remember some of the lessons I first learned while making that game.

I would highly recommend exercising this apprenticeship pattern. This pattern combines the developer’s interests with a stress-free environment to create a project that is exciting and rewarding. I think of our coding skills like cooking, part science and part art. To grow as a programmer, it is important to remember that we need to push our boundaries and experiment is we are to learn. A breakable toy is the perfect project to practice old skills and develop new ones.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

This week, I’ve been thinking about an apprenticeship pattern that brought up something I had never considered. It opens with a quote suggesting people might say programming might not be sustainable in the long-term. News to me!

The crux of this pattern is that you won’t always be provided with the career path that you want. To be successful, you have to fight the urge to follow the path an employer gives you and take steps toward the path that you want. This is your map, and it can be redrawn at will. The goal is not to narrow your experience just because of a comfortable salary and your attachment to a fancier title.

This pattern seems to stem from the loss of many great developers to the world of management. The author seems a bit biased in wanting to prevent this. Unfortunately, many people might find their salaries necessary to maintain a lifestyle, or support a family. Furthermore specialization, or “narrowing” as they describe it, can be a good thing.

Of course, if narrowing is part of your map, I suppose it still fits with the pattern. But the book also suggests looking at the possibilities, which I agree with. After all, a map doesn’t have one path; it has many from which to choose. Listing many potential paths and following the one that looks best for you is likely a good tactic to get where you’d like to be in your career.

I’ve always felt a pressure to choose a single path and stick with it. Being able to change my mind is a nice idea. Luckily as far as I know now, I’ve mostly figured out my career path, but I will also follow the suggestion of the book to plan many alternatives. Experience in multiple different positions has given me insight into the aspects of each job I like. With this knowledge, I’m only interviewing at positions that I trust I can stay with long term, and I’ll only accept a position if I still believe that’s the case. Nevertheless, the rest of my career is a long time, and companies change.

The quote at the beginning of the chapter is meant to say that if people tell you to stick to one thing — to move to the safe, normal career path — you don’t have to. If a company prevents your own professional growth, it’s time to jump ship.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

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 first step towards learning how to win. The objective is to gain self-awareness of the reasons which lead to failure, and then make better decisions by reducing the inclination towards idealism. Being conscious that you cannot know everything, is the only way to become aware of how you fail. Knowing your own limitations, allows you to deliberately identify obstacles and concentrate on the goals you can reach.

Yes, you will fail! What’s more important is that you will win, once you know why you failed. The way to get the best out of it is to create a system to prevent the failure from happening again after you have figured out what went wrong. Creating a checklist or a type of protocol to prevent it from happening again when you find the weak point is another option to not go through failure again.

In this pattern what got my attention is the last sentence, which says “if you’re brave enough, get a friend to review your code, and see what else she can discover”. This is very accurate because everyone who writes code knows that there will be errors and it will take time to fix them. Even though you fix the errors you get, someone will find something else for you to fix, especially when you work in groups. This can be very tough because you feel like you are falling down. The reason why this happens is that we feed our brains to always win, and never lose. We reach the goal because we know how to do everything, and there are times when we do not reach the goal because there is something, we had no clue about. Is it time to step back? No! We should go through the failure, learn why you fail, and try again if you think you’re capable to fix it. As a conclusion, it can be very painful to learn how you fail, but in the end, you will have the skill to accept whatever life throws your way.

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

The Breakable Toys pattern talks about a familiar lesson in life, which is that you can learn from your mistakes and failures because they are bound to happen. The pattern suggests that you create something similar to what you are doing in your job/work and use it as a playground to see what will work and what won’t and expand on the things that interest you and learn from what you create or fail to create. The one thing they suggest making and that a lot of developers make is a wiki because they simple to make and expand upon over time to show what you have learned and what you are capable of.
This pattern seems very useful and something that I might implement very early into my career because it sounds fun and interesting. The ability to create something and build on is something that is very important especially in the world of computer science where new things are always being made/optimized. I think this pattern makes me feel like the ability to grow and work on what interests you is an extremely important quality to have in software development. I now understand why our professors wanted us to make a professional blog and use it later in our professional careers since it will demonstrate our interests and progress made in learning more about the different aspects of computer science and software development.
The one thing that I really like about this pattern is the creativity aspect because it makes learning more fun since you are adding and making things more refined because you want what you create to look or work better. The best projects, not only in computer science courses, were the ones that allowed us to create whatever we wanted and pursue what we were interested in. Treating a job like this can turn it from a boring and exhausting job to a hobby that you enjoy and get paid to do. I really like this pattern and wish I knew about it earlier because I most likely applied it to my computer science courses as well to make them easier and more fun.

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.