This week, I will be writing a reflection on the “Practice, Practice, Practice” pattern.  This pattern addresses developers who want to get better at programming and to expand your diversity of concrete skills.  I chose to reflect on this pattern because I recently accepted an offer for a summer internship and I intend to put in quite a bit of practice before I begin working in June.   Oshineye and Hoover provide solid advice on how to exercise programming skills for those in the ideal situation of having a mentor and those who are left to their own devices.

They begin by saying “Take the time to practice your craft without interruptions, in an environment where you can feel comfortable making mistakes”.  I think environment is a very important element in getting the most out of practice.  The environment in which you practice should allow you to focus completely on the skill you are trying to improve.  Ideally, this environment would also include a mentor that can help guide your practicing and gauge your progress.  Personally, I think an ideal environment could also include peers who are also developing their programming skills because it would provide more outlets for each individual to discuss their work and mentor one another.

They go on to say that the key to this pattern is finding time to develop software in a stress-free environment with no due dates production issues, or interruptions.  This pattern, like the “Breakable Toys” pattern, also stresses the importance of short feedback loops in practice sessions.  Short feedback loops refer to the cycle of completing exercises and quickly receiving feedback on your performance for the purpose of gauging a person’s progress toward a goal.  Short feedback loops can be found in the form of feedback from a mentor or in your own incremental completion of progressively more difficult tasks.

To implement this pattern, Oshineye and Hoover advise developers to find exercises or create their own, and ensure that those exercises will challenge them to at least some degree higher than what they know they are capable of.  They also advise that you should solve and resolve the same issue over some period of time, so that you can see how your solutions change and progress.  I have been motivated by this pattern and I intend to implement it in the coming weeks as I prepare for my internship.

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

“Reading List” is the first in a set of design patterns written to help the apprentice craft a learning curriculum.  As more and more material becomes available, it’s important to carefully select a set of materials that can effectively guide oneself.

This particular pattern is focused on managing material, not necessarily curating it (although it does recommend asking mentors for suggestions).  The recommendation here is to create a list of reading material, and maintain it in a way that lets you see what you have read as well as what you have yet to read.  This allows you to fill in gaps as you go, even if the original list was not particularly comprehensive.  The basic form of the pattern is to keep a text file as a reading list.  In more complex implementations, you can use a version control system to track changes, or use a public form (like a wiki) so that others can benefit.

I am not sure how helpful this pattern will be to me.  While I do understand the need for continued education, and I do enjoy reading, I’ve found that I learn far better from practical, hands-on experience than books, blogs, or powerpoint slides.  While I definitely got a lot out of Clean Code, I got more out of taking Uncle Bob’s suggestions and putting them into practice.  I also tend not to take well to to-do lists, either making or sticking to them — although, perhaps, this pattern would give me an opportunity to expand my horizons in personal organization as well as software craft.

My implementation of this pattern might be a bit more complex than the simple suggestion of keeping a version-controlled text file.  I would prefer to curate a list of resources that contain practical, hands-on components (like Apprenticeship Patterns, although many of those are fairly abstract), or to learn from tutorials that give me room to experiment.

You could even apply this pattern to parts of a book (like Apprenticeship Patterns) that is more fragmented, or easier to digest across multiple readings.  Perhaps also to a video or article series.

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

This apprenticeship pattern is the flip side of last weeks pattern, expose your ignorance. Now you have to confront the ignorance that you exposed to your team mates and coworkers . You start simply by choosing one thing you do not understand fully, and then researching and working on it until you fill in the gaps in your knowledge about that tool or framework or some such. You work on fixing your ignorance on your own time, until a point where you decide to continue working on it or move to something else you are ignorant in.

This is a very necessary pattern for an apprentice, especially paired with the previous pattern of exposing your ignorance. They both need to go hand in hand for an apprentice to advance themselves as a craftsman. What happens if one uses one pattern but not the other?

If someone uses the expose your ignorance pattern without confronting their ignorance, then they do nothing but stay ignorant. Whenever you are tasked with doing something you are ignorant of, you simply state your ignorance and then… that is it. You just shrug and say that you ca not do it. Without ever learning about things you do not know, you can never advance as a craftsman.

However, while confronting your ignorance does lead to learning and advance in oneself as a craftsman, doing only that without exposing the ignorance in the first place can be problematic. If apprentices only ever learn in their own time without letting anyone know that they were ignorant in the first place, everyone would silently work on their own problems without ever asking for help. There would be no discussion of issues, or allowing others to help you get through something you are having a large amount of trouble with. The reason one exposes their ignorance is to gain help from those on the team more experienced than them.

This pattern made a lot of sense to me. The part of the pattern section that discussed what confronting your ignorance without exposing it is was like was familiar to me. In the past I had moments where I would try to work on a project on my own for a long period of time, and bash my head against a wall until I figured it out. Then realizing I could have just asked someone else for help and reduce my frustrations by an enormous amount. Nowadays I was always strive to get past my pride and ask for help, to avoid a lot of headache and to help myself learn more effectively.

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.

In class we did a group activity which had us work together in teams of five and conduct a software technical review. In a software technical review you have a specific role in which you must fulfill specific duties. There are four roles. The producer, review leader, recorder, and reviewers.

Producer–  The producer is the person who created the work that is being reviewed.

Review Leader–  The review leader schedules the review meetings, prepares materials for meetings, conducts meetings, and writes the review report.

Recorder- The recorder’s job is to take notes of what is being said. They also document anomalies, decisions and recommendations.

Reviewer– The reviewer(s) job is to prepare an individual reviewer issue sheet that is given to the review leader before the meeting. The sheet contains all of the issues that the reviewer found with the code.

