Draw Your Own Map is all about defining your career path and how it aligns with your values as a programmer. When working at any job it is always important to keep in mind your goals and aspirations; don’t let a company’s goals supersede your own. Sometimes it may be tempting to stay with a company that doesn’t fit your map since they offer promotions and raises, but it will benefit you in the long run to find a more suitable job.

I think this is a fantastic pattern for apprentices to learn since it is very tempting to stay with a job to peruse promotions. I worked at Taco Bell, a job I didn’t like, for four years because I accepted a managerial position. If I had learned about Draw Your Own Map before I began working I wouldn’t have stayed with Taco Bell so long.

When choosing between fast food jobs there is not much difference between work environments, but when choosing between software development jobs there is a huge amount of difference between two companies, let alone the entire industry. This is why it is so important to Draw Your Own Map wisely and choose the right path, because you do not get a second chance.

Your path compounds on itself, as shown by Desi’s experience. She began work as a system administrator, but found that she wanted to program. Few companies would hire her since she had a lot of systems experience, but little programming experience. This is why it is so important to always stay on your map and make sure the experience you gain is experience you want. Eventually Desi found a company which hired her, and is much happier at her current job.

Reading this pattern has definitely changed my perspective on my future career path. Draw Your Own Map suggests to set small goals for yourself since achieving these goals will help you create new ones. I’ve been debating if I should (professionally) hop around jobs, and this pattern has convinced me to do so. Hopping jobs will allow me to experience what the industry has to offer, and to decide what I want to do based on personal experience rather than my own thoughts about what software development is. I thoroughly enjoyed Draw Your Own Map and I think it’s insights are invaluable, especially to someone like me.

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

This apprenticeship pattern really tries to tell apprentices, relatively new software craftsmen, to allow their enthusiasm and new set of eyes to help guide older, more experienced members of a group. It encourages us to speak our minds about issues, and offer new solutions that may be looked over by the more experienced members of a development team, but that we can see with fresh eyes. It’s mostly about the value that new developers can bring to a project, and how at this point in our career we can gain a lot from suggesting things, whether they’re accepted or shot down, we will still learn something from the experience, and really there’s nothing to lose.

The thing that I found most surprising about this pattern was that new members of the team are actually pretty important, they cited a study about aircraft carrier teams being more effective with new members, and stated that it is similar in the software field. The new members bring in new ideas and a freshness that the more experienced group members have lost, and that it all creates an important balance between experience and freshness. It is important in the early part of our careers that we harness the new, fresh, outlook on the field in order to bring more creativity to our projects, find new ways of doing things, and are given the opportunity to advance and learn from people that have been around for a long time. And then we will eventually get to be the ones to temper the new apprentices’ expectations, and teach them, but also learn from their ideas. It is just fascinating to think that we are part of this ecosystem that has lasted for generations of developers and that despite our relative inexperience we are still invaluable assets.

I know that after reading this, I am feeling a lot less nervous about graduating in the next few months and that my contributions to my future development team will be necessary for their survival, and I’m excited to learn what I can from them. However, I’m not sure how the “Solution” part of this pattern really addresses the core tenant of the pattern. Yes, it is a good idea to make sure that your voice is heard and have a more experienced person tell you if there are flaws in your idea and where to improve. However, for many of us, we’ve never really been in a professional environment so it is kind of hard to achieve their solution. However, I don’t think there is a real issue or something I disagree with, but it just seems like it isn’t fully attainable for everyone.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

The pattern I am writing about today is use the source. The problem is that an apprentice can be using bad habits, but he will not know if he is not reading someone else’s code. The author specifically mentions that the apprentice should look at the source code of the tools he is using. One reaction I had to this was an interview experience I had. I solved a coding problem, and my interviewer asked my what the time complexity was. I was using the Java library method Arrays.sort() but I did not look up what the time complexity of that library method. I eventually figured it out. But it made me realize that I should know more about the libraries that I am using in my code.

The author also mentions the importance of refactory code. When reading somebody elses codebase. The craftsmen should look for ways to improce the codebase, and understand why the project is built in the way that it was. This experience could also lead to apprentice refactoring his own code. The author also mentions code reviews. This is something I am really looking forward to as a professional Software Engineer. When we learn the fundamentals school, we are usually working alone, or in a small group. But in the professional world, we collaborate. This will give myself, as an apprentice an oppurtunity to learn from the source code of my coworkers. Open source is another great way for new craftsmen to gain this experience.

