Craft over Art

For this week’s pattern I have chosen “Craft over Art”. It describes of the pattern where you are given a problem and you are solving it for a customer. You can do it the simple and tested way or create a new solution that will let you express yourself as a programming artist and will look nice on the resume. It describes the conundrum of making something simple and useful right away or making something beautiful and complicated and not usable right away.

I have chosen this pattern because I have struggled with it many times before in my professional career. Many times have I been given a problem to solve for a customer and I had to decide to make it the quick and easy way that I already know will work, or should I do it some new, more complex way that can possibly save some time in the long run. The way that the “Apprenticeship Patterns” describes it should be done with a mix of both solutions, make it somewhat easy but tested way but with possible improvements. I think this is a good approach but there is a catch to it in my opinion, what is acceptable to the customer? Can they wait for a different, nicer way or quick, not totally efficient way will suffice? I think in the moments like that it is up to a Project Manager or the customer to decide and anybody working on this should act accordingly.

We as programmers and developers are in the end a service providers, unless we work for ourselves and do not have any hard deadlines, we need to stick to timelines and or project deadlines. What works and is tested very often is the right solution because time spent on implementing new solution can be something that ultimately may cause a project to fail and nobody wants that. The book also says that we as craftsmen need to provide at leas a minimal level of quality, and I think that if something is well defined and tested and works has that kind of quality. Why go for a new fancy way that might now work 100% of the time, or it requires a lot of time to be understood by somebody else. My boss likes to remind me that “if it is not broken do not fix it, because you will only cause more headaches to yourself and somebody who will work with my code later”.

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.

Pratice makes permanent

Apprenticeship Patterns is a really interesting book to read and I actually learned a lot from it. For this week, I read about the pattern “Practice, Practice, Practice” and there are a few interesting things I found about it. The pattern starts with a quote by George Leonard saying that masters they don’t just get better by devoting in a particular skill, but they practice getting better and the it gets more enjoyable to perform basic moves over again once they are better. I can definitely agree on this as I think we all have been through a rough beginning of doing something, but when we are better, we would think back how easy it is to do those basic task and we would do those rather than more complex problems that we have to face later on during the process of mastering a skill.
Then the author went on to talk about practice is a long process and it has to be done without interruption, and in a comfortable environment of making mistake. At this part, it is interesting to learn that practice in software development can be in a stress-free and playful environment. For me, I always think that the best way to practice is to join a group project, and there would be one or another thing that would stress me out so easily like if I work in a small group or alone even on a small size project, at some point we would be overwhelm with the amount of work that we have to deal with, or too much concern about security, features, accessibility, etc. and after reading this chapter, it makes me question about my priority on different aspect of the program and maybe I should change in order to get better.
The author also brings up another interesting point is to try to do a bit different for each time we practice and choosing the right thing to practice is very important. In my opinion, I think that should be the most optimize way to discover new things and not to miss out any important things while we are still on the basic level.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Unleash Your Enthusiasm

Further reading into chapter 2 I find that I relate to many of the patterns in this chapter, However, in my reading tonight I felt a specific interest in UnleashYour Enthusiasm. Unleashing Your Enthusiasm is about taking your passion for the work you do and exercising that passion. Think of it like starting at a new gym. You may not know what to do or the correct ways to do things, you may feel weak, confused, and embarrassed. Even with all of these negative feelings you know that you are excited to learn and get stronger. You may need to ask trainers for help and exercise your want for learning despite the embarrassment. This pattern is primarily about understanding that your passion used correctly is itself a valuable attribute to contribute to a team or teacher.

I find that this pattern goes hand in hand with Exposing Your Ignorance and that are one in the same. In order to unleash your enthusiasm you must be willing to expose your ignorance. If you are new to a team or project you are undoubtedly going to have to learn. You have to know that other more senior members will know more than you and will have to take the time to teach you, which for them may seem counterproductive. Being alright with your ignorance is the first step toward unleashing your enthusiasm. UnleashYour Enthusiasm is more about seeing the value in your ignorance. With this drive for knowledge it can help rekindle the flames of other more senior members who have plateaued and have their fire of passion die down to a smolder.

