What Hunter Does
I recently had the opportunity to ask some questions to Hunter Anderson about his work with Fenway, a technology consulting company with an office here at Louisiana Tech. Hunter tells me that he has worked with Fenway since early in 2016, and that he has been “the Tech Lead on software development POD that managed web applications for Southwest Airlines.” Given Fenway’s position as a technology consulting company, its employees have opportunities to work on technical projects across a wide spectrum of different companies and industries.
The Communication in Code
Hunter mentions that there are many aspects and decisions to be made surrounding the commenting of code. For those unfamiliar with the industry, no piece of computer code is just worked on by a single person for its lifespan of creation, rollout, and maintenance. Many teams of people across multiple businesses will look through the code at some point, and so comments are left in the code to help describe in human language the less obvious aspects of the code.
How Hunter Handles Commenting
When I ask if Fenway applies set guidelines to instruct their workers on how to comment their code, Hunter tells me that specifics are often laid out by the client, but that “there are some overarching principles should that guide every team.” These include keeping comments professional and explaining complex segments for the next developer who will have to work in the code. However, he also mentions the danger of over-commenting code. When every little piece of code if packed with comments in overabundance, then slogging through it all to find the useful information becomes more and more tedious.
Hunter describes issues that can arise when commenting gets out of hand. One issue that he discussed was that he had seen cases where in-code comments were used to document when pieces were added to the code with which customer request it fulfilled. He explains the issue with scaling such a situation, where multiple customers need things changed and added to the same block of code, and the documentation to keep track of the changes upon changes gets out of hand, and becomes more of a burden than anything useful. Staying concise is just as important a virtue in programming as it is in technical communication.
Meetings between Team Members
The teams that work together to create solutions at Fenway need to stay on the same page if they want to work as an efficient group. Therefore, team members have several types of meetings that they go though. Periods of work are broken into “sprints” in which the workers create solutions to their client’s requests. Each day includes a “Daily Scrum,” which is a 15 minute meeting where each member discusses what they have accomplished since the last meeting, and what they are working on next. During “Sprint Review” meetings, the project is demoed to the product owner and information is collected on any other changes they may need. In a final “Retrospective” meeting, the team discusses the project as a whole and what was good or bad about the project and the process.
Documents that have to be made
When I ask about any kinds of official written documents that Hunter works on, he tells me that many documents are produced from a team effort. Teams will create a rough draft, and then “refine and improve” the document together. He mentions that with Google Docs, the whole process can be done collaboratively and simultaneously by the team members. Hunter also mentions the importance of emails as a paper trail of communication. In-person discussions can be forgotten, but having commitments and plans in writing and emails with their clients keeps everything cleaner.
Andy Curtis, Guest Blogger