There are three different types of software technical reviews. The walk through, technical inspection and an audit.

Walkthrough- A walkthrough is an informal meeting with the producer and the colleagues. There is little preparation and little documentation.

Technical Inspection- A technical inspection is a formal process and includes training.  There is sufficient and budgeted preparation time and the team ic very carefully selected.

Audit– An audit is a review that is held by an external group. The purpose of audits are to ensure that you are conforming to standards.

Why would we waste our time with such a complicated process when we could just look for faults individually? Well, there are many good reasons why we hold reviews and why the process is so important.

Reviews push developers to communicate with one another, it gives an opportunity to train new employees, it helps management report progress in the business, you find defects, it builds team morale and it gives the customer reassurance that the product comes out the way it should.

Going into your first review is probably nerve wracking. If you can remember the proper review etiquette, you should be golden!

Be prepared– There is nothing worse than an unprepared team member

Be respectful- it is the golden rule after all. Review the product not the producer.

Avoid discussions of style- Not everyone likes the same thing you do, as long as it is not wrong leave it be.

Provide minor comments to producer at the end of meeting 

Be Constructive- help others, don’t bring them down.

Remain focused- identify issues and don’t try to solve them yet.

Participate- Do not try to get the spotlight, it can be annoying.

Be open- the results of the review should be available to the entire organization.

My source of information was our class slides, but you can learn more about software technical reviews here:

http://www.softwaretestinggenius.com/understanding-software-technical-reviews-strs

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

Recently while working on our final project, my partner and I ran into an issue involving the positioning of courses on a schedule. We were trying to figure out a way to place elements (courses) on top of another element (the schedule). Naturally on our way to a solution, we stumbled upon absolute positioning. Using this we were able to place the courses in their correct positions on the schedule.

Even though that solution seemed to work, there was something about it that didn’t sit right with me. For whatever reason, the thought of using an absolute position on the page to place elements on another element just did not seem like a smart thing to do. What would happen if I added elements above the table?

Because the table uses the default position, its placement is based on its order in relation to other elements. However, the courses are using an absolute position relative to the page.

The solution to this is relatively simple, but not necessarily one of the most obvious solutions for those who are new to CSS.

CSS Positioning Blog

In the blog CSS Positioning: A Comprehensive Look, Louis Lazaris discusses the main types of positions used in CSS’s position property. The positions are:

• static – positions the element statically, following the normal flow based on its order in relation to other elements, typically unnecessary.
• relative – behaves the same way as a static element, except that if you give it a positioning attribute, such as: “left: 20px;”, it will be offset 20px left from its original spot.
• absolute – causes the element to be completely removed the the document’s normal flow, no longer interacting with other elements. Absolute elements are positioned relative to the page, or to its parent assuming its parent is relatively positioned.
• fixed – behaves similarly to absolute elements, however it won’t move when the document is scrolled or relatively to its parent element.

The key part of this is that absolutely positioned elements can be changed by added a relatively positioned element as its parent. Thus the simple solution to our problem was just to change the schedule (or table) to use a relative position, even though we weren’t making any changes to its position visually.

Not only does this change where the elements are positioned relative to, it also makes it so that if I were to set the width or height of the course’s container using a percentage instead of pixels, it would be relative to the size of the schedule instead of the page.

The reason I chose this blog was because it contained exactly what I was looking for: a way to place absolutely positioned elements relative to its parent.

Source: http://blog.teamtreehouse.com/css-positioning

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

In this article, Greg Sypolt talks in brief about the role of AI as a software testing assistant.  I chose this piece because it combines a field I’m interested in (AI and machine learning) with the content of my software testing course.  I am interested in AI task automation already, so a piece that dovetails these two topics is a perfect fit.  The author has chops as well — he oversaw the conversion from manual to automated testing at his company, and offers training to help other teams transition to automation.

Sypolt starts off by outlining three uses of AI in testing:

1. Automatic test case generation that reduces level of effort (he abbreviates as “LOE”) while maintaining consistent standards.
2. Generating test code or pseudocode from user stories; a user story is a use case or use sequence for some kind of product (software or hardware).
3. Codeless test automation, or testing without writing tests as code.

He then outlines the necessity of properly training the testing bots, and some of the difficulties that may be involved:

1. Identifying the proper training algorithms.
2. Collecting a massive quantity of useful data.
3. Ensuring that bots behave in a reasonable fashion from a given set of inputs, and ensuring that they exhibit new behavior (generate new tests) when the inputs change.
4. The training process never really ends; each new set of tests and results gives the bots another data point to learn from.

I firmly believe that we are at the very start of a revolution in machine learning.  Why not apply those principles to software testing?  There are, of course, a couple of issues that arise which Sypolt didn’t mention: quality of tests and accuracy of tests.

A point firmly pushed by other articles and texts I’ve read is that quality is more important than quantity.  There can be little difference between running ten tests and running one hundred tests if the extra ninety don’t teach us much of anything.  The trick isn’t to create an AI that merrily runs thousands on thousands of unit tests; it’s to create on that identifies the important tests which reveal faults we don’t know about and confine itself to executing exactly those.

It’s also very important to ensure that the AI has learned properly and is up to standards — and that means testing the AI.  Which means testing the AI that tests the AI, and it’s digital turtles all the way down.

I can take away from this article two things: Firstly, it’s reasonable to combine two fields that I’m interested in (AI and testing) and that resources exist or will exist to support the two together.  Secondly, the field of testing is constantly and rapidly changing.  Additional learning is crucial, just like AI systems continue to learn from each new piece of data.

Article link

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