Category Archives: #token

Find Mentors

For this week “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye I have chosen “Find Mentors”. It talks about finding someone to help you along the journey as a Software Developer, a mentor – a person who can teach or show you the ropes of the profession. The general state of the computer science field is young and therefore there is not many masters present, especially those that can teach us everything so one might have a lot of masters, each for a different part of the field they want to pursue. Important thing is to remember that we are all still learning about this and being a mentor does not mean they know everything.

This particular pattern is something I was a truly fortunate to have gone through in my own career. In my years of work, I have found a person who was willing to help me learn the ropes of the Motion Control field and be patient with me and my constant questions and mistakes. He is an exceptionally good teacher who will always take his time to explain concepts and work required to get things done. What I have found rather useful (and I will probably use this method in the future) is that this pattern does give us some way of potentially finding a mentor or many. It also somewhat prepares us for the possible rejection form potential mentor as unlikely it is and how the benefits can be huge.

What I have found particularly useful in this Pattern is how it tells us to “be tenacious about finding mentors to guide you”. After my own experience with this I think this is a very good advice, I for one know for sure I would not be where I am today in terms of my skills and understanding of the subject if it wasn’t for the help of my mentor. Everyone should find such a person to help them develop their skills, unless one is a genius and does not need any help, it is impossible to know things about a field without someone already experienced helping along the way. I think this cannot be stressed enough: FIND MENTORS!

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Breakable Toys

The pattern form “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye that I have chosen for this week is called “Breakable Toys”. It talks about being on a job that does not allow mistakes or failure, but without falling there is not room to learn or grow. How is one supposed to learn and fill in their gaps in knowledge if something needs to be right the first time. Simple solution is to create a “simple toys” on your own and play with them, fail with them and break them in order to fix them and learn from those mistakes, that will be unrelated to the project but an opportunity to learn and grow for it.

This pattern is something that I have used myself many times, what helped me a lot in this regard is also fact that I was going to school and was learning or “playing” with new programs and ideas all the time. Many people or managers, in my opinion do not understand how much learning or failing needs to happen before a good program will take shape, many times even just a working software, not perfect or good, is a major learning task for employees. To be able to do so safely and without repercussions from a work environment is a key in staying ahead in your career.

In my own experience I have done similar things described in this pattern and have even done so while at work, but only in thanks to a very understanding leader and mentor who was not afraid to let me take some time to familiarize myself with something new we were going to do. I am aware that not everybody has the same luck as I did and that is where this pattern is very much right. All people in our field should be able to play with the new software, new language and be able to just break it, to be able to later fix it and learn from the mistakes made, the only way that I can see the absolutely everybody can do it is on our own time, at home. It might not be something we will be paid for but it will let us develop decent skills and be familiar enough with a given concept to pass in the environment that does not allow failure.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Best Software Engineering Practices

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.