Sweep The Floor

A common stereotype amongst movies and literature when an apprentice first begins their work, they are handed a menial task and told to perfect it. Often sweeping or “wax on, wax off” from the movie Karate Kid, the task being grueling and numbing in a sense. This task assigned to you wasn’t to demoralize you or just give you something to be distracted by, it was to get you ready and perfect a skill by practicing frequently.

As an apprentice you are nearly always going to be on the lower rung of experience and will find yourself doing work closer to your skill level. With programming the metaphorical broom might not be clear, or obvious. Instead of waiting for instruction you should take the initiative and volunteer for things. Take a task that you can complete or learn to complete and lighten the load of others.

This won’t necessarily seem like sweeping the floor but in a sense you are taking the tasks that will help yourself and the team you are aspiring to become an essential part of. I understand this aspect fairly well absorbing this concept through admittedly far more media than I should have, but I agree with this pattern pretty much wholeheartedly. Being apart of the group and not being as skilled as them is fairly demoralizing, but taking the lesser tasks can still make you a vital part of the process while you make the effort to become as skilled as your group members.

While learning and developing your skills you do have to step back and learn the basics. Focusing your skills and learning the essentials is integral and necessary. It’s also usually the tasks that most don’t want to work on. Mind numbing maintenance and formatting is one task that higher level workers dread maintaining. These tasks are necessary and vital to the projects success and someone needs to do it. You might as well put yourself into the problems you can solve and along the way you will learn things vital to improving the project and increasing your skills. To learn the basics is to master them. Sweep the broom before you place the first brick of the new structure. Stack bricks thousands of times before you can build a sturdy wall. This pattern is to take the mindset of the novice within your group and how as an apprentice you can learn while also helping out your group.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

As my final semester approaches here at Worcester State University, I figured a relatable blog topic would be the best practices you can learn as a Software Engineer. The article can be found here: http://www.excella.com/insights/best-software-engineering-practices

 

This article touches upon three different practices that the author thought highly enough to include. The three practices are S.O.L.I.D., Automated Unit Testing, and continuous integration.

S.O.L.I.D. –  an acronym for an object oriented design principle.

S –  Single Responsibility –  a class should have only a single responsibility.

O – Open/Closed Principle – Software should be open for extension, but closed for modification.

L- Liskov substitution principle – objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

I- Interface Segregation Principle – Many client-specific interfaces are better than one general-purpose interface.

D- Dependency inversion principle – One should depend upon abstractions, not concretions.

When you use all of these principle together, a developer can create code that is much easier to maintain and improve over time. The code is SOLID.

 

Automated Unit Testing

Automated unit testing is a software development and testing approach where you independently test units to ensure that they are operating correctly.  Unit testing can be done manually and it was in the past, but automation has taken over and everyone is thankful for that.

I use JUnit in eclipse to test java programs continuously. It makes it very easy to track where there is an error and what caused it to happen.

Developers become much more confident in their work when they don’t have to worry about wasting a bunch of time finding errors, instead we test immediately and fix the problem before it gets too clustered.

 

Continuous Integration

Continuous Integration quite literally means that you continuously ingrate the code and fixing issues before they are submitted to the actual project repository. In my classes we used Github or GitLab to manage repositories.

It works by a developer checking new code submissions in the repository. The integration process then builds and runs tests while analyzing the code. The CI detects any problems with the code and gives feedback to the developer. The developer fixes them and then approves the changes to the code. This way no code ever gets broken.

One of the benefits about using Continuous integration is that the version control system holds all current and changed code. You can easily go back to see what changed and how something may have broke.

 

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