Monthly Archives: April 2018

Apprenticeship Pattern: Draw Your Own Map

This week I read the apprenticeship pattern “Draw Your Own Map”, and it is on the the most inspiring patterns that I’ve read so far. This pattern instructs you to do exactly what its title states, and this is big for me because it gives me a sense of control. This pattern asks you to reflect about your current path, your current position and answer the question “is this really where I want to be in the future?”. If this the answer to the previous question is not a yes, and there is no way to alter your current path to fit with the path that you desire, then the author suggests that you leave, even if you are leaving a “great” title or fantastic salary. Of course what is being asked by this pattern is very intimidating and can be very difficult to actually do when the time comes. This is because from the moment we decide to go to school and take on a new career, the path is already laid out for us and society expects us to follow it, that is: get your degree, get a job, stick with that job and try to climb the corporate ladder there. That being said, there is nothing wrong with the climb if you are happy with where you are, the difficulty comes from taking the risk and abandoning what is sure and working for what you want.

I could not agree anymore with this pattern, and having read it it caused me to think about what some of my goals are. Though I enjoy learning about software and will be very happy to enter the field and work as an employee for a few years, one day I would like to start my own company. I’m sure that making the decision to leave a secure source of income behind a taking the financial risk of starting a company will not be an easy one, but that is what this whole pattern is all about. This pattern has changed the way that I think about the software industry and even working as a whole, it’s made me realize that in the end despite all of the technical challenges and setback that we will face in the professional world what matters is doing what you love, and this is a mentality that I will take with me throughout my career.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

A Different Road

Complementing and maybe even contrasting The Long Road pattern described earlier this week, A Different Road is a pattern about when you stop being a craftsman.

After a long time on your Long Road of being a software craftsman you will have to seriously consider your future in the career and the industry. And as you do this, you may realize you no longer wish to continue the life long journey of moving to software mastery. In this case, you move off the long road and take a different road in your life. We all are on our own life long journeys and this can take us in many different directions depending on the circumstances.

Other software craftsman will not hold it against you if you decide to move on to something else. I personally would never judge someone for deciding they needed to change careers or that this particular career is not for them. I would wish them the best.

And this different path can also lead back to the long road. It is not a clear cut thing. Life is flexible and can the path you take through it can wind around in interesting ways. People can leave the road of being software craftsman and later on realize it was a mistake or it suits them better now. And as the book states, and my personal opinion states, other craftsman would welcome them back with open arms. I would think nothing of it if someone left the field for several years to follow another dream or similar, and then coming back when realizing that that was their calling. I can see myself changing careers and fields in pursuit of my calling depending on how each turns out. As I have stated before, what someone desires in life can change even day to day, as can their goals.

The unfortunate reality is that some in the industry will look down on this, or look at it with suspicion. Mostly those in charge of hiring decisions, most unfortunately. But this is a minor hurdle that can be overcome. It should not dissuade anyone from pursuing what they believe is their path in life. This is something I also whole heartedly believe.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

The Long Road

The Long Road is an apprenticeship pattern that is much more focused on the long term than some others. The situation it is designed for is essentially your entire career path. A craftsman is someone who is wholly dedicated to their craft and improving themselves in this. Someone who holds a genuine excitement and skill for the craft. Because of this, the path to becoming a true master craftsman is one that focuses wholly on the craft. So what to do you do when the opportunity presents itself to you to gain a promotion or a new job that gives you a large raise in income or something similar, but takes you away from your craft?

The Long Road posits that the best path to being a true craftsman is taking, well, the long road. There are no shortcuts, no big jumps that can lead to mastery. And moving away from this long road to being a master is something that should be avoided. This goes against conventional wisdom that most people have, to take the biggest opportunity that raises your station in life when it presents itself. But this does not improve yourself as a craftsman.

The way to do this is to slowly, but surely, build yourself up. Use the other patterns and have a genuine desire to learn and improve. It will take a long time and could be arduous, but it is the sure path to mastery. And it has no end, a life long journey of steady improvement. Such a long journey presents itself a wide variety of possibilities, which should be kept in mind as one walks the long road ahead of themselves.

This pattern definitely has the ability to be controversial for some, because it does go against conventional wisdom. When choosing whether to follow it one has to consider what they truly want in the end. I agree that the best way to being a master software craftsman is not veering off the path of being a software craftsman. But do I stick to this path that stringently? Is my ultimate goal in life to become a master? This pattern forces one to look to the future and question what their ultimate goals are, and I’m still wondering. There probably is no straight answer, as desires change throughout ones life, maybe even day to day.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

The Long Road

The Long Road is an apprenticeship pattern that is much more focused on the long term than some others. The situation it is designed for is essentially your entire career path. A craftsman is someone who is wholly dedicated to their craft and improving themselves in this. Someone who holds a genuine excitement and skill for the craft. Because of this, the path to becoming a true master craftsman is one that focuses wholly on the craft. So what to do you do when the opportunity presents itself to you to gain a promotion or a new job that gives you a large raise in income or something similar, but takes you away from your craft?