I find I experience the fear of exposing my ignorance quite often. At this point in my education I am always learning in everything I do. It sounds silly because it’s so obvious, but everything I have learned was once something I did not know. This means I had to overcome some fear and pursue that knowledge. Working with teams of my peers there is often a wide range of knowledge based on experience and backgrounds. It is scary to put myself out there and explain that I may not know something that they are all talking about it, but I have had the courage to do so. Many times I have done this and then had a pleasant conversation with my peers about having the drive for knowledge. It doesn’t pay to be afraid of taking the chance, that chance is knowledge and it gives others the opportunity to share something with you. I find that this unleashing of enthusiasm sparks a great pep talk for any team.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Machine Learning Problem Framing

Last week, I gave an overview of my planned independent study project. This week, I’ll give a bit more detail on what I’ve done.

I have a habit of preparing for classes before they start. I buy the text books, get an overview of the material, and prepare to apply learning techniques throughout the semester. This helps me identify problems before the semester starts and address them in class as I go. Likewise with this project, I had hoped to get as much as I could done with machine learning before this semester started to hit the ground running with the software portion. Naturally, my ignorance led me to assume the problem was easier than it actually is. After a great conversation with a communications professor, I realized the problems I was trying to solve had to be broken down.

Counter-intuitively, the broken down problem is more difficult. To recap, my project involves machine learning and audio signal processing. Although great leaps have been made in this field and many problems have been solved, they mostly use clever tricks to achieve the results they get. Take speech recognition for example: your text-to-speech software transcribes nearly 100% correctly. Machine learning models can use huge datasets of audio, as well as commonly-spoken phrases to decide which words you’re most likely to say. The result is that mumbling, stuttering, or ambient noise is a bit more forgivable. On the contrary, transcribing each and every syllable is not nearly as easy, and in fact it’s a problem that has yet to be solved. That’s a shame, considering I was hoping to transcribe an audio sample into phones as part of my process and I somehow doubt I can do it without first getting a PhD.

This realization has led me to take a quick course on machine learning problem framing. It teaches the process of developing an hypothesis and developing a model to prove it, as well as resisting the temptation to shoehorn a problem into machine learning when a heuristic solution is as good or better. I did manage to find examples of using machine learning to solve some of the problems I wanted to (dating back 20+ years, even), but unfortunately they were each limited in scope and would be difficult to use to make a cohesive app. My goal isn’t a Frankenstein project.

In an effort to dig deeper, I’ve also done an introduction to Pandas tutorial, and started on a Tensorflow tutorial. These are surface-level in and of themselves, but help in understanding the higher-level frameworks. My hope is that understanding the basics will allow me to create a model that has an exciting application. In the meantime, I can implement the prerequisite features in software: audio recording and signal processing.

I’m going to dive into more specific problems as the semester goes on and I get more comfortable with the topics. I’ve already come up with a list of ideas and find myself wanting to write posts on small things like Android project flavors and build configuration. Posting thoughts and lessons in a public place has been great for accountability, and my goal is to know these technologies inside and out 4 months from now.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern Review 1: Expose Your Ignorance

This blog is the first in a series of posts that will be covering software craftsmanship patterns I find compelling from Apprenticeship Patterns by Oshineye, Hoover. With these posts I aim to summarize the pattern and explain its relevance to me and software development as a whole.

In short, the “Expose Your Ignorance” pattern is aimed at dealing with a fundamental issue with people living in industrialized society. Software developers are under extreme pressure from managers and team members to know how to use many technologies. Especially in the case where those relying on you are under the impression that you understand how to do something, it can be extremely hard to make it clear that you actually don’t know how to do that something yet. Acknowledging the fact that there is a push to reassure everyone that you know everything and going directly against this is essential to learning as quickly as possible. This is the gist of “exposing your ignorance”.

I constantly feel the pressure to reassure my colleagues that I understand whatever it is we are talking about. I’ve always felt like doing otherwise would make me seem incompetent when in reality it is a sign of maturity. Immediately after reading this pattern I feel as though it made a fundamental shift in my approach to problems. It makes complete sense that mastering this pattern would yield great benefits throughout my career. “The most obvious way to expose your ignorance is to ask questions”(Oshineye,Hoover). Being able to ask questions whenever I am unsure of something can greatly abridge the time it takes me to learn a given skill. Also, in a world where we have near infinite knowledge at out fingertips at all times, I feel that a desire to learn is a much greater skill to possess than “knowing” a lot.

