Rubbing Elbows

Until I can obtain a job, I will be working by myself most the time. This will inevitably impact my learning because working with others allows shared knowledge and experience for the parties to teach each other. The “Rubbing Elbows” pattern from Dave Hoover’s and Adewale Oshineye’s Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman discusses the benefits of collaborating with others.

The pattern mentions “Pair Programming,” a technique where developers code side-by-side. I have not coded in this manner in a long time. When I took my first computer programming class my best friend and college roommate was also taking that class. Given the circumstances, we often collaborated on assignments. While we did collaborate, we often coded the assignments solo and discussed our methods and problems. I cannot count the times that one of us would get stuck with an issue that the other had no problem with. I learned then that different programmers will find multiple solutions and methods while developing. These diverse techniques are worth examining and potentially adopting.

“Pair Programming” is not the only way to practice “Rubbing Elbows.”

“The goal is to find ways to expose yourself to the daily working habits of other skilled people, and observe the ways in which they gradually refine those habits into even greater skill. These habits extend beyond coding and into all aspects of software development.”

This statement from the pattern shows the type of knowledge the pattern will provide. “Rubbing Elbows” is not necessarily about learning new coding methods but about observing the small, often unmentioned details of a developer’s work habits. Because of this, developers can rub elbows by working on any part of the development process, including presentations or papers.

Working in LFP’s update module team provided plenty of learning opportunities for me. Some opportunities were coding related, while others were about project management.

I have a couple ways planned for practicing this pattern. Now that I am graduating, I think this would be a great time to collaborate on a project with my friend again. We have not worked together in years and this seems like an opportune time. He has been working in development for awhile and I am sure he has a lot for me to learn. I also plan on participating in the LFP spike-a-thon this summer. This will let me work on something familiar while presenting opportunities to work with other developers.

Sweep the Floor

I will hopefully be starting my software development career soon, and with that I will be joining a new team. Dave Hoover’s and Adewale Oshineye’s Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman’s pattern “Sweep the Floor” suggests “volunteer[ing] for simple, unglamorous, yet necessary, tasks” to contribute to the team. I will be one of the least experienced members in the team, so I’ll need to be proactive working on the more tedious work. Doing these tasks is more than just gaining trust from the team but also showing respect for the more experienced members. The experienced members should be focused on the work that requires their experience and not bogged down by simple chores.

“Examples of these tasks include maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, eliminating technical debt, setting up the project wiki, updating documentation, acting as a sounding board for other people’s ideas, and so on.”

While it may not be fun work, these tasks are still important, and the team will be grateful for the effort. To practice this pattern, “Sweep the Floor” suggests finding the tasks that the team has been putting off and do them. The pattern however warns of the potentiality of being perceived as incapable of more vital work. This can be averted by working on more complicated issues or personal projects alongside the simple chores.

When reading through the list of example tasks, I could see the tasks that often held up work during our LFP sprints with code review being the biggest culprit. I can see how completing these tasks would be good to focus on when joining a new team. Not only will the team benefit from these tasks being done but completing these tasks will also give valuable insight into the project. With code reviewing, the opportunity to study the unfamiliar parts of a project is presented. Work on the documentation was also often put off or forgotten.

I think this pattern makes sense having the inexperienced members handling the simpler tasks. These tasks are chores to the experienced members of the team but are learning experiences for the inexperienced.

The pattern includes an experience of a developer working in a formal software apprenticeship. The important part of the story is when the apprentice watches Uncle Bob Martin, a master craftsman, take out the trash. The apprentice’s mentor then scolds the apprentice for allowing the job to go undone and having a master craftsman take care of it.

“It is not the job of the master craftsman to take out the garbage.”

This pattern has made clear what I will need to focus on when entering a new team as an inexperienced developer. I will need to find the simple, more tedious jobs and work on them while furthering my learning. “Sweep[ing] the Floor” will help with my integration into a team by familiarizing myself with the code base and team practices. I will also build trust with the other members of the team. Once I gain enough experience and trust, I can then start to work with more complex, interesting work.

Retrospective 3

It’s time for this project’s last sprint retrospective. At the end of the last sprint, I had started implementing our needed endpoints for our API and had rough versions working. So, my first focus for this sprint was getting the API working [link]. Our definition of done requires testing for an issue to be considered done. Thus, I made learning how to automate tests for the API a priority [link]. I ended up finding automated testing through Postman and it’s CLI. Using the Postman IDE, I started writing tests for our endpoints [link] and this allowed me to become better acquainted with how endpoints should behave. Postman’s built in test system made creating the tests relatively simple, as it supplies common test code snippets to use. The tests I wrote check for correct response status, response time to be under 200 milliseconds, request has content type header, and returned data. At this point, the work on the backend was nearly done and was awaiting review.

