This sprint, I feel, was messier than the last two since our team was mainly trying to finish up what we had leftover form sprint two and do whatever we could before the end of the semester. It feels like that lack of direction was one of the factors that affected the rate at which I performed my tasks. I already mentioned what I did during the sprint which I think isn’t really nearly enough of what I wanted to do. I wanted to finish up what I had leftover from last sprint in a week or two and completely focus on the event system and maybe help out on the backend functions. What ate up most of my time was trying to test the API with docker which I wasn’t even able to do in the end. And I couldn’t even take advantage of the extended deadline since most of my finals were on the week following the new due date. I was only able to make the subdirectory and the basic send.js file during that time span. What I’d want to improve on as a team is to set a clear goal since I feel that was one of the factors on why I think I wasn’t able to do as much as I wanted to similar to what I said last retrospective. As an individual, I really need to brush up on docker since I couldn’t test the backend correctly even though I based it on the stoney-manage-items example on GitLab. I couldn’t even get the example itself to run on docker either, neither locally or with the docker-compose.yaml file.
The section “Be The Worst”, found in chapter four in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye focuses on situations where you aren’t able to learn much from your environment. Being on a strong team has its benefits, other members can cover areas where you are weak on and catch you before making mistakes among other things. Ideally, a team member should be able to take a step back from their team to accurately assess their skill and knowledge. In the case where the gap in skill or knowledge between yourself and other team members in vastly in your favor, then it’s likely that you won’t be able to grow much as a software developer. Because of this, it’s best to start out as the weakest member of a team, hence “Be The Worst”, in order to have room to learn and grow. Emphasis on “start out”; the weaker members of a team should work more to catch up to the rest of their teams. If they don’t bother, then the “Be The Worst” pattern kind of loses its whole point.
Fortunately, or unfortunately depending on how you look at it, I’ve never felt that I was the strongest in a team skill wise. Some of the people I’ve worked with on a team do things super quickly so I had to adapt by starting tasks early and refamiliarizing myself with certain concepts. I guess you could consider that a method of catching up with other team members. In a team setting, I don’t actively try to “Be The Worst” but I at the very least understand why it’s a pattern. If people aren’t challenged, then they’re tempted to stagnate and it becomes all too easy to end up as a big fish in a small pond. When someone better inevitably comes along, then those who’ve done nothing to improve are thrown for a loop and can’t easily adapt to that change. Though, people could also be motivated to do the opposite; work catch up or even surpass their peers in order to not be seen as the weak link.
The section “Rubbing Elbows”, found in chapter four in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye focuses on a learning technique similar to “Record What You Learn” pattern which I wrote about during week 12 of this semester. To “Rub Elbows” in this context means to sit next to a fellow software programmer and exchange ideas. This could range from simply talking to each other during a lunch break to peer programming which is when two or more developers physically sit side by side and collaborate while they develop software. In any such case as these, a software developer will likely pick up on the small micro-techniques that are too trivial to be covered during active teaching. However, these techniques can add up and significantly contribute to the development of a software programmer. And when even if one were to disagree with their peer’s methods, they at the very least have gained a new perspective to view from. The same can be said in the case where there’s a knowledge gap between peers, which forces both of them to take each other’s viewpoints into consideration.
Again, like the “Record What You Learn” pattern, I’ve experienced and used “Rubbing Elbows” to an extent. In recent memory, me and a peer have helped each other study and do the work in classes that we share. We weren’t able to physically meet up since the pandemic but we occasionally talk to each other online through discord. I remember one conversation where he mentioned Python and I didn’t really know much of the language so I asked him what separated that with programming languages like C and Java. That got me interested enough to the point where one of my final projects for this semester partly uses Python code. There’s also a pet project that I’m toying around with, something to do with chess; I’m kind of tempted to research more of Python so I can write the code entirely in that language. It’s not what I’d describe as a micro-technique, but it’s something that I picked up while “Rubbing Elbows” with a peer.
The section “Familiar Tools”, found in chapter six in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye focuses on the tools a craftsman uses. Focusing and familiarizing oneself with a particular set of tools will help increase productivity since there won’t be any need to go over the functions or specifics of said tools. This also allows one to more accurately know how long a task will take using these sets of tools. However, overreliance on one set is discouraged as there will likely be other tools that are either better suited to a particular task or are an outright upgrade. There are also situations where one will have to either choose your familiar tools and personal efficiency or less familiar tools and the overall team’s efficiency. Regardless, familiar toolsets will become obsolete and have to be replaced over the course of a software developer’s career.
The concept of having to swap familiar toolsets overtime is something I’m experiencing in real time despite my relatively small experience. For example, the first program that I used to develop and edit code in was BlueJ. It’s a fairly simple IDE that focuses entirely on the Java language and is mainly used for educational purposes. I got comfortable with it pretty quickly but then I had to learn C language which lead me to switch to Code::Blocks if I’m remembering correctly. The IDE I’ve been using for over a year now is IntelliJ which I mainly use to code in Java. I used all these different IDEs over the course of around three to four years and in the case where IntelliJ becomes obsolete or I need to code in a different language, like Python for example, I’d have to change IDEs again. This process is going to repeat again and again for as long as I use IDEs; though it doesn’t mean that I lose out sticking with one IDE for a period of time. Like the book states, I’ll be saving a significant amount of time coding in Java since I’m already familiar with IntelliJ and I’ll also have a frame of reference when estimating how long a task will take to get done.
The section “Concrete Skills”, found in chapter two in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye discusses the issue of needing some quality that will convince hiring managers to choose you over other candidates. In particular, this issue centers around the question “If we hire you today, what can you do on Monday morning that will benefit us?”. The solution the authors suggest is that one should develop concrete skills. What they mean by concrete skills is abilities that show that you don’t need to be babysat such as writing build files in popular languages or having knowledge of popular open-source frameworks. Skills like these show people like hiring managers that you have something of worth outside the basic skills expected of an entry level position. In the long term, the specific skill doesn’t matter too much as it’s just a stepping stone to the path to journeyman.
A concrete skill isn’t something that I’ve put too much thought into. I guess some could say that skills I’ve learned in class like knowing how to use docker or SQL would count as concrete skills, but that depends on the position I apply to. There’s also the projects and work connected to my GitLab account which I could show to a potential employer. Still, I have this feeling that it won’t be enough since most of my peers have a similar advantage if not more. That’s why I feel that I should do some independent study, not an internship mind you, something that I can do on my own time.
I feel like I could showcase a concrete skill by working on a personal project which I’ve been toying with but haven’t settled on a specific plan. I’d like to make a simple chess program, partly just as an excuse to learn the game but it would also be something to show to say “this is something I’m able to do and contribute”. I don’t know what exact skill this would convey; it could be that I’m proficient in so and so language or I can make a program by myself even if it’s on the simpler side. Despite my lack of direction right now, I feel it’s still worth a shot.
According to the article linked above, integration testing is a type of software testing that focuses on how well different components of a system interact with each other. For example, when assembling a pen, one would ideally test if all the parts for a pen fit together like the cap, ink cartridge, tail, among other parts. There are two main types of integration testing called unit integrated testing and system integrated testing respectively. Unit integrated testing focuses on testing the interactions and interfaces between integrated components. System integrated testing focuses on testing the interactions and interfaces between systems. There are also four ways to approach integration testing called Big Bang, Top Down, Bottom Up, and Sandwich or Hybrid. Big Bang is when most if not all components are tested at once such as all the functionalities in a system. Top Down is when top-level components are tested first followed by lower-level components. Bottom Up is the opposite where low-level components are tested first followed by higher-level ones. Sandwich, also called Hybrid, is combination of both Top Down and Bottom Up approaches.
For my software capstone, me and three other team members are working on an inventory system. Each of us are working on different components; for example, I am working on the backend API and a messaging system. Right now, I’m in the middle of testing the API by itself, but I’ll have to test it in conjunction with other components like the messaging system, the rest of the backend, the frontend, and also the other systems that are being developed simultaneously. One could call this a form of integration testing, focusing both on the unit and system levels. I feel I’ll take a Hybrid approach since what’ll be tested first is whatever I finish first and what my teammates finish first.
The section “Record What You Learn”, found in chapter five in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye, opens with the common saying “Those who do not learn from history are doomed to repeat it”. This section focuses on the practice of keeping some sort of diary to record what you learn throughout your career. Doing so has the benefit of creating a useful resource that can be referred back to at any time. It also has the added advantage of finding like minded individuals by finding common ground in what the both of you have learned. Both authors see these benefits since they also keep records of what they’ve learned. Oshineye uses two instances of the wiki, one public and one private, to share lessons he’s learned with others and give honest feedback to his own progress respectively. Meanwhile, Hoover kept a text file of references and quotes which eventually grew to such a size that he decided to publish it online for others to use. What separates this design pattern from another such as “Share What You Learn” is that “Record What You Learn” focuses on preserving the road you took to mastery so that you or others might learn something new from it.
While I haven’t reached mastery yet, I do generally try to write down what I learn. Admittedly, I partly do so I won’t fall asleep during lectures and I also often don’t go back to older notes. But I still notice some of the benefits like how generally more of the material sticks when I write down notes since I’m paying more attention to the material writing it down. And most of my older notes still exist, either digitally in my hard drive or physically in a stack of note books I keep inside box in the corner of my room. They’re still around and I can access them at any time which is one of the main benefits to “Record What You Learn”. So, when I’m talking to someone and they bring up a concept that I somewhat remember, I can open up my notes and refamiliarize myself.
For the second spring, our team focused on developing the frontends, backend, and keycloak of the inventory system. But a big problem the team encountered during the sprint is that to develop the inventory system, we had to learn all this new material such as Vue.js, Express, and API. Even though I was introduced to these concepts last semester, it’s still comparatively new next to all the time in college where I used Java and C++. And even though we had the entire first sprint to get familiar with the material, actually applying it to a project is a bit more difficult. It caused the progress on development to lag and a decent chunk of what was planned for the sprint didn’t get finished, like writing the API for example which was my responsibility and I’ll get to that later.
On what to improve as a team, I can’t really think of much outside of trying to keep up with the new material because I feel a good portion of the class is dealing with the same problem. I feel that the inventory team is doing decently all thing considering. As an individual I could improve on my knowledge of API and some other subjects by using the inventory system wiki more. I could also try and free up more time to work on the system since I planned to work on the API some more and I barely got anything done since I had a test last Friday and I have another test this coming Tuesday. I might have time on Tuesday afternoon or Wednesday but I also have other classes that I have to keep up with and I should also set a concrete goal or write a to do list to guide myself. I just came up with that and it sounds like a good idea so I’ll stick to that plan.
According to the article linked above, to code review is to consciously and systematically convene with one’s fellow programmers to check each other’s code for mistakes. There are many different ways to code review such as through an email thread, pair programming, over the shoulder, or tool assistance. Through email, a programmer can easily send their colleague a file with the un-reviewed code allowing both of them to exchange regardless of schedule or location. Pair programming is when two software developers work on the same code side by side, allowing both to more fluidly exchange ideas. Developing over the shoulder is similar to peer programming except only one developer actively works on the code while the other acts as support. Tool assistance allows for even more flexibility than email chains since it allows for code review through software-based code review tools.
Code review is a very simple concept as it is simply peer reviewing in the context of software development. The importance of peer review is that another person can examine and point out someone’s mistakes unlike automated processes. Developers are still human and make human errors which are less likely to be picked up through artificial means. And solely relying on tests written by the original developer runs the risk of overlooking errors not picked up by tests or in the worst case, following the assessments of a flawed test. That’s why peer review, and by extension code review, is so important to speeding up and streamlining software development.
This week I read the section “Learn How You Fail” in chapter five of Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. This section focuses on the concept of learning from your mistakes by understanding your shortcomings. An example the authors use to illustrate this is writing an implementation of binary search and its tests in one sitting without compiling the code or running tests once. Once finished, compile the code and run the tests in order to find any mistakes you’ve made. Repeat this process until the code compiles and passes all the tests while also writing down notes on each iteration. These notes will act as an identifier to your personal shortcomings which will certainly be useful into the self-assessment that allows one to set realistic expectations and a direction to aim towards in self-development.
The concept of “Learn How You Fail” has a lot in common with “Expose Your Ignorance” like how they both promote self-improvement and emphasize examining one’s shortcomings. But the most important similarities among these is that they’re both concepts that center around learning from your failures. However, the key difference is that EYI is opening up yourself to failure while LHYF is learning from that failure. It’s just that both concepts complement each other in that one naturally leads to the other. Take for example that exposing your ignorance could very easily act as the direction needed for self-development similar to the notes in the “Learn How You Fail” example.
The idea of “Learn How You Fail” is also one that applies to many different contexts outside of software development. For example, before someone learns how to ride a bicycle, they’re likely to fall dozens of times. A saying I’ve encountered in everyday life is that mindlessly failing again and again will only get you so far, improving muscle memory and the like. A key aspect in learning effectively and quickly is knowing exactly what to improve on. That’s why I personally believe that a direction or a goal is incredibly important not only to this concept, but to learning as a whole.