Monthly Archives: January 2018

The White Belt

I’ve been in the Computer Science (CS) program at WSU for quite some time now. Though I’ve learned a lot in the process, I realize that graduating in May will be just the beginning of my career. I still have a lifetime responsibility of learning ahead of me, and I must find a way to effectively approach this everlasting task.

The textbook references The White Belt as what I feel to be a highly effective pattern to apply when learning new things. The idea is to keep an open mind and bring a proverbial “clean slate” whenever approaching something new. I’m going to use the example of learning new programming languages to further explain this pattern.

We focus a lot on the Java programming language in our school’s CS program. Because of this, I feel I have a proficient understanding of that particular language. We have branched out into other programming languages as well, such as C and TypeScript. But since Java was my first programming language I’ve become proficient in, I always find myself comparing the new languages I learn to Java while I am learning them. The White Belt pattern has changed the way I feel I should be approaching new material. I shouldn’t be making assumptions of new technologies based on my knowledge of other topics, no matter how comparable they may seem. I should be applying The White Belt pattern when approaching new ideas.

For instance, consider a scenario where an algorithm that has been coded in the most effective way known possible for the Java programming language. I should not assume that the code will be just as efficient in a different programming language just because some of the terminology may be similar. I should approach learning a new programming language in the same fashion that I learned Java. A good start would be to consult the community who are well-versed in the skill I am seeking to learn. I ought to start at the very beginning, practicing beginner projects before attempting the more advanced ones. As simple as a “Hello World” exercise may seem based on prior coding experience, The White Belt suggests I should “set this previous knowledge aside.” Based on reading the context of this pattern, I will always try to approach new topics with an open mind and a “clean slate.” This applies not only to the example of learning new programming languages, but also any new situation I may find myself during my professional career.

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

Apprenticeship Patterns Chapter 1 Reaction

The introductory chapter to Dave Hoover and Adewale Oshineye’s Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman is a set of definitions for the focal topics of the book – the apprentice, the journeyman, the master and apprenticeship itself. Perhaps more importantly, and certainly of greater impact in my mind, is the brief discussion regarding some of the primary goals that an apprentice ought to have. The role of the apprentice as strictly a learner was one that came as obvious, but I think what made the read novel for me was the methodology suggested. Specifically, Hoover recalls the pivotal moments of his learning, and a majority of them involve having lacking work examined by more experienced developers, having it improved by working with those developers, and taking lessons away from those experiences.

I actually reread Dave’s recollection several times to reprocess it, and I was alarmed at how much it made me think about myself and how I began and, of course, where I ought to be taking myself through the start of my software development career. The shock Dave describes of going from your first language – which you’ve spent ample amounts of time attaining proficiency in – to one that behaves or looks very differently is something I’m familiar with. I count myself very fortunate to have had the weak exposure to programming that I did (Game Maker Language in freshman year of high school, if you were curious), because looking back on it, the task of learning even Java after that first language was especially difficult. I have in fact wondered about this idea over my time in University; I’ve thought for the past couple of years about whether or not we are mistaken to only mandate exposure to Object-Oriented Programming in our classroom. From what I understand, the CS program is beginning to walk students into other paradigms here and there. However, I cannot help but ponder whether my fellow students are able to program in any other paradigm – I know I certainly have a hard enough time with it, and I’ve made a point to try and work out Haskell.

I digress. Where I was intending to go with this was: I recognize and can identify the situations Dave describes in myself and in my own experiences. I find the idea of putting out work with the intent of having it get picked apart to be profound and daunting, but sensible. And, the more I consider it, the more I think that it would be an intellectual dishonesty to do otherwise.