While the API server was under review, I started working on learning Docker. [link] Since I had worked mostly on the backend, I started with getting the server containerized. Once I had the dockerfile written for the server, I then had to figure out how to use docker-compose to link the database and server in containers. [link] Then I started to split my attention between fixing up the server, writing docker configuration for the backend, and reviewing work.

Most of the backend work was writing up documentation. Our team had a dockerfile written for our frontend, so I started writing a compose file for the entire module. This worked well except I could not figure out how to obtain the backend container IP for the frontend. I have since found it has something to do with the nginx proxy we used in our frontend dockerfile.

Once the planned work for the backend was done, I had some time to address the additional requested endpoints from another team. [link] After completing the endpoints, I reviewed work and assisted where I could. The final issue I worked on was implementing the endpoints in the frontend. [link] This was a last-minute scramble that started a day before review. Thankfully, the entire team came together, and we were able to get the reactive forms implemented and connect their data with the endpoint call before the review.

When this sprint was first being started, our team had a heavy workload if we were to finish everything we had planned. Considering this and the additional unplanned work, our team performed quite well. We communicated better and more often. Our individual work had started to heavily overlap each other’s. I believe this led to increased team cohesion. I, however, had a minor problem with our backend endpoints issue. Since our definition of done required testing, this issue required two other issues to be completed before or with it that had not been started. This only affected my estimation of work-to-time ratio, and I do not believe it added extra work. Overall, I am quite satisfied with my team’s accomplishments and all we were able to complete.

Concrete Skills

I have no professional developer experience yet, and that can make starting a career difficult. To make up for the lack of experience, I will need to procure and maintain some concrete skills. Concrete skills demonstrate the ability to utilize knowledge. The apprentice pattern “Concrete Skills” from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, by Dave Hoover and Adewale Oshineye, addresses the usefulness of concrete skills when seeking a career.

“If we hire you today, what can you do on Monday morning that will benefit us?”

This question from the pattern makes clear what a concrete skill is. Businesses are not looking for someone with just knowledge, they are looking for someone who can do the job. It is important to practice some concrete skills with current technologies and frameworks so I can hit the ground running when I start a job. The pattern lists several examples of skills to explore: basic web design, JavaScript, open source frameworks, build files, and a language’s standard libraries.

The pattern suggests collecting CVs, Curriculum Vitae, for respected developers to find out what kind of skills to practice. The CVs will contain the concrete skills of those developers. With this knowledge, I would only need to choose which skills that would be immediately useful for my desired career path. The pattern then suggests creating toy implementations of the chosen skills for practice, which then can be used as examples in interviews.

 “Concrete Skills” advises going through one’s own CV and find all the discrete skills. These skills are the only information many hiring managers will look at, according to “Concrete Skills.” This makes having demonstrable skills a necessity when looking for a job.

The pattern, “Concrete Skills,” seems like common sense, but I think it is an important point that needs to be stated. It is easy to lose yourself in the studying of development techniques and forget to polish the skills you already possess. The lesson this pattern is trying to teach is summed up nicely by a quote from Pete McBreen’s Software Craftmanship: The New Imperative:

“Having knowledge is not the same as having the skill and practical ability to apply that knowledge to create software applications. This is where craftsmanship comes in.”

Share What You Learn

My work over the semester has required me to explain what I have learned to my teammates. My explanatory skills are not great, but I have been able to make do with the help of live examples. Chances are likely that I will need to do this continuously throughout the future. Since this is an important skill, I will need to practice my instructive capabilities. Luckily, the pattern “Share What You Learn” from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, by Dave Hoover and Adewale Oshineye, addresses this problem.

“Up until now, you have focused exclusively on your own improvement as a craftsman. To become a journeyman you will need the ability to communicate effectively and bring other people up to speed quickly.”

“Share What You Learn” discusses the reasons for passing your knowledge to others. Ethically, it is wrong to only receive knowledge from the community and never give any in return. Being able to capably communicate your knowledge will make you a better developer. Teaching knowledge requires a deeper understanding of the knowledge than just using it. Also, other apprentices may appreciate an explanation from someone with the same level of abilities.

The pattern warns to be sure that the knowledge being shared, can be shared. It is common for companies to keep trade secrets, including software development information, so be careful.

There are a few ways listed for practicing “Share What You Learn.” One way is to write blogs about projects you are working on. The act of writing down your methods will make it easier to remember the details later. Another is to try writing a tutorial for a topic, presented in a way that you wished the topic had been presented to you. Lastly, imagine preparing for a workshop at a conference and how you would prepare for presenting your work.

