This week I read a post of Joel Spolsky, the CEO of Stack Overflow. This post talks about the development abstraction layer that software developers work and are responsible for in a software business. The author started with the story of an experienced software developer who left a big software company to start his own business. He was confident that he could develop and sell software by himself because a lot of software products he worked on for the big company were sold pretty well to many customers. However, after months he could not get order from customer to support his own business and living cost. Finally, he had to come back to work for the previous company. He wondered why he failed with his own business. He was pretty sure that he lacked good marketing for his business. Marketing simply stands for everything in business of creating and selling software that he and many developers don’t understand all about. He was wrong. Software is a conversation, between the software developer and the user. However, that conversation requires a lot of work beyond the function of software development. It takes marketing, yes, but also sales, and public relations, and an office, and a network, and infrastructure, and air conditioning in the office, and customer service, and accounting, and a bunch of other support tasks.

Software developers design and write code, layout screens, debug, integrate, and they check things into the source code control repository. The level that a developer works at is called the development abstract layer, which is too abstract to support a business. The development abstraction layer needs an implementation layer — an organization with many support tasks – that takes their code and turns it into products to customers. The top priority of a software team manager is building the development abstraction layer that all developers only concentrate on and they don’t have to concern about other tasks.

The post gives us an idea of the scope of work that a typical software developer works for. A successful software company should have good support tasks across the board to help developers do their best and turn their works into quality products to customers. Moreover, if we plan to start a software business, we should understand which tasks we need beyond the development abstraction layer to keep our business running well.

Article: https://www.joelonsoftware.com/2006/04/11/the-development-abstraction-layer-2/

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

The “Expose Your Ignorance” pattern encourages software apprentices not to feign competence when they don’t know how to do something, but instead to nurture and showcase their ability to learn by admitting that they don’t. According to the writers, the problem is most likely to come up when your managers or team members assume or want confirmation that you know something. You can still reassure people in these situations, but with your capacity to learn instead of by being dishonest about your abilities. In this way you can build trust by showing you can be counted on to figure out how to do what’s needed, even if you can’t do it yet.

Exposing your ignorance doesn’t seem like such a difficult thing if there are no expectations of your knowledge level beforehand, but letting someone know you don’t understand something they thought you did seems almost unbearable, especially in a situation where your ability to do your job depends on understanding it. I hadn’t considered that I might be put under pressure to project an image of having knowledge in an area I don’t, so I’m glad to have some ideas of how to respond to it before it becomes an issue.

Another thing I hadn’t considered was the idea that becoming an expert is something to be avoided, or at least not the main goal. The authors explain that to be a software craftsman, you can’t become confined to a specific domain or skill. This is what naturally happens if you’re too afraid of exposing your ignorance to learn new things. Here too, the idea of having a greater goal to pursue is helpful to me. I would rather be a software craftsman than an expert in one area, because it would help me to keep my options open. Being good at only one thing also means you run the risk that the skill will one day become obsolete.

The advice to publicly post a list of things you don’t understand about your work surprised me. It seems like it would be a painful thing to do, but it does also seem like it would help you get used to putting this pattern into practice. It might end up something I try in the future.

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

This week I chose to cover “Craft over Art” from chapter 3. Craft over art is an essential piece to becoming an apprentice. When you are faced with a task, an opportunity to try something different and creative arises. Sometimes you have to sacrifice beautiful work in order to deliver a solid working project. Building… Continue reading Apprenticeship Patterns: Craft Over Art →

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

In this stage of the Apprenticeship patterns, it gives us an overall idea of what it’s like to be an apprentice. In terms of learning different programming languages, especially if its a new language, it will be hard to learn it because you have prior knowledge on the concepts of basic programming actions. According to the Apprenticeship patterns, “we have to be able to put aside our past experiences and preconceptions to allow new knowledge in. This is especially difficult when trying to learn your second programming language, because it is likely the first time that you have to sacrifice productivity in order to improve your skills.” When you think you are knowledgeable in programming languages, you are unable to take in the maximum depth of learning you are expected to take in as well as limit the ability to discover new possibilities.  To put this in the modern work place, team members will always have a certain level of competency in the work that they do. Pride will be one of the factors that may be an obstruction to the team unless each of them are able to allow themselves to unlearn what they learn in order to learn new things in case problems should arise in the future.