I find it very interesting that the authors make a distinction between software craftsman and experts. I agree that not being able to ask questions can shoehorn a developer into becoming really good at one skill, yet never branching out into others. I personally feel like being an expert rather than a craftsman can make a career in software development grow stale. Being able to nurture a desire to learn is important not only in the context of a software development career, but in everyday life as well. “Expose your ignorance” truly is a pattern that I feel will improve my career as a software developer.

 

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

This apprenticeship pattern concerns something that most people are afraid to do. Nobody wants to look ignorant in their profession, because we are expected to be competent and knowledgeable and that is what we are paid for.

The main idea is simple: don’t pretend to know something you don’t. This leads to headaches in many ways, but most importantly it will make it more difficult to learn what you need to learn. In software there is an endless supply of new technology to learn and throughout a software career, there will be countless projects that use something you don’t understand. Admitting this fact and asking others for help is the quickest way to learn it. At the same time, you will build trust with your team and show that you know how to learn.

We are trained to look competent from a young age. We need good grades to get into better classes, a better college, the best job possible. Getting a poor grade reflects lack of preparation rather than exposing ignorance, so it’s natural to think that we will be seen as unprepared if we show ignorance in our work. If this fear is realized, it is likely a problem with the culture.

The most important idea in this pattern is showing others that learning is part of the software process. Speaking from experience, I’ve never judged a coworker or classmate for something they didn’t know. Each of us has our expertise, and if I don’t have time to teach something, I can at least be there for support if they need it. What would become an issue, is when someone says they can get something done and only much later admit that they can’t, when it’s too late to get them up to speed.

Likewise, people have always been willing to help in the times I’ve admitted not knowing. More often than not, the response has been mutual frustration. I’ve saved myself a lot of worry by admitting confusion and hearing from tenured employees that “it’s just confusing, I don’t really understand it either”. The result is a collaborative effort where both people come out knowing more, and having a better rapport in the future.

This pattern is an excellent reminder that we’ll never know it all, and that pretending to is not a long-term solution. The suggested action is to write down five things that you don’t understand about your work, and showing it where others can see it. This seems like a good tactic, and I plan to do this on a whiteboard at work. Coworkers who know better than I will hopefully guide me in the right direction.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

Breakable Joys: what I was missing in my breakable toys

As I picked through the list of Apprenticeship Patterns one of the earlier ones jumped out to me, as it seemed fairly obvious from the name what it was. Upon reading the description I was correct in this assumption and further I had experience with this particular pattern – even if outside of an apprenticeship. That description being a “toy system that [is] similar in toolset, but not in scope to the systems you build at work”. If you were to insert “school” instead of “work”, then I have built breakable toys for the same reason the book describes: to try and fail in private so that your successes can be applied to a real project using the same technologies, but your failures do not come at the expense of said project.

I have a sense already that many of the patterns I pick this semester will be those that I either have experience with or involve skills I feel insecure about. This being a pattern I feel familiar with I hoped to see if I was applying it correctly, and I wasn’t, at least not completely. First, the book stresses that a breakable toy should be like any real toy, fun. I think this is at least one hang up I have had with my own toys is that I try too hard to make them into potentially repurposable that I can use in whatever project I am training for. Instead, I think moving forward I will try first to make something fun, but overengineer it like the book says, such that I can gain as much experience possible from some silly little program.

Additionally, the book mentions making a little wiki as your toy, and this I had never thought of. Initially, I had read this as meaning thoroughly documenting the toy you are building. It makes perfect sense and follows logically one of the best points that has been made to me about learning, which is that the best way to do so is to teach. However, upon subsequent readings I realized they meant developing a wiki with your selected tools. While this certainly would help foster an understanding of yours selected tools, it would clash with the previous goal of being fun, at least in my mind. Instead, despite it being a misunderstanding, I think much could be gained from documenting one’s progress on a breakable toy. Considering I have a spike project to work on currently, I think I will apply these lessons as I begin.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Introduction to Apprenticeship Patterns