Admittedly, I payed far less attention to the definitions and dissections of the journeyman and master. For the moment, I’m still trying to get myself into the mindset that I think I ought to be now: I want to begin displaying my work for the world to see and have it critiqued. I want to hear of my shortcomings and inefficiencies, then use the ideas of people smarter than I am to turn myself into a peer on equal footing with those people. It is, I should think, rewarding in multiple ways to develop a humble frame of mind that can receive criticism and can be incorrect without feeling some level of inadequacy. Often one’s greatest inhibitor to success is oneself, and I can only imagine that this applies to me just as much as to any other person. Therefore, I should not assume that I can break these barriers on my own; it will take the guidance and wisdom of those who have already attained such success. And so begins the story of the apprentice.

From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – The Long Road

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye isn’t a book for those looking to take the easy road. It isn’t a book for those looking to quickly ascend in to management. It isn’t a book for those looking to become wealthy fast. What it is however, is a book for those looking to truly become masters at what they do. In chapter 3, a pattern called “The Long Road” [AP] is discussed. It discusses how in today’ society there is a big draw towards quickly rising to fame and wealth [AP]. People want to get rich quick and without much effort [AP]. The pattern discusses how for most people that is unrealistic [AP]. More importantly, if you truly want to be great at your craft of choice, then jumping into management isn’t the right path to take [AP]. Expect to sacrifice promotions and salary increases and make other sacrifices along the way [AP]. Some people may aspire to go into management. If that case, there is nothing wrong with that and no one is going to stop you. But that’s not what this book is about.

I agree that to truly become a master software developer, you have to continue to be actively developing for a long time. The field is forever changing and changing quickly. Each passing year you continue to hone the skills you currently have while picking up more new skills along the way. Eventually you’ll get to the point where you can handle any situation. I feel when you reach that point; when you have an answer for everything (or almost everything) relating to your field then you truly have mastered what you do. To get to this point will take a long time. I also feel that this road is not for everyone. Not everyone wants to be developing software into their 40’s or 50’s. Some may want to move on to other things. Some feel that the role of a developer is merely a stepping stone for higher ranking positions. There is nothing wrong with this philosophy. Not everyone aspires to be a master developer. Personally, I am not sure if I want to become a master developer. I’m not sure if I want to be a true developer into my 40’s or 50’s. I feel this is a question I will answer for myself as time goes on and my career develops. I don’t think anyone my age (I’m 21) has an answer to this question. However, if you are one of the one’s who do want to be a master, then long road is the only way to get there.

 

Link to pattern in the book: http://chimera.labs.oreilly.com/books/1234000001813/ch03.html#the_long_road

 

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Staying Open to New Ideas

After a few years of using mainly one language to accomplish programming assignments, I will certainly admit to becoming complacent with Java. If I was asked to write pseudocode, my mind immediately begins object orientation and even begins running through some of the Java syntax. While this can be helpful, as I feel my ability to think in Java means that I may be well on my way to becoming bilingual, there are also many drawbacks to complacency.

Applying this Java-like thinking to problems in other languages or under other frameworks is where problems may arise. Rather than being open to discovering and developing new skills, the existing knowledge becomes a hindrance to learning. Attempting to apply existing knowledge to problems of a different sort or in a different language may slow progress, and make learning even more difficult and frustrating.

The solution offered by Hoover and Oshineye in Apprenticeship Patterns is to put on The White Belt and allow oneself to be ignorant by putting aside accumulated knowledge and experience, leaving no choice but to learn the way through trial, error and reflection. Treating new learning opportunities in this way allows for more deeper understanding and helps to create more smooth communications with members of the existing community.

I recently decided to expand my software development experience by studying JavaScript. While I feel confident that I have stumbled over the most difficult learning hurdles at this point, I wish that I had read this apprenticeship pattern before my attempt. I feel that I had a difficult time initially overcoming how fundamentally different JavaScript is, and often found myself grasping for the comfort of Java. It wasn’t until I took a step back from what I was doing that I realized I needed to open my mind to fully understand and appreciate JavaScript for what it was rather than how it was different from or similar to Java. The example that Apprenticeship Patterns uses, a lottery program written in three languages (Java, Io and J) is especially telling of this fact.