The author recommends that the apprentice contribute to open source, so he can read source code, and learn from it. He also mentions that if a programmer can understand a program from the source code, that means he is a good craftsmen. This makes a lot of sense to me, and understandy the code base is typically what a programmer does on their first day or days on the job. In order to contribute to a project of any size, the craftmen should know what the code currently does. So I agree that using the source is an incredibly important skill.

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog! This week I want to talk about SOLID design principles since it is important for other programmers to read and understand your code so you can collaboratively work together on it. Having code that is not clean and hard to understand will ultimately hinder you in the long term. Having clean code also makes your code easier to write and understand as well. The term SOLID stands for multiple things: The Single Responsibility Principle, The Open-Closed Principle, The Liskov Substitution Principle, The Interface Segregation Principle, and The Dependency Inversion Principle. These principles were made by a Computer Scientist named Robert J. Martin who is also the author of Clean Code. I’m reading that book for CS-348. 

Starting with the Single Responsibility Principle, this principle states that a class should only have one responsibility. Furthermore, it should only have one reason to change. For example, there is a program that calculates the area of shapes. There would be classes that define the shapes themselves (ex. Class Square) and a class that calculates the area of the shapes (ex. Class ShapeArea). The ShapeArea class should only calculate the area of the shapes. 

The open closed principle means that classes should be open for extension and closed to modification. This means that programmers should be able to add new features to the code without touching the existing code because touching the existing code could create new bugs. 

The Liskov substitution Principle states that subclasses should be substitutable for their base classes. This means that if class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A and the method should not give any weird output in that case. 

The interface segregation principle states that larger interfaces should be split into smaller ones. By doing that, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them. 

The last one is the Dependency Inversion principle. The general idea of the principle is that high level and complex modules should be easily reusable and unaffected by changes in low level utility modules. To do this, there needs to be an abstraction between the high level and low level modules so they are separated and you can tell them apart. 

Those are all the SOLID principles. Thank you for reading this blog post!

https://www.bmc.com/blogs/solid-design-principles/#

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

Hello and welcome back to another week of my blog! This week I want to talk about SOLID design principles since it is important for other programmers to read and understand your code so you can collaboratively work together on it. Having code that is not clean and hard to understand will ultimately hinder you in the long term. Having clean code also makes your code easier to write and understand as well. The term SOLID stands for multiple things: The Single Responsibility Principle, The Open-Closed Principle, The Liskov Substitution Principle, The Interface Segregation Principle, and The Dependency Inversion Principle. These principles were made by a Computer Scientist named Robert J. Martin who is also the author of Clean Code. I’m reading that book for CS-348. 

Starting with the Single Responsibility Principle, this principle states that a class should only have one responsibility. Furthermore, it should only have one reason to change. For example, there is a program that calculates the area of shapes. There would be classes that define the shapes themselves (ex. Class Square) and a class that calculates the area of the shapes (ex. Class ShapeArea). The ShapeArea class should only calculate the area of the shapes. 

The open closed principle means that classes should be open for extension and closed to modification. This means that programmers should be able to add new features to the code without touching the existing code because touching the existing code could create new bugs. 

The Liskov substitution Principle states that subclasses should be substitutable for their base classes. This means that if class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A and the method should not give any weird output in that case. 

The interface segregation principle states that larger interfaces should be split into smaller ones. By doing that, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them. 

The last one is the Dependency Inversion principle. The general idea of the principle is that high level and complex modules should be easily reusable and unaffected by changes in low level utility modules. To do this, there needs to be an abstraction between the high level and low level modules so they are separated and you can tell them apart. 

Those are all the SOLID principles. Thank you for reading this blog post!

https://www.bmc.com/blogs/solid-design-principles/#

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

Hello and welcome back to another week of my blog! This week I want to talk about SOLID design principles since it is important for other programmers to read and understand your code so you can collaboratively work together on it. Having code that is not clean and hard to understand will ultimately hinder you in the long term. Having clean code also makes your code easier to write and understand as well. The term SOLID stands for multiple things: The Single Responsibility Principle, The Open-Closed Principle, The Liskov Substitution Principle, The Interface Segregation Principle, and The Dependency Inversion Principle. These principles were made by a Computer Scientist named Robert J. Martin who is also the author of Clean Code. I’m reading that book for CS-348. 