I must agree with this pattern’s assertions, I believe being able to pass along knowledge quickly and clearly is an essential skill for software developers. As I have experienced this semester, I am not skilled with this pattern and I feel it has impacted our work to some degree. As such, I will need to practice “Share What You Learn” to be a better teammate and developer.

Dig Deeper

With the final sprint of the semester underway, I have had to learn several new technologies for our LFP microservice over the semester. This has led me to obtain only the necessary knowledge to move forward in the project. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman,by Dave Hoover and Adewale Oshineye, has a pattern that addresses this problem: “Dig Deeper.”

“When you read a tutorial, you should not be looking for code to copy but for a mental structure in which to place your new knowledge. Your goal should be to understand the historical context of the concept and whether it is a special instance of something else.”

The apprenticeship pattern, “Dig Deeper,” discusses the downfalls of having a shallow knowledge base and the need for obtaining a deep knowledge of how the tools and technologies work. There are several advantages to having this level of understanding, including: improving confidence, providing a starting point when joining a new team, and improving interview skills. The pattern refers to programmers with this knowledge as “cathedral builders.” These “cathedral builders” can debug, decompile, and reverse-engineer code. The best way to obtain this knowledge is to read specifications and familiarize yourself with debuggers.

The need for this pattern’s practice is like the need to learn history. Learning the history of a tool or technology will prevent repetition of previous mistakes and illuminate the reasons for the inner working’s current state. In addition to learning the history, it is important to dive into the different layers behind the tech and learning how the system works as a unit.

I realize my current understanding of the technologies I have been using for our LFP microservice is shallow and now, I have a direction I had not thought of looking into yet, debuggers.

A problem I have with this pattern is deciding where to start, as any time used to dig deeper is time that cannot be used for learning a new tech. This problem will likely resolve itself, though, once I decide upon a career path. For now, I can just dig deeper into our LFP microservice’s technologies: MongoDb, Node.js and its packages, angular, docker, and all the testing frameworks.

Sprint 2: Retrospective

It’s time for another sprint retrospective. Last sprint, our team focused on researching needed technologies and structure of our micro-service. This sprint, our team focused on implementation.

We started with deciding coding standards and preparing for the visit with pantry staff. We decided to follow the principles of the first five chapters of Clean Code: A Handbook of Agile Software Craftmanship by Robert C. Martin. Lucky for me, I was reading these chapters for my software process management class. We also decided our code formatting standards, so collaborative work does not get reformatted constantly. After these issues were completed, it was spring break and I started focusing on solo work.

Last sprint, I learned how to implement and test a Mongo database with a schema defined by the Node.js package called mongoose. With this knowledge, I started implementing our micro-service’s database requirements. I designed a guest schema with all the data fields from the register team. Due to the nature of our update service, our schema does not require any data field except for the guest id. I also added an additional date field for when the update was made that is automatically added. I then wrote tests for checking the schema and the interaction with the database using mocha. At this point I decided to wait for my work to be reviewed by my team and started work on implementing our endpoints.

Our service only needed a few endpoints, a POST for new updates, a GET for obtaining an array of updates from a range of dates, and possibly a DELETE. I managed to get a couple endpoints started before my previous work was reviewed. After the review I had to focus on the guest schema again. While I did not focus on the endpoints after this, I did manage to fix up the incomplete GET endpoint when I had the time.

My focus for the rest of the sprint was getting the schema work ready to be merged. The review process was much longer than I had anticipated. With my merge requested branch bringing a lot of changes, the issues I needed to fix were diverse and plentiful. The issues ranged from simple oversights, to writing documentation. At this point, the schema branch has been through many changes and is nearly completed.

The rest of the work I did was reviewing my team’s work and familiarizing myself with it. The rest of my team worked on the front-end, implementing our UI and how to test it. At this point, our team has the UI design completed or nearly so.

Overall, I feel good about the work that was completed even though it took longer than expected. I think we have improved our teamwork since last sprint. The main lesson to learn from this sprint for me was to expect a lot of editing and to assume issues will take longer than I initially guess. Something we could improve on is the scope of our issues. Many of our issues could have been broken down into smaller issues that would be quicker to complete. After last sprint, we gave a work-in-progress limit to our review column to try and force reviews, but it ended up getting clogged by wide scope issues with a lot of work to review. I believe our team will be able to continue work on our micro-service and hopefully be able to have some functional software after next sprint.

Kindred Spirits