The Long Road posits that the best path to being a true craftsman is taking, well, the long road. There are no shortcuts, no big jumps that can lead to mastery. And moving away from this long road to being a master is something that should be avoided. This goes against conventional wisdom that most people have, to take the biggest opportunity that raises your station in life when it presents itself. But this does not improve yourself as a craftsman.

The way to do this is to slowly, but surely, build yourself up. Use the other patterns and have a genuine desire to learn and improve. It will take a long time and could be arduous, but it is the sure path to mastery. And it has no end, a life long journey of steady improvement. Such a long journey presents itself a wide variety of possibilities, which should be kept in mind as one walks the long road ahead of themselves.

This pattern definitely has the ability to be controversial for some, because it does go against conventional wisdom. When choosing whether to follow it one has to consider what they truly want in the end. I agree that the best way to being a master software craftsman is not veering off the path of being a software craftsman. But do I stick to this path that stringently? Is my ultimate goal in life to become a master? This pattern forces one to look to the future and question what their ultimate goals are, and I’m still wondering. There probably is no straight answer, as desires change throughout ones life, maybe even day to day.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

Dig Deeper

Problem

You keep running into difficulty maintaining the code you’ve written because it turns out that the tutorials you followed cut corners and simplified complex issues. You find that your superficial knowledge of a thousand tools means you’re always floundering whenever a subtle bug arises or you have to do something that demands deep knowledge. People often accuse you of having a misleading CV because you don’t distinguish between a couple of weeks of extending an existing web service and a deep knowledge of the issues inherent in maintaining an interoperable and highly scalable enterprise system. What’s even worse is that because your knowledge is so superficial, you’re not even aware of how little you know until something or someone puts you to the test.

Solution

The solution the text offers is to “dig deep into tools, technologies, and techniques. To acquire the depths of knowledge to the point that you know why thing are the way they are.” Depth meaning you understand the forces that leads to a design rather than just the details of the design. Areas where you have deep knowledge feed your confidence and allows yourself to apply your value early when on a new team. Having the background knowledge of how things work gives you the ability to fall back onto that to tackle difficult challenges and allows you to explain the inner workings on to tools and systems you are working on. This knowledge will help you in interviews, setting yourself apart from others because you can explain how a system or tools works. Using primary sources is the best way to understand the deeper workings of things, you can follow the trail of information that leads you to the decisions made along the way and why they were chosen.

This pattern is overall good advice for anyone who want’s to be a software craftsman. It’s important to Dig Deep into something you are passionate about. You don’t have to know everything about programming and software design but you should know a good amount about a few important areas. The ability to fall back on that background knowledge keeps you from struggling to understand new concepts, and makes you an asset to any team because you understand what’s going on beneath the surface. With this knowledge you can help others by explaining things in a clear way. Doing research and looking into primary resources allows you to get to the core of the information. It takes time to learn how things work but the benefits are worth it. This pattern will definitely improve my professional career and ability to help other understand deeper concepts.

The post Dig Deeper 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.

Apprenticeship Patterns: Draw Your Own Map

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

Preparing to Present

Over the past semester, I’ve been working with Dr. Vallejos to build a website for Massachusetts HOSA. At the conclusion of my independent study project, I will be presenting my project to the Computer Science faculty and other CS students. In preparing for this presentation, I came to a couple of realizations about what I’ve learned from this experience.

While I certainly think that I have improved upon my technical skills in CSS and PHP, I think that what is perhaps more valuable is the immense amount of real-world project management experience that I have gained. This experience has already allowed me to build a better understanding of project requirements at work and for the software development capstone project with AMPATH Informatics. Being able to understand the requirements of stakeholders is essential to delivering a product that meets their expectations. Asking the right questions the first time will prevent having to reach out again and again for clarification of the requirements. People are generally very busy and they will not be available to answer your questions or provide you with information. Whether it is a customer, manager, or product owner, it is best not to waste other people’s time with comeback questions because of your own failure to fully consider the project’s requirements.

I also believe that I greatly improved my personal software development process throughout this project. Although it took a couple of mistakes for me to learn, I am thankful that I made these mistakes in a safe environment and lost nothing but a few hours of my time. I was initially pretty careless, making customization changes to the theme files directly on the web server itself, not backing up, and not tracking any of my changes. After losing all of my theme customizations by updating the theme, I decided to make some changes to this process. I implemented Git version control, allowing me to make and test changes locally before pushing to the actual website as well as tracking changes incrementally and allowing me to rollback to any revision, as desired. I also implemented automatic offsite backup in Google Drive, which runs weekly to ensure that even if I do mess something up, there’s always a working copy safely stored elsewhere.

I have always been an avid believer in learning through experience, and the MassHOSA website project has been a fantastic opportunity to learn through my experiences. Not only have I had the chance to both sharpen my technical skills and widen my skill set, I have gained invaluable experience managing a project and working with stakeholders on bringing an idea from the conceptual phase through to a working product.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Create Feedback Loops