While I would have previously described myself as open minded and always willing to learn, I believe that The White Belt pattern has helped me see a more valuable way to approach new learning. I will certainly be using the ideas of Hoover and Oshineye the next time I attempt to learn a new programming paradigm.

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

CS@Worcester – Fun in Function 2018-01-24 23:39:17

The first chapter of Apprenticeship Patterns introduces the main concepts used throughout the book and outlines the book’s purpose. Software development is treated like the kind of craft practiced in medieval guilds, where there’s an apprentice stage, a journeyman stage, and a master stage. The book is a pattern language meant to serve as a guide for navigating a software apprenticeship, consisting of solutions to common problems people encounter in the apprentice stage. A software apprenticeship is defined as a stage where you, as a new software developer, are working to find better ways of doing things; as well as people, jobs, and situations that force you to learn those ways. It’s a period composed mostly of focus on yourself and your growth (as opposed to responsibilities to others) and continuous learning.

Before reading this, it hadn’t occurred to me to treat specific jobs as opportunities to learn and improve the craft, rather than the learning of the craft being a prerequisite for getting a job. The mindset demonstrated in this introduction seems to emphasize valuing software development as a craft in a way similar to the way I’ve seen artists talk about valuing art for the sake of art. It’s an attitude I didn’t really expect to see in a STEM field, but it’s one I’m very open to, since I’ve found that believing in the inherent value of the work you’re doing (instead of being motivated only by outside factors) is one of the best ways to maintain passion. It also would’ve never crossed my mind to think of a career in software development in terms of medieval craft guilds, but the roles outlined in the book made me want to fail a lot in the beginning so that I can learn from it and not fail when I have greater responsibilities later on.

The idea that you’re not supposed to know how to do everything at this stage is one I found comforting. Reading Dave’s story made me feel less insecure about my own late start in this field of study and my ignorance, which I think was partially the point.

The prospect of having to carve out your own apprenticeship because the industry isn’t currently structured to support it is somewhat intimidating, but I’m also intrigued by the idea and think this approach could be fun. Pursuing a goal beyond and bigger than meeting the requirements of a certain job or just plain advancement naturally seems more enjoyable.

I expect this book will be useful to me because I need challenge in order to be happy, and it promises advice on how to avoid pitfalls that will lead to me losing the challenge that made me choose this major in the first place. I’d be interested in reading this book even outside the context of this class because I’m unsure about basically all aspects of trying to start a career, and having some ideas of how to navigate it will be helpful.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman- Chapter 1

Woah !, I really enjoyed reading the book , Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. I have read many books and been in the software-learning role for a while but this book spoke entirely about how I had been seeing this field and how i felt it should be done. I am very emotionally connected to this life craft. I am currently a CS student and like this author, it wasn’t until my junior year in college that I began to see a future with this program for me. I had excelled in class and managed to perform okay but when I I tried to create new project for myself to work on, I found my self always hitting a blank wall. It wasn’t till last summer that I figured what was going on. I was studying how to program like it was a task to be done instead of a skill that needed to be cultivated. When attempting to cultivate a land there are many steps that has to be taken. The soil has to be prepped, and catered for the incoming crops. Everyone wants to be great at programming but you can’t expect a 3 year old to read a college level book. In programing, the gap between the proficient and beginner is so large but unlike ages and height, its not easily noticeable. Its it only when you decide to create something from scratch that’s when you realize and begin to appreciate the people who were able to build Operating systems and large software programs from scratch. This goes to prove the apprenticeship of the software journey. Those people that are able to do that, often don’t hold very high degrees when they were building those programs instead they invest time and dedicate their efforts into making a change by creating and developing something that will benefit the world. From this reading I do agree and believe that one has to invest time, sweat and effort into learning the art of thinking like a programmer. It is only then can you start to see what they can see and think like they can. In programming, if you can’t see and logically make the connection, it’s almost impossible to create. Teaching an individual what to see and how to interpret it takes time and is also greatly individualized. Just like apprenticeship, everyone has their own pace and cognitive strength and moving forward should only be allowed when what is needed is grasped. In a perfect world, everyone that graduates in software development should be able to code quiet adequately but such is not life and I believe and agree with this book in the sense that if you should approach software development as a personal piece of art that continually needed to be perfected, you will become a successful programmer.

 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