If you are close to graduation as a Computer Scientist or Software Developer, the market for you will be huge. There are unlimited opportunities in the Tech field but should really be prepared for that. How do you see yourself in the professional world? Where do you see your starting point, and what are your future goals? An inexperienced Software developer, you have to be an apprentice, and following the long way of this journey, you will be a master, unless something goes wrong – like really wrong.
Reading “Apprenticeship Patterns” by Adewale Oshineve and Dave Hoover, will give you the first jump on the “Software Craftsmanship” world.

The term Software Craftsmanship is used to illustrate the skills you need to be successful in this journey. Being a Software Craftsman, you don’t need to have coding skills, you need creativity, you need to build your crafts, design your ideas, solve the problems avoiding complexity. Sounds fun, right? Yes, it is actually fun if you enjoy it, and if you know how to start from point zero. Imagine if you are a baby: you need to learn how to walk before traveling the world. You need to learn how to talk and read before being a scientist. So, you must be an Apprentice and follow the pathway that is important for you. One step at a time, learning from your masters and applying your skills will make you jump to the next phases. However, if you need to maintain your skills you don’t need just to practice them, you should also pass them to the other people.

At this point, you will not be an apprentice anymore, you will be a journeyman! Being a journeyman does not mean that you do not need to learn anymore, you should still follow your mentors, they will still be your masters who open new doors of your mind. You will still be focused on your craft, your ability to develop your skills, to advance the complexity of your designs. As a Journeyman, you should have created your portfolio, which represents your experiences, your knowledge and your ability to be a craftsman.

Next step, you will be a master. As a master, you will be an apprentice: you will keep learning and develop your skills, you will be a journeyman: you will keep building your portfolio and expand your craftsman ability, and Master: you have to move the industry forward and pass your knowledge to the new apprentices. Being a master means that you have all the needed skills and experiences to be a true craftsman. You will have the ability to design, architect and construct your crafts.

As you go through this journey you will need to make important choices. You should always need to be careful about what you choose, money or experience. Money can give a good life, financially, but skills and experience give you more opportunity and open more doors for your future. Ready to start your journey? Good luck…

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

Apprenticeship Patterns Guidance for the Aspiring Software Craftsman Reaction

summary

what was interesting

what was the most useful

what changed my opinion

what do i disagree with

what chapter was the most relevent

overall thoughts

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

The White Belt

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye is the book assigned to us in my Computer Science Capstone class, it seems like a rather interesting read from the first look I had at it. The book describes different problems and solutions that a lot of software developers struggle with at different times in their careers. It has a rather easygoing approach to those things and is a good read that should be done by every upcoming and experienced developer, in my opinion. I know I will read it.

I was blown away by the intro of the book, which is chapter 1, and then and chapter 2 made me read it all the way. It was hitting close to home in my professional development. It made me think about all the things I’m going through right now, how my enthusiasm for my job went down and how I do not learn new things as well as I used to. Especially the white belt part makes me read it over and over. I realized that I grew complacent in my current job status and the change that is coming soon does not make me excited about the new possibilities at all, the fact that I’m dreading learning new skills for work is rather laughable since that was the way I got to where I am today.

I can see how this book will be a very useful tool for anybody who works in software development. Just by glancing at the introductions of the other chapters I can see that it will definitely be a very good motivation and inspiration to move things along, either it be my schoolwork or professional work. Simple things like what the book describes, for example chapter 6: Construct Your Curriculum, have been put on hold for me because I thought I didn’t have to do much anymore and I was all set when it comes to my skillset.

I have a very good feeling about this book, and it purpose of inspiring people to grow as developers, it is very thought provoking and makes you think critically about yourself and the problem we all face. I will most likely read this whole book as soon as I can to increase my enthusiasm for the work I do, and knowledge I’m amassing both through school and my profession. It definitely makes me want to be better but at the same time I’m understanding better that I need to learn things slowly, learn to walk before I can run. I have grown lazy when it comes to programming and I want to change that after reading just parts of this book. I will try to read the whole book as soon I can.

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.