This pattern also dealt with a very important aspect in our everyday activities as an apprentice. I will say feedback are necessary because they do not just correct me but they also guide me to explore new directions and track specific causes to my failure. Even though, we got positive and negative feedback, I  strongly believe if you are able to accept them regardless of what kind they are and do a thoroughly assessment of yourself, they can be useful to you. Sometime, you might believe yourself and try counter defends yourself by explaining as to why you did something to a criticism instead of accepting it as a feedback. Getting feedback that enable you to figure out what to do more or less is very important to your success. I have drawn a lot of ideas from this pattern that I think will go a long way to help me stay focus in the software development industry.

For instance, I will be very mindful of what could come of me if I am in the teams where my skills are above average or below average. I will be very careful not to think I am the best when encounter with such situation. I will also not down grade myself too much to the extent that it will destroy me because I am the less skill among the team I am working with; it will give me the opportunity to extend my tentacle and learn more to catch up with them should that be the situation.

I really like the ideas discussed in this pattern. Because, as a newcomer, I am bound to face some shocks regarding feedback I will receiver but with this pattern’s ideas in mind, I think these shocks could be turn into something useful that will help me assess myself. I wasn’t even aware of some of those techniques for obtaining feedback such as test driven development, Exams and certifications that have been discussed in this pattern until I read it. Before reading this pattern and if I haven’t come across it, I will just assume I didn’t meet the standard a company might want if I am not offered a job after attending an interview. I wouldn’t bother myself to do a follow up to know why and what I need to improve on. The ideas in this pattern are really going to help me in the future.

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

Post #31 – Reflection on the “Reading List” Pattern

This week, I will be writing a reflection on the “Reading List” pattern.  This pattern addresses developers who are proficient in their first language but feel that the amount of knowledge to be learned about the language is growing at a faster rate than they can acquire it.  I chose this pattern because I have been visiting book stores to shop for software development literature.  While I feel proficient in a language, I have yet to encounter this worry of an expanding knowledge-base that I’ll never fully acquire.  I do, however, plan to begin putting a reading list together as I continue preparing for my internship in the summer.  Regardless, Oshineye and Hoover provide sound advice on how to manage the books you plan to read and how to reflect on your past reading habits.

Their first piece of advice, ofcourse, it to create a list of the books you plan to read.  This is useful in that it allows you to plan out a kind of strategy that will allow you to learn incrementally and notice patterns, trends, and gaps.  As a side note, they also suggest that you make your reading list public to open the possibility of receiving suggestions for future reading while also allowing others to follow the same plan you did.  They recommend that you treat your reading list as a priority queue, as it will help you realize that some of the books on your list might actually not be worth reading.  To initially create your list, choose books that will broadly cover the area that you are studying, and then subsequently drill down on individual topics as you filter out the ones you find most important or interesting.  I found these tips helpful and will likely use them when I head to the bookstore soon.

They conclude the pattern by describing the kind of action you can take to begin implementing this pattern in your own life.  They recommend listing the books you are currently reading in a text file, and then progressively update the list as time goes on.  As long as you maintain the text file, you will be implementing the pattern.  I began my list today, with Clean Code and Apprenticeship Patterns being first and second in the queue.

 

 

 

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

Apprenticeship Patterns – Find Mentors

In this apprenticeship pattern, the authors present a context in which developing software professionals are “spending a lot of time exploring blind alleys.” They then describe the problem by saying that the software apprentice is “walking along a path” but having trouble being prepared for “what’s around the corner.” In other words, they are describing the difficult task all software apprentices face when trying to learn new skills and master their craft. The authors then go on to remind the reader that every software developer who is considered to be a “master” in the field, has walked the same path and knows exactly what that path entails.

For the solution to this problem, the authors suggest that software apprentices “seek out” those that are considered to be masters who are further along on “the long road” and attempt to learn from them. However, this suggestion comes with some warnings. They point out that as an apprentice it may be more difficult to spot the true master craftsman in the field. To counteract this concern, the authors advise that apprentices ” be supervised by a series of mentors who possess varying degrees of mastery.” Additionally, they remind the reader that “no one knows everything” so it is ill-advised for an apprentice to be under the assumption their mentor is infallible in terms of their software development skills and expertise. By upholding this mindset, the apprentice may be able to recognize their mentor’s weaknesses without feeling like they have outgrown their mentor.

The authors also address the issues and concerns that coincide with reaching out to more experienced professionals within the software development field. They recognize that this task may seem extremely intimidating to most apprentices due to fears of rejection or being seen as “strange” by a potential mentor but they assure the reader that these risks are low when compared to the payoff of being mentored by someone who is much further down “the long road.” The authors also provide testimonial from a developer named Dave in which they illustrate these payoffs. Dave reminisces on the time he “uncharacteristically” approached a more experienced software developer named Wyatt at a conference and later went on to exchange emails with him asking to be mentored. Wyatt agreed to become Dave’s mentor and the two went on to meet periodically throughout a year. Dave describes his interactions with Wyatt as “pivotal in (his) progress” in becoming a skilled practitioner of agile development.

After reading this I plan on taking the authors’ advise by “lurking” on message boards and community web pages with the intention of finding potential mentors and valuable information regarding my particular field of study within computer science.

 

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.