Category Archives: Week 3

The Benefits of Unit Testing

This article by Ekaterina Novoseltseva on DZone (DevOps Zone) is about 8 benefits of unit testing. In the article, she breaks down how her company, Apiumhub, utilizes unit testing in order to stay Agile. She also breaks down several of the benefits of unit testing including relation to Agile, quality of code improvements, reduction of costs, and several others.

I found this article interesting because while I knew some of these benefits of unit testing, I never thought of some of the specific examples like the relation to Agile. She points out that unit testing facilitates “safe refactoring” by forcing developers to use the smallest functionality possible for testing a single unit. I agree completely with her in regards to Agile especially after she pointed out that this goes hand in hand with extreme programming and test driven development.

Personally, I’d never used test driven development at a large scale before so I’ve never really considered the benefits. The section on the benefits to design really pushes the idea that test driven development makes code more optimized, with cleaner designs. When breaking everything down into a unit first, figuring out what each unit is, and defining what the functionality is through tests, you are forced to consider the designs of the actual functions before writing them.

Another point that she makes that is probably one of the most important to the business is that unit testing reduces costs for the development process. Unit testing finds bugs early in the process because the tests are either written before the code is even written, or before moving onto the next snippet of functionality in order to stay Agile. This means that application-breaking bugs are less likely to be found in the later stages of the development process like “system testing” or “acceptance testing” as Ekaterina points out in the article.

I wholeheartedly recommend this article to anyone who is relatively new to unit testing and doesn’t is any bit unsure of the possible reasons why unit testing is so important. I can see myself utilizing unit testing more in my personal projects in the future as I already try to work on them in some resemblance of an Agile process.

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

A Review of Software Engineering Radio’s Conversation with eBay’s Randy Schoup (ep. 109)

I was interested in what someone from such a large website, eBay, would have to say about its architecture. There was a lot of takeaways from it, summarized in four main ideas: partition everything, use asynchrony everywhere, automate everything, and design the system keeping in mind that everything fails at some pint in a large distributed system. Although this is an older talk (from 2007), these all seem to be sound systems to design something so large. He referenced a theorem from 1998 that he said took a while to get traction. Likewise, I am sure his design principles have proven true for the last ten years.

To be completely honest, there was a lot of industry-specific jargon used that went above my head. I took a lot of notes though, and looked up the terms I did not know. I still found it very interesting, though. I found it the most interesting that someone designing one of the largest websites in the world was incredibility realistic of the shortcomings of everything designed. It seemed that everything designed had to have a degree of compromise of what was expected of it. He referenced the “CAP Theorem,” where it seemed you cannot always have all three parts that it stood for — “Consistency,” “Availability,” and “Partition tolerance.” He also was realistic that everything can fail, especially  when the system gets as big as it gets bigger. For some reason it surprised me when someone from such a prominent company would admit this.

Something else that really surprised me what he said one of their biggest limiting factor was something I would not have expected, which was power consumption. He claimed that some companies’ database centers can use more energy than a local power station can support. This makes it much more important to design efficient database structures, especially in a company that deals with data in several petabytes.

It just boggles my mind how reliable websites like this are for millions upon millions of consumers. He said $2,000 worth of transactions were made every second, and that was over ten years ago. The site has grown since then. This gave me some great ideas to run with, as I hope to one day work for a company as esteemed as his.

Link: http://www.se-radio.net/2008/09/episode-109-ebays-architecture-principles-with-randy-shoup/

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

The Development Abstraction Layer

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.

CS@Worcester – Fun in Function 2018-02-04 21:52:46

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.

Apprenticeship Patterns: Craft Over Art

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.

Concrete Skills

The Concrete Skills apprenticeship pattern seems to give the assertion that entry level software developers should maintain a quality understanding of the “basics.” Employers can and should have the expectation that new hires can contribute in some substantial way, right from the gate. I feel this patterns’ context stresses the importance of understanding the fundamentals of programming, essential algorithms, and computer science in general. One of my main responsibilities as an undergraduate is to learn and maintain such fundamentals that any reputable employer should expect from any entry level software developer.

The authors describing this pattern do a great job of highlighting some pivotal “concrete skills” one should strive for as a newcomer to the field. For instance, it is suggested that gathering a solid understanding of one’s first programming language is a primary skill we should strive for. I realize that my first language (Java) is just the beginning of a myriad of languages I expect to be exposed to in the near future. I ought to practice Java to the point where I can roughly draft code for any rudimentary procedure at any given moment. My potential employers need to know that I grasp the basics of vital data structures and design patterns. I should strive for a solid understanding of these fundamentals to a point where I can just start shelling out code whenever it is asked of me. When I can do this to a point of solid understanding and self-confidence, this will be the day that I can say that I have done so by successfully applying the Concrete Skills pattern.

What I found most interesting about this pattern was the implication of the importance of learning how to play “buzzword bingo” to get your foot in the door as an entry level Software Developer. I must say I found this amusing in the sense that I pictured someone at an interview saying something like “…yeah I’m familiar with APIs, ASP, IDEs, J2EE, NPM, SQL, UML…” and all sorts of other alphabet soup. But at the same time, the term “buzzword bingo” was especially enlightening for me. Any quality resume/CV I’ve ever encountered for inspiration had similar keywords sprinkled throughout them. Thus I have set a personal task for myself to become familiar with such popular buzzwords to a point where I can at least explain them. Proficiency would be great, but I feel I can begin to apply the concrete skills pattern by at least researching more about these recurring buzzword terms. I feel this, along with striving and maintaining a solid understanding of my “first language” Java, are great ways to apply the concrete skills pattern.

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

Emptying the Cup: The White Belt

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.

Apprenticeship Patterns: Emptying the Cup (Chapter 2)

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.

Unleash Your Enthusiasm

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.

Thoughts on “The White Belt” apprenticeship pattern

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.