The pattern “Kindred Spirits” in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, by Dave Hoover and Adewale Oshineye, addresses the need for social connections to other software developers. Fostering relationships with kindred spirits will create an environment that promotes curiosity and avoids stagnation. Groups share knowledge which allows members to learn from each other. The pattern warns of groups that will resist change and shun those who present change. Groupthink is also warned of in this pattern.  Conforming to some standards is necessary when participating in a group but that conformity should not discourage growth.

I have never been very good with making new connections. Most, if not all, of my computer science connections have been through school and, with graduation nearing, I will need to find new kindred spirits. “Kindred Spirits” suggests finding groups that meet in person, making this currently unadvisable (Social Distancing) but good to remember for down the road. While maybe not as effective as in person meetings, there are plenty of online groups to check out. The open-source communities seem like a good potential place to start. Also, many in person groups will have ways of communicating remotely so it still may be worth looking into.

“This pattern is simple in principle, and for some people (our extroverted cohorts) it is simple in practice. For others, however, it can be difficult.”

This line makes it clear that the difficulty I find with this pattern is common. My innate aversion to large groups and strangers has caused me to avoid attending events in the past, but it is becoming increasingly apparent that I will need to change that behavior.

While I find groups stressful, I agree with the pattern about the benefits of being part of one. Software development communities are great sources of knowledge and inspiration.

The pattern, “Kindred Spirits,” is one I will need to practice. Since I still have a great deal to learn, I think it will be imperative to find a group that will teach and inspire me. Other software developers will always have new things for me to learn if I seek them out.

“Use the Source”

“Use the Source” is a pattern from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern focuses on the need for reading code written by other developers. Some good sources of code to examine are open source projects. By examining source code, a programmer can see what their bad habits are and adopt new, better habits. Another benefit from code reading is learning new algorithms to solve different kinds of problems. Expanding one’s collection of code solutions allows a programmer to be flexible and able to solve more problems.

I found this pattern particularly interesting. Since programmers are constantly required to work with other’s code, it is imperative that they learn to read code efficiently with practice. I do not have much experience with this myself and this pattern has made clear how important reviewing other’s code is. Regardless of what career I pursue after graduation, it will be important to read code effectively. I will need to start looking into some open source projects so I can improve my skills. Now I just need to find some projects that I contribute to and am interested in.

“Use the Source” suggests contributing to open source projects for software you already use. This is very helpful advice to me; I use a lot open source software.

  • Atom: text editor
  • Eclipse: IDE
  • Insomnia: REST client
  • GIMP: image editor
  • Several different game system emulators

I briefly examined some of GIMP’s source code. GIMP has a label on issues for newcomers, allowing for quick access to simpler issues.  After reading through some of the code, I realized that it would take a great deal of time to get an idea of the project architecture.

I looked at this issue, (https://gitlab.gnome.org/GNOME/gimp/issues/4128), and thought it seemed simple enough problem to start with. While the problem seemed simple, I could not navigate the repository and locate where the problem may be. GIMP is significantly more complex than any project I have worked on before. Ultimately, I was not able to make any headway on the issue. I was, however, able to read through portions of the code and begin to see some of the structure behind the it. Though I did not find what I was looking for, I did get a basic feel of the code’s flow.

As stated in Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin, developers read far more code than they write. With that being the case, “Use the Source” is an excellent way to grow your code reading skills.

Sprint Retrospective 1

Completed tasks

I was worried about how well my team would work together at the start of the sprint. We are all rather quiet and I feared that would impact our project. Even Professor Wurst expressed some concern. While I feel our communication could use improvement, I think we did a fine job completing what we planned to do in this sprint.

We divided the sprint tasks amongst us and mostly worked on our tasks independently. All work that was completed was shared so that others could study and review the tasks they did not work on. While this worked for our first sprint, I am hesitant to repeat this method as I believe it can lead to confusion in the group. For our next sprint, I think we should try and assign tasks to multiple people so we can emphasize that the responsibility for the tasks fall on the entire group.

I feel we did a great job of sharing our work and resources. Most of our decisions are public on gitlab so that it is clear why we did what we did.

My primary focuses this sprint were learning how to set up a mongo database and how create a REST API for it. One thing I think I could improve on is the frequency of my updates. I generally completed a task before making my work public. It may be beneficial to update more often. Something I would like more from my team is feedback. While my work was reviewed, I have not felt like I have received any real criticism, constructive or otherwise.

By the end of this sprint, we had a good skeletal structure of the update module. We implemented test versions of the technologies we would use in our full stack application and completed a small MEAN stack, a full stack app using MongoDB, Express.js, Angular.js, Node.js. With what we completed in this sprint, I believe the coming sprint will be clearer in scope and better planned.

Create your website at WordPress.com
Get started