Code review and feedback in a pull request
The Github Pull Request Checks for the project
During the fourth course period I had an internship at Judilica, a start-up that develops digital tools for legal work (mainly). The internship was fully remote and lasted for six months, during which I and a fellow intern had the task of creating the company's landing page from design to deployment (CI/CD). The frontend technologies (stack) that I worked with with during the internship were Next.js, React, TypeScript and Sass.
K2
Knowledge and experience in various development methods and work processes, and above all agile system development methods.
Judilica as a company is one that aim to work in an agile fashion. I noticed this from the very start at our introduction meeting with the team. The meeting started off with a small team development session and even though it was held online, I felt as though I was able to get to know and connect with the entire team. In regards to the five stages of group development (posited by Bruce Tuckman), this session took the new team constellation from forming to norming. This was really good because even though I was mainly in contact with our mentor, I still felt comfortable reaching out the other members of the team when it was necessary throughout the internship.
The entire team collaborated in Notion (in regards to planning) and we were assigned our own workspace for the landing page, which we were responsible of populating and maintaining. Below is a picture from the kanban board that I and the fellow intern created and maintained throughout the internship. The purpose of the kanban board was to help visualize work and maximize efficiency (flow). During the design phase we created the different tasks for the board directly in Notion, during the implementation phase the tasks were generated from our Github Issues.
Kanban board
I also worked with Scrum throughout the project, working in iterations (1 - 4 weeks sprints). We started of each sprint by reviewing our backlog as well as discussing and deciding on the features that we were to implement for the sprint (sprint planning and creating a sprint backlog). Everyday we would have a daily stand-up where I shared briefly about my progress or struggles and what my aim was for the day. At the end of each sprint we would have an increment, during which we presented the work we had carried out to our mentor and receive feedback, which we would review at the start of the following sprint (sprint review and retrospective).
I also had the opportunity to learn more and work with test-driven development (TDD) during my internship. Throughout the project I continuously deployed (CI/CD) new branches using Github and Vercel to ensure that they worked properly before merging them with the main branch. Below is an image from our slack channel of automated messages from Vercel with two deployments that I made.
Slack board with automated CI/CD messages
396 + 71 (intro) = 467 words
K3
Methods of quality assurance.
Below is the process of quality assurance that I applied during my internship:
I began each new feature/fix by creating a new branch for the feature/fix that I was going to develop. This enabled for a more manage way to conduct unit testing during the implementation, before the integration (TDD). Once I was done developing the first iteration of the feature/fix, I would push it to our remote repository and create a pull request in Github. My mentor would then review the code (static testing) and then share feedback on what could be improved. The process would then repeat until the pull request was approved. Before merging the pull request with main, I had to make sure that it passed a few Github Pull Request Checks that had been configured by our mentor, the most important being a successful deployment of the branch via Vercel. Once all the Checks were passed and conflicts resolved with the main branch, I merged the branch with main.
I also learned, whilst working with CI/CD, that it is wise to run a build test locally to amend any build issues and errors before pushing the code. As well as configure automatic formatting to avoid running into unnecessary conflicts, in particularly when working a project with multiple developer.
A successful local build that I made at one occasion
Other methods of quality assurance that I worked with during CP4 were :
Accessibility Guidelines (WCAG), in particularly when designing the landing page. Things such as checking the color contrast of the buttons with a color checking tool and increasing the font weight on smaller text to increase the accessibility visually. When working with the different animations on the page, I also took in consideration not to go overboard with the different effects for the same purpose.
TypeScript (instead of JavaScript) which I consider to be a method of quality assurance when developing as it helps catch mistakes early through a type system and makes debugging easier.
TypeScript implementation
343 words
K5
Choose work and project methodology and make independent decisions about planning and work according to requirement specifications against set quality requirements in delivery.
One of the things that I found rewarding when it came to my internship was the opportunity to create the landing page from scratch and have responsibility for the entire development process. We were both assigned Co-Project Lead for the project. This meant that I had the chance to choose work and project methodology, as well as make independent decisions about planning and work according to requirement specifications set by our mentor (part of the stakeholders). Below are a few occasions reflecting my engagement with this course goal.
Starting off I collaborated with a fellow intern to create backlog activities for the design process. The main activities that we planned and carried out were wire-framing, loFi and hiFi prototyping. We collaborated on and created the wire-framing together as we needed to be on the same page when it came to which features were to be included on the landing page. The features that we decided on were based on the requirements in the project specification for the landing page, which we had received at the beginning of the project.
Wire-frame created in Figma
After receiving approval from our stakeholders that the wire-frame met set requirements (mainly that the required features and elements were included in the design), we decided to work individually on the loFi & hiFi prototypes. This in order to provide our stakeholders with different design options and for us to gain a better sense of what appealed to them visually. This approach helped me when it came to hiFi prototyping, as the loFi design that they had settled for gave me an idea of what design style appealed to the stakeholders. Below are two different iterations of the loFi designs.
loFi prototype
(I created the one to the left. The one to the right has elements from both our loFi design after receiving feedback from our stakeholders.)
Aside from the required features and elements in the project specification, the process requirements of the project was also specified in the project specification. Mainly "deciding and diving everyday operations/work methods with an agile approach", as well as utilize a kanban board (in Notion). When developing I utilized Github Issues to create requirement specifications for both new features that I implemented as well as bug fixes. The Issues were connected to our kanban board in Notion.
Below is a screenshot of an issue that I created for correcting the overall responsiveness on the desktop version. In the Issue I described the bug, how to reproduce it and then shared a photo of the expected behavior vs current behavior. I then solved the bug and created a pull request with the solutions that I used to solve it. Followed by merging the branch with the main branch, once the pull request had been approved by my mentor. For document purposes I linked the Issue to the pull request.
Github Issue #20
Pull request for issue #20
486 words
C2
Collaborate effectively as employees and leaders in the management and implementation of projects.
I was really fortunate to be assigned the internship with a fellow classmate, who I had collaborated with in the past. Our duo was already at norming when we kicked off the project as we had worked really well together prior to this experience. Working together from design to deployment (CI/CD) meant that we had to communicate a lot. This required me to really practice being both patient (whilst explaining and sharing knowledge) and humble (in order to learn new things).
Starting off we exchanged our expectations for the internship, which were aligned. Both of us wanted to learn as much as possible from the experience and utilize the mentorship to learn industry standards in regards to the different activities that we engaged with/in throughout the internship. Our mutual goal was to deliver a final product that our stakeholders could utilize or further develop for their needs. Aligning in this fashion early on enabled for us to encourage each other throughout the internship, and in moments where the motivation was low.
The internship was fully remote and we had to divide some of the tasks in able to work more effectively. We went with the agile approach of working on one task on the kanban board at a time. In able to maintain a good culture I practiced open and honest communication. Due to the freedom but also the responsibility that came with having such a flexible workspace, I made sure to communicate whenever I had hindrances (related to work as well as personal) that would affect my work. eg. sharing when I wasn't feeling well and needed to take the day off. By sharing during our daily stand-ups, we were able adjust our sprints accordingly and set more realistic time management plans. Sharing in this fashion also enabled the team to provide with some encouragement when I felt low (and vice versa), which improved the overall efficiency of our team.
Receiving some encouragement from the team
As we needed to work together throughout the project, we opted for tools that allow for multiple users to work in the same document/program. We mainly used Notion (planning), Figma (design), VSCode (implementation) and Github (version control). In the beginning of the implementation phase, I felt that it was important for us to work closely together to ensure that we both on the same page. We started off with header component and implemented it together before dividing and individually working the remaining features (components) of the page. It took us longer to get started however, I felt that we were synchronized from the start and could easily jump in and review each other's code, as a result of agreeing on the implementation structure together in the beginning.
Initially, I was a bit reluctant to pair-programming as I thought the practice to be time consuming and inefficient (two people working on one task). However I have come to learn that there are a lot of benefits to having two people working on the same problem. I was able to learn a lot from my fellow intern through our pair-programming sessions (and vice versa). One of the major benefits that I discovered was the opportunity to share knowledge in a more cohesive way (working with both verbal and visual feedback). This was particularly helpful when creating the wire-frame and when trying to align on the design language to for the landing page.
Discord conversation with a VSCode live share
577 words
C5
Independently treat relationships with and expectations of customers and stakeholders in such a way that it leads to further learning and completion of project.
Starting off the project, the stakeholders did not have any concrete ideas for how they wanted the landing page to appear. During the design phase, I and my the intern had to work in iterations and ask for feedback after each step (wire-framing, loFi & hiFi ). The feedback we received we then continued to build upon. This also meant that I had to communicate an empathetic manner and remind the stakeholder that our job was to support their vision (and that I would not take offense if they wanted to go in a different direction). As the stakeholders also had access to our Figma files, they were able to follow the work that we were doing in real-time and come with relevant feedback as we were working (did not have to wait until the next increment). I believed that practicing having transparency in this fashion helped the project move along more smoothly.
Providing different color theme options
As our mentor had other obligations, I felt that it was important to be mindful of our exchanges and how often they took place. I also saw this as an opportunity for me to work more independently. As demonstrated in how I worked with the "overall responsiveness" bug in K5, where I created an Issue (task) and implemented a solution before asking what solution our mentor preferred in, and when the pull request was ready for review. Him approving the of solution presented meant that I only needed to have one exchange with regarding this bug fix.
During the implementation phase I made sure to openly communicate with my mentor whenever I ran into issues that I felt like were taking too long to solve. I would first access and see if I needed to acquire some more knowledge on the topic (eg. taking an online course) or if it was an issue he could help solve directly. On a few occasions (and when he had the time to spare) I would him schedule a meeting with my for more in depth explanations. Below is an exchange between me and my mentor during which I received some advice on how to solve an task via messaging in Slack.
Slack conversation
An important aspect of the internship for me personally was learning how to work and communicate efficiently with my mentor. When we initialized the project I specifically asked him to openly and honestly share his feedback. This due to the fact that I genuinely wanted to both improve my coding (write cleaner code) as well meet the project specification requirements and complete the project in a way that was satisfying to the stakeholders. I felt like I was able to achieve both things by the end of the internship.
Advice on how to write better Sass
The landing page itself