What I found interesting about this pattern was how the metaphor “white belt” was used.

“Wearing the white belt is based on the realization that while the black belt knows the way, the white belt has no choice but to learn the way.”

In my mind, I thought it made sense because as a true beginner, you know nothing at all to start off. To be taught at first, it is normal to think that the first way you learn would be the right way. At that point you allow yourself to learn, and therefore, you are able to discover possibilities you hadn’t known.

This Apprenticeship pattern was useful because it made me think of when I first learned my second programming language, which was Java. When I transitioned from C++, I thought learning Java wouldn’t be as hard as I thought it would. It ended up being harder because I wasn’t allowing myself to learn the full principles and rules of the language. I took shortcuts when I wasn’t suppose to, and I had to learn that the hard way as I struggled through learning it. Soon after, I took it step by step and allowed myself to learn it the right way.  I completely agree with this pattern because not only it applies to programming, but it can apply to anything you learn in life, and it starts by wearing that “white belt” first.

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

The authors began this chapter with a really thought-provoking story of a Zen master and a young philosopher. In this story, the young philosopher sets out to learn the ways of the Zen master but every time the zen master would begin to describe his own practices the young philosopher would cut him short and start talking about how he does things and how it might relate. Essentially, the Zen master is never able to complete any of his thoughts because the young philosopher keeps interrupting and talking about his own experiences. This goes on for a while until the Zen master goes to pour a glass of tea and he keeps pouring until the the cup is overflowing. at this point, the young philosopher tells the zen master to stop pouring to which the zen master replies, “If you come to me with a cup that is already full, how can you expect me to give you something to drink?”

I think that the short story about the Zen master and the philosopher is extremely relatable to learning how to become a software developer. In the field of programming its’s really important to approach problems with an open mind and to not disregard certain techniques or practices due to the fact that they aren’t familiar to you. By emptying your ‘mental’ cup and being upon to new ideas you will inevitably be much more successful in developing and honing down your programming abilities.

The authors go on to describe the best way to get your software development career started. They suggest that you choose one specific programming language and “become fluent in it.” Some of the things they proposed to get help get you started are using that programming language to build a “toy” application, trying to solve real problems using that language, and reading the language’s specification documentation. The authors recommend using tools like git to publish and/or contribute to open source projects. The benefits of contributing to open source projects include the fact that you can get feedback on your code and advice from experienced professionals that already know the language your learning. Overall, I’d have to say that they present some really good advice on how to get your programming career started and I wish that I had read this when I was starting out as it probably would have saved me a lot of headaches.

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.

Unleashing your enthusiasm focuses on bringing enthusiasm to your new team.  It emphasizes approaching your new team with energy and readiness to learn as much as possible.  The book explains that a lot of new developers may be hesitant to appear too enthusiastic, thinking that the team that they are integrating into might not be welcoming to the new injection of enthusiasm into their work place.  Enthusiasm is infectious though and in just a short period your enthusiasm to work and learn will spread to the other team members and the overall work environment will rise.  I agree that this works not only in software development, but in any industry.  During my time in the Army there were plenty of days that were miserable at best.  No matter what the condition was though if you had a positive energy and enthusiasm it made the day a little easier.  When one person showed up with this type of attitude they were quickly berated and rejected by those who were determined to stay miserable.  Soon enough though the positive attitude spread to others and everyone had seemingly found what little good and joy there was to find that day.  Work then seemed easier and the day moved quicker.  No one could tell you any specific time or event that the change occurred.  The tone of the team just kind of changed as the enthusiasm spread.  I think that a high morale and enthusiasm for the job will greatly improve the overall morale and performance of the team.  I found the study from the aircraft carrier interesting.  The idea that new employees mixed with seasoned vets of the industry makes sense, but is often overlooked until it is brought up.  The vets share their experience with the new employees while the new employees are able to share the newer ways of teaching and question the way things have been done in order to change procedures if necessary.  When the employee is in the middle of these two extremes is where changes are made and new procedures and policies replace the old.  It’s important to for all to remember that this process doesn’t work without a mutual respect and open mindedness towards all.

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