Chapter One

Chapter One of Apprenticeship patters was a very helpful and interesting reading. For the most part I agreed with mostly everything this chapter has talked about. I love the idea that programmers are broken down into three different categories which are the apprentice, the journeyman, and the master. Within these different categories I still believe that I am an apprentice. As an apprentice I aim to keep learning new programming languages and to expand my knowledge for me, myself, and I. So, I am always looking for tutors, “masters”, and any kind of outside sources to help me learn as much as I can. Next stage would be the journeyman. These people are still trying to improve themselves and their knowledge of programming language however they are educated and experienced enough that they can talk to other journeyman and interact with other people. Finally, there are the masters who has reach the point in their lives that they are proficient enough in programming (however still learning because you can always teach an old dog new tricks.) these are the people who become mentors, teachers, project heads. They are the people that the apprentices and journeyman aspire to be and look to for help.

 

There was also a section of the chapter where it talks about the community of practice united and defined by overlapping values. Few of them are things I believe that a lot of new programmers should follow which is “A willingness to experiment and be proven wrong.” This is very important because we should not be afraid to make mistakes. With mistakes comes a learning/teaching experience. This shows you that there are things that you don’t know and that is fine because you are not supposed to know everything. If you are willing to make those risks then that just means that you accepted that you are not the best and is willing to learn from others. I also like the value that talks about “A belief that it is better to share what we know than to create scarcity by hording it.” I honestly think that this is something a lot of people should follow I understand with today’s society money rules the world. However, knowledge should not cost an arm and a leg to get. With education we should be able to get information from others to help each other out and to increase productivity with each other.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Software Craftsmanship

I tried to go into the Apprentice Patterns with an open mind, but this was difficult as my preconceived notions of an apprentice craftsman generally aligned with the old timey examples the first chapter described as not being what a software craftsman apprentice would look like.

The first chapter did a good job avoiding my worst expectations for the text, advocating for a return to past apprentice master relationships or some other ridiculous notion. These worries were not at the forefront of my mind, but they were at the back hoping they turned out to be unwarranted. Which they were thankfully.

The focus on being determined, hard working, and eager to learn and advance was definitely expected and aligned with what I believed a good software developer would be like. I agree with the assertion that people are not simply talented and skilled to begin with, it takes work to get there and continued work to maintain the level of skill achieved. Being talented or not is often seen as a binary value that you have or do not, stifling some who believe it is simply out of their grasp. I enjoy the text dissuading this line of thinking.

Being a software craftsman means to be skill centric rather than process centric is an idea that I’ve implicitly come to myself, but never really thought about in terms of consequences. The downsides of a skill centric field is petty obvious when it was stated, but I never considered it before. My eyes have opened somewhat and I feel like I will be seeing careers around me in terms of skill or process centric for some time.

When the text described the roles and differences between apprentices, journeymen, and masters it was about what I expected. It was somewhat vague, but that makes sense given how undefined things can be in the real world. What I found interesting was the mention of how some apprentice patterns would not work for a journeyman and that failure for them and masters cause much more harm than an apprentice’s. Failure is not discouraged for an apprentice, it is seen as a learning experience. So the limiting of options as one gains more responsibilities and failure becomes less acceptable was something I did not consider. Obviously as one gains more responsibility and experience failure should happen much less, but it is interesting to consider if the pressure of not being allowed to fail limits growth or not.

Overall, I am quite excited to keep reading the text. It seems to be geared specifically to people in my situation. Having several patterns that give guidance when I might not have any provides a nice safety net I can fall back on instead of guessing what works.

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.

All About Apprenticeship Patterns