Starting with the Single Responsibility Principle, this principle states that a class should only have one responsibility. Furthermore, it should only have one reason to change. For example, there is a program that calculates the area of shapes. There would be classes that define the shapes themselves (ex. Class Square) and a class that calculates the area of the shapes (ex. Class ShapeArea). The ShapeArea class should only calculate the area of the shapes. 

The open closed principle means that classes should be open for extension and closed to modification. This means that programmers should be able to add new features to the code without touching the existing code because touching the existing code could create new bugs. 

The Liskov substitution Principle states that subclasses should be substitutable for their base classes. This means that if class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A and the method should not give any weird output in that case. 

The interface segregation principle states that larger interfaces should be split into smaller ones. By doing that, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them. 

The last one is the Dependency Inversion principle. The general idea of the principle is that high level and complex modules should be easily reusable and unaffected by changes in low level utility modules. To do this, there needs to be an abstraction between the high level and low level modules so they are separated and you can tell them apart. 

Those are all the SOLID principles. Thank you for reading this blog post!

https://www.bmc.com/blogs/solid-design-principles/#

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

Hello and welcome back to another week of my blog! This week I want to talk about SOLID design principles since it is important for other programmers to read and understand your code so you can collaboratively work together on it. Having code that is not clean and hard to understand will ultimately hinder you in the long term. Having clean code also makes your code easier to write and understand as well. The term SOLID stands for multiple things: The Single Responsibility Principle, The Open-Closed Principle, The Liskov Substitution Principle, The Interface Segregation Principle, and The Dependency Inversion Principle. These principles were made by a Computer Scientist named Robert J. Martin who is also the author of Clean Code. I’m reading that book for CS-348. 

Starting with the Single Responsibility Principle, this principle states that a class should only have one responsibility. Furthermore, it should only have one reason to change. For example, there is a program that calculates the area of shapes. There would be classes that define the shapes themselves (ex. Class Square) and a class that calculates the area of the shapes (ex. Class ShapeArea). The ShapeArea class should only calculate the area of the shapes. 

The open closed principle means that classes should be open for extension and closed to modification. This means that programmers should be able to add new features to the code without touching the existing code because touching the existing code could create new bugs. 

The Liskov substitution Principle states that subclasses should be substitutable for their base classes. This means that if class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A and the method should not give any weird output in that case. 

The interface segregation principle states that larger interfaces should be split into smaller ones. By doing that, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them. 

The last one is the Dependency Inversion principle. The general idea of the principle is that high level and complex modules should be easily reusable and unaffected by changes in low level utility modules. To do this, there needs to be an abstraction between the high level and low level modules so they are separated and you can tell them apart. 

Those are all the SOLID principles. Thank you for reading this blog post!

https://www.bmc.com/blogs/solid-design-principles/#

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

Hello and welcome back to another week of my blog! This week I want to talk about SOLID design principles since it is important for other programmers to read and understand your code so you can collaboratively work together on it. Having code that is not clean and hard to understand will ultimately hinder you in the long term. Having clean code also makes your code easier to write and understand as well. The term SOLID stands for multiple things: The Single Responsibility Principle, The Open-Closed Principle, The Liskov Substitution Principle, The Interface Segregation Principle, and The Dependency Inversion Principle. These principles were made by a Computer Scientist named Robert J. Martin who is also the author of Clean Code. I’m reading that book for CS-348. 

Starting with the Single Responsibility Principle, this principle states that a class should only have one responsibility. Furthermore, it should only have one reason to change. For example, there is a program that calculates the area of shapes. There would be classes that define the shapes themselves (ex. Class Square) and a class that calculates the area of the shapes (ex. Class ShapeArea). The ShapeArea class should only calculate the area of the shapes. 

The open closed principle means that classes should be open for extension and closed to modification. This means that programmers should be able to add new features to the code without touching the existing code because touching the existing code could create new bugs. 

The Liskov substitution Principle states that subclasses should be substitutable for their base classes. This means that if class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A and the method should not give any weird output in that case. 

The interface segregation principle states that larger interfaces should be split into smaller ones. By doing that, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them. 

The last one is the Dependency Inversion principle. The general idea of the principle is that high level and complex modules should be easily reusable and unaffected by changes in low level utility modules. To do this, there needs to be an abstraction between the high level and low level modules so they are separated and you can tell them apart. 

Those are all the SOLID principles. Thank you for reading this blog post!

https://www.bmc.com/blogs/solid-design-principles/#

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