The White Belt pattern arises out of an issue I’ve encountered — I’ve learned one language fairly well and have some practice with others that follow similar paradigms, but have found it to be more challenging to learn new things.  Tools, skills, and languages that are different from what I know don’t come as naturally as it seems they should.

This apprenticeship pattern seeks to solve that problem through a mindstate and a more practical approach.  It teaches the mindset of a willingness to feel like a beginner again, to fail and maybe look foolish in order to adopt a childlike ability to absorb knowledge.  More practically, it suggests a learning strategy: adapt a simple, known software project from one language to another, using the paradigms of the new language to their fullest rather than trying to write “Fortran in any language”.

As I said before, I have notice that I struggle more and more to acquire new skills.  Whether that’s environment setup, picking up new languages, or adapting to a different set of tools it seems to get harder as I learn more.  That doesn’t bode well for my mental plasticity, and this pattern provides a useful solution.

The most useful aspect of the pattern, for me, are what the authors calls the mindset of not knowing.  Of willingness to ask questions, start from the beginning (whether that’s following tutorials that feel beneath me, or finding help elsewhere).  Of taking a harder road to learn things right and come up with a better and more nuanced solution rather than patching together something that’s familiar and comforting.  This speaks to something I learned in a high school gym class: we learn and grow the best and most successfully just a bit outside of our comfort zones.  I need to push myself into the “learning zone”.

The action advice is also something that I can take away and use moving forward.  While I don’t have a lot of time now, I am interested in refactoring old projects into new languages as a learning exercise, to blend something that I know well already with something brand-new.

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

http://www.codesimplicity.com/post/kindness-and-code/#more-1673

This week, I read this blog post titled “kindness and code” authored by Max Kanat-Alexander on his blog, Code Simplicity. The post is about the toxicity of the software development community and Alexander is trying to help improve it by explaining the importance of kindness and treating fellow developers with respect. I chose this post to write about because I am interested in improving the typical harshness people tend to deliver to each other on the internet. As somebody who plays a lot of remarkably toxic video games such as league of legends or call of duty, its easy to see how that type of bad behavior can also exist in software development. In fact, you can find horrible behavior common in any field regarding random community communication on the internet.

I believe people tend to lash out over the internet more often than in real life. This is because they are mostly anonymous and care less about good manners or reputation when it involves somebody they may not ever meet again. This allows somebody who is given any slight reason to judge you, the justification to barrage you with hate. This type of behavior is pointless as Alexander writes “There is no value to being cruel to other people in the development community” as it seems like an instinctual reaction for some people to point out anothers flaw just to make them feel bad about it. Take an example of any normal person trying to learn something new for the first time, either with a video game or in software development, and they make a mistake. If another person online is able to see their mistake, they might be aggravated by it enough to insult and verbally abuse the poor person who is just trying to learn.

Usually this occurs when somebody more experienced looks down on a newer person however, not necessarily. As the internet matures like an older brother, more and more experienced people are picking up the habit of lending healthy advice down towards the still learning user, and that is what Max’s blog is about. Coming from an experienced point of view, he offers techniques of constructive criticism to the software development community in hopes that they will help each other rather than judge each other. While today it is common sense to simply ignore and accept the inevitability of horrible comments on the internet, it is becoming more of a growing trend that not everybody on the internet has something hurtful to say. That means progress! Even though it is difficult to imagine an internet without any angry anonymous trolls waiting to insult your every move, I believe the internet community is getting better and better every day.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.