Today I’m taking a break from writing about software apprenticeship to post a quick overview of my progress in the first of three sprints I’m doing as part of a scrum team working on the Thea’s Pantry reporting system. This is my first time on a scrum team as well as my first time working with most of the tech stack involved here, so if it seems sort of unfocused, that’s why.
Here are the links to the commits I wrote during the last sprint:
Here I fixed a typo. I also made the repo and wrote a very bare bones readme file that this commit was addressing.
Here I copied some boilerplate from an example project.
Here I added scripts that make it easier to use docker-compose.
I copied some things from an example readme to the frontend readme.
I went back and changed the title of that readme to actually be relevant to the project.
I deleted a random file that I think someone was using for testing purposes.
This commit contains the bulk of the actual work I did. That being said, I didn’t really know what I was doing, and mostly just thoughtlessly copied stuff over for the sake of getting something out there. I noticed there were dependencies at the top of the file, and that they needed to be either removed from the file or added to the project in order for the code to actually work, although for the sake of time and for the sake of keeping the history clear I decided to just leave them in as they were. After the retrospective meeting, I think there’s really no good reason to keep the validator around when NPM serves the same purpose, although we might still put the logger to use.
So, the problem that has been burning in my mind the most was that I just kind of threw things together, being so unfamiliar with the system that I really didn’t even test to see whether my code worked. A big part of that is that we don’t really have anything functioning yet, but it’s also because in the specific area I was working on (the backend) I actually was a little rusty on how. I am from a background where I’m used to just having an executable file with a call stack that I can look at at any time, and the way this project is spread across multiple machines is something I find somewhat confusing.
We also didn’t take creating issues as seriously as we should have, in my opinion. We kind of threw it all on a few people. We should probably have discussed them for more than just the one class session, and the discussion should have been put in writing on GitLab so that there would be evidence of everyone having participated (a lesson I learned the hard way).
I think many issues were too granular. Many of the above commits were two-weight issues, which our department is using to mean that the task should take about one week. I did most of them back to back in one session, except for the last one, which took another session (in other words, it all added up to one single two-weight issue).
I feel like as a team we’re pretty good at putting the effort in, which is in my opinion the hardest part of anything. I think our biggest struggle is in communication, and I think that’s due in part to unfamiliarity with the project. Something we could try as a team is to pick five areas to research and assign one to each person. Something I could do personally is see if I can get the whole system running so that I can test it out and know what everything is for and what everything is supposed to do.
One final thing I’m going to do is proofread everything I write in this project, because a pretty significant number of commits up there are just fixing typos. I actually noticed another one as I was writing this post, which I’ll probably fix as soon as I post this. I don’t really understand why I made all these errors, since it’s not something I usually do. I suspect it may be because I was panicking when I did most of the work here. That’s definitely something to avoid in the future, since I feel it’s not conducive to programming.
From the blog CS@Worcester – Tom's Blog by Thomas Clifford and used with permission of the author. All other rights reserved by the author.