Post #27 – Reflection on the “Dig Deeper” Pattern

This week, I will be writing a reflection on the “Dig Deeper” pattern.  This pattern addresses developers who feel that feel that they only possess a superficial knowledge of some of the technologies, tools, and techniques utilized at their workplace.  The problem that arises, in this scenario, is that the developer begins having trouble with maintenance of his or her code because it was written with only superficial knowledge that is likely to be forgotten.  I chose to reflect on this pattern because I really like the advise that Oshineye and Hoover provide about how to truly immerse yourself into the learning process and transform your superficial knowledge to deep knowledge.  I also agree that having a deeper understanding of the everyday things in your life can be incredibly beneficial in a number of ways.

The primary importance of deep knowledge is that allows you to explain the inner workings of systems you work on, which will distinguish you from colleagues that are unable to do so and show others that you are more proficient in working with that system.  I recently had an interview for an internship and many of the questions I was asked were related to my contribution to and understanding of past projects.  The recruiter got back to me a short time after the interview and informed me that I ‘knocked the interview out of the park’ and I was offered the position – I accepted!  Oshineye and Hoover explain that deep knowledge can also act as a safety net in that you can refer back to how you gained your deep understanding in that area to gain confidence about learning something new.

They recommend that developers ‘dig deep’ into the tools and technologies involved in the project they’re working on, until they have a deep understanding of how those tools and technologies work and why they are being used.  One of the ways somebody can dig deep into something is by getting their information from primary sources.  Primary sources understand the problems they were trying to solve.  Another way somebody can dig deep is by looking at tutorials and guides regarding the thing(s) they want to learn, and asking themselves if there are underlying computer science concepts behind what you they are learning.

I think this pattern will prove to be a useful piece of knowledge in my repertoire.  I will try to apply it regularly in my career and I strive to become a person who truly understands the tools and technology utilized in the software I am working on.  I have used this pattern and seen it work, first hand, and I hope it will lead me to more success in the future.

Advertisements

Post #14

As a follow up to my previous post about our upcoming group-code-review, I thought I would review another article I found that compares group code reviews to peer code reviews.  “Peer Review vs Group Review: Which Is Best For A Code Review?“, written by Stephen Ritchie, provides an answer to this question as it is often asked by clients in the field.  Ritchie begins by stating that that both methods have advantages over the other, depending on the development team’s particular circumstance.

Ritchie defines a group code review as a code review in which a portion of the development team comes together to review code while the rest of the team provides feedback for improvement.  He believes that group code reviews engage the individual developer, the team, and the team’s leaders in ways that evoke experience and judgment to find and fix problems.  As I mentioned in the previous post, Ritchie also believes that effective group code reviews let tools perform fundamental review and let the focus of the developer review to be a spotlight on parts of the code that do not utilize the best practices and designs.  Ritchie feels that discussing code, as a group, serves as an excellent transfer of knowledge from the more experienced to the less experienced.  If a group code review is conducted properly, it opens up a healthy dialog between developers about the chosen conventions and why adherence to them is important.  The main advantage of group code reviews is that it allows for a group of developers to learn and grow together, improving relationships and cultivating the transfer of knowledge and experience.  The main disadvantage of group code reviews is that it can be challenging to get all group members up to the same working pace.  Group code reviews can suffer if group members become diverted or distracted.  This can potentially lead to a worsening of relationships among developers.

Ritchie defines a peer code review as a code review in which one developer’s code is reviewed by another developer.  A pair of developers would meet and one developer would review the code of the other, and provide constructive feedback.  Peer code reviews are similar to group code reviews but their personal nature generally ensures a thorough and properly done review.  The main advantage of peer code reviews is that pairs of developers who conduct peer code reviews have likely collaborated and formed a bond in the past that allows for issues to be better-handled and addressed immediately.  The is also somewhat of a disadvantage in that it necessitates that you have a decent relationship with the person you are reviewing with, if you wish to conduct the review effectively.  A bad relationship between the reviewer and the developer being reviewed can result in a lack of collaboration and dialog and, inevitably, a poor review overall.

Ritchie believes that, for teams that have many developers with years of experience, it is more efficient to conduct peer code reviews.  This is because the time of identification to resolution of an issue is much shorter, due to the personal relationship between peers.  Ritchie prefers peer code reviews to group code reviews because they quickly improve the developers’ skills while simultaneously making progress in the implementation.

I agree that peer code reviews are more personal and allow for faster feedback and resolution to issues but I also appreciate the fact that group code reviews bring many resolution strategies and points of view to the table.  For the small projects I have worked on, I have always found peer review to be more effective – but I think that, because larger projects generally require more developers, a group code review is necessary to get all the developers on the same page.  I think that the code we are reviewing could be done by a pair of developers, but I am looking forward to seeing if the group review will provide better solutions and insight.