I read through Chapter 1 of Apprenticeship Patterns a few times and really like the approach of seeing software craftsmanship in different levels.  When I think about it I guess that I’ve always thought of software development as either able to do it or not and getting better at it as you practice.  I like the idea of seeing it as being an apprentice, a journeyman, and a master.  It puts software craftsmanship in the same boat as other skills and trades.  It makes it sound like something that is more attainable to more people who are willing to practice at it.  Many times in just the past three and a half years of school when I tell people that I am majoring in computer science quickly say that they could never do that.  The truth is they could if they wanted to and practiced at it.  It is a skill/trade like plumbing or car maintenance.  You may not know anything now, but if you went to school for it or took the time to learn on your own you will grow your toolkit.  Seeing it as three levels is nice and makes it seem like less of a constant climb, it still is because the field is always changing, but when you reach the next level it is a little accomplishment rather than a constant climb with no specific advancement.  As the book says though that the definitions of apprentice, journeyman, and master are not the same as you would find in a dictionary.  For other trades there are unions set up and standards set in place that dictate when someone moves from apprentice to journeyman and journeyman to master.  There is no such set up for software development.  That would be an interesting development in the field if there was a governing body of some type and software developers created a union type set up.  I don’t believe that it will happen though as it is a new skill/trade and not seem the same as a plumber or an electrician.  For software developers it will be a more gradual and seamless transition rather than taking a test or working in the field for a certain number of hours.  As a portfolio grows and more skills are learned a developer will start to either search for a job at a higher level or start taking on more responsibilities at their current company.  Then without realizing they will be in the role of a journeyman and have a few apprentices that they will be around and either intentionally or unintentionally inspiring them and helping to shape their careers.  Then years later after working on many projects and taking leads they will make another gradual transition to become a master of their craft.  These won’t be as pronounced as your more traditional skills and trades.  I don’t think that it will change anytime soon because it is viewed differently than physical trades.

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

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman

The Introduction to the textbook sets the goals for the book and the targeted audience.

“One of our goals for this book is to inspire the people who love to create software to stay focused on their craft.”

“This book is written entirely for you—not for your boss, not for your team leader, not for your professor.”

What Is Software Craftsmanship?
The book considers software craftsmanship as some overlapping values, listed here are those values with my thoughts on them.

  • Growth Mindset, the belief that you can always improve and find faster, easier ways to do things if you are prepared to work. Failure should be seen as an incentive to change your approach. “Effort is what makes you smart or talented” – Carol Dweck. I think the growth mindset it very important to quality and success and avoiding burn-out.
  • Constantly adapting to constructive criticism and learning to improve areas where you are lacking. This idea is essential to ensuring quality work and keeping up-to-date on the best practices.
  • A desire to be pragmatic rather than dogmatic. This important trade-off allows you to get things done and avoid spending too much time making things “perfect”. This ties in well with YAGNI.
  • A belief that information is better shared than hoarded. Everyone benefits from shared knowledge which is the basis for the idea of Open Source projects. This allows a greater population to improve shared code and learn how things work.
  • Ability and willingness to experiment and not worry about failing, because you are able to learn from the experience.
  • Taking control of and responsibility for our destinies rather than waiting for someone else to give us the answer. I think this is basically saying to take initiative, or try to think differently to solve a problem.
  • Focusing on individuals rather than groups. This book is meant to help you as an individual improve your skills.
  • A commitment to inclusiveness. I think this is a good rule in everyday life but works with being a craftsman.
  • We are skill-centric rather than process-centric. It’s more important to be highly skilled than using the “right” process. I think it boils down to it pays to have the knowledge to use your skills in any situation, not having to rely on a template of tools.
  • Situated Learning, the idea of learning a skill around those using those skills. Working your first job as a software developer would be a good example of this.
  • Based on the introduction, this text appears to have very useful information for someone who wants to improve the quality of their work and what they contribute. The book includes good lessons that can apply to any aspect of life. It stresses the idea of improving skills by being open to learning from others, learn from mistakes, and never stop improving.

    The post Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman 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.