Author Archives: kmaiser

Sprint 3 Retrospective

To start with, our communication got a lot better about when we were done working on things, and about what needed to be done before the rest of us could work on new issues. Our prioritization also improved greatly, with us figuring out what was most vital in order to get our project as far along as we could in the last sprint. Our issues were also a lot clear in terms of what needed to be done, and we were relatively efficient in assigning and working on them as needed. I also felt that personally, I was extremely productive during this sprint, more so than I had been in the others, and this was the first sprint I felt that I had an extremely clear goal and something that was important and useful that I was working on.

That being said, I felt like other parts of team communication were lacking somewhat. We still struggled with knowing what everyone else was working on, and there were a lot of cases where it seemed like some people were finished and waiting on others, or were just unsure of what to do next. I felt like the backend not being fully functional still was a huge holdup to the rest of our work, but there were still some small things that could’ve been done without it. I think that having a clear end date on when we would be able to work on the project left us with less motivation to get some things done, as they would likely have to be redone by future teams, so I just think that our overall planning was a little bit lacking for the amount of work we had to do in some places, as evidenced by our remaining issues in the sprint backlog.

As a team, I think that we should have improved our communication a bit more, and more time spent looking at what actually needed to be done in the code could’ve helped us break up the work a little bit more. But I also think that this largely comes from our lack of clear direction and prioritization in the prior sprints. I think that greater clarity and communication about what we did, what we were working on, and what we needed done could’ve helped avoid a lot of the issues we ran into this sprint, and I think that overall having a clearer picture of the overarching architecture required for all of this could’ve helped us a lot. If we had spent more time getting to know exactly what we had done and what we needed to do could’ve helped us significantly improve our performance in this case.

As an individual, I think that I should’ve been more open about what I was doing with my team, and this sprint has given me an example of how I need to, in the future, pay more attention to the vital parts of the project, so we can get those working before we start working on the meat of it all. I should have been more meticulous previously, and less short-sighted when creating issues. Spending more time looking through the code and what we needed could’ve helped greatly here, I feel.

Issue #36: This started off as just adding bin files to start and build the backend server, but became reconfiguring and rewriting all the server files to get the backend server and API functioning.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Reflection on the Learn How to Fail Apprenticeship Pattern

The Learn How to Fail Apprenticeship Pattern is a relatively simple, and yet extremely important pattern to keep in mind at all stages of your professional journey. It states that we should learn what we are not good at, learn where it is that we fail, and learn what parts of that failure are worth learning how to fix and what failure we must just accept as something that we aren’t good at and move on to improve the things that are worth improving. It is about learning what behaviors, conditions, or habits lead us to failure, and learning how to get around them or just accept them for what they are.

I really liked the idea that they brought up about keeping a list of your skillset in your own personal wiki, that way you can always see what skills you have, and what skills you are losing over time. This way you can choose what is worth continuing to work on, and which skills are no longer useful to you. This is such a pivotal step to continuous self-improvement and learning that is a common thread throughout all the apprenticeship patterns. We need to be able to identify our weaknesses and learn why they happen so we can improve, and I think this is a really good way of going about it. I also really liked their action plan, writing code in a simple text editor, writing tests for it, and revising it without ever compiling or running it until it is perfect. I thought this was a really good way of testing yourself and finding the weak points that will follow you throughout every project you work on. I know that I have some weaknesses in my knowledge base, and some habits that will lead me to failure and moving forward I would like to take note of them and work on them as they come up in the future. I accept that failure is inevitable, but continually working on those failures and allowing myself to learn from my mistakes will make me a better developer.

If I disagree with anything in this pattern, it would be that you should drop things that would take a disproportionate investment of time and effort to accomplish. I think that sometimes, even for a little improvement, it is necessary to sink way too much time and effort into certain things that are fundamental or are extremely important to a project. Not all the time, but it is important to be able to make that distinction for yourself and figure out what is really needed to improve, regardless of the cost.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Reflection on the Sweep the Floor Apprenticeship Pattern

This apprenticeship pattern urges apprentices who are going to be entering the workforce to take on the tasks that nobody else wants to do. The tasks on the edges of the project, like documentation or code refactoring. It explains that this is a good way to help out the team without much experience, to ingratiate yourself with your teammates, and show everyone that you are capable and a useful member of the team. It will also help you gain some humility, by doing the tasks nobody else wants to do and learning the importance of these tasks.

I think that the real strength of this pattern is in laying down expectations for apprentices about to start, or just starting their time on a real team in the real world. We have to humble ourselves and realize that when we first start at a project, we are new and we haven’t earned our chops, or shown anyone what we can really do. By choosing to take on the menial tasks that everyone else has pushed aside, we are choosing to show everyone that we are willing to get our hands dirty, dive into a new project, and prove that we can be valuable besides just as a workhorse on these tasks. Showing the team that you are ready and willing to contribute to the project in whatever way you can shows that you aren’t someone to shy away from a challenge. The pattern also warns about the pitfalls of this though, and they are good things to keep in mind so you don’t get stuck doing menial work forever. I had kind of planned on this since the beginning, I think it is vitally important to show people that you are willing to do what needs to be done, and this pattern has reinforced the need to be ready for that and reminded me that while I am willing to do it, I also need to advocate for myself and make sure that I am getting what I want as an apprentice: the opportunity to learn, and to work on something bigger.

I don’t really disagree with anything from this pattern. I honestly think that it is all just good advice, it is important to be able to earn your place as a valuable team member, and it is equally important to remember that you are valuable, and to use it as a learning experience, and as a way to show your skill. It is a valuable part of being new to a project and is a great way that we can gain experience outside the classroom, and apply what we have learned to something real and tangible.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

I think that in this sprint we greatly improved our workflow as a team, we knew what we were doing and were a lot more efficient about knowing what we were doing and completing it. We were also a lot better at communicating with each other this sprint than in the previous one, keeping each other updated on what we were doing and what we had to wait on in order to complete our section of the work. We just overall worked a lot better together and were able to complete things as a team as needed in order to get the job done.

Despite the fact that I think we did work a lot better as a team and we did communicate better, I think that it could still certainly use improvement. While we are better about it I still feel like there is some difficulty in communication about what each of us is working on at any given time, and we tend to just wait until class to talk to each other, other than the occasional discord message. We also still have trouble working on the technical side with git, making sure we are merging when we should and focusing on the epics, most of the time, at least for me, we just focus on the individual issues on the issue board and completely ignore the epics aspect of the project organization. Similarly, I think we are still having issues actually running the code with the backend in order to actually test things, but I think that is something we can definitely iron out in the last sprint.

To improve as a team, on the issues listed above, I think that we need to focus a little more again on communicating, especially when things are done and need to be reviewed, and then when they need to be merged. I don’t think we have huge issues in these areas, we just need to make sure we are letting everyone else know when we are done with things. We should also make more explicit what we are working on at any given time, only pulling things to in-process when we are actively working on them would fix this issue I think. Possibly we should focus more on completing epics than the individual issues, just to keep a little more structure to our workflow, but I don’t think it’s been a huge problem thus far, just something to think about. And lastly, I think a big focus of sprint 3 would be making sure we can actually run the code for testing and have the docker images work properly and everything. I think we have talked about it briefly, but getting that fixed I think should be a priority.

As an individual, I think I still need to be a bit more productive and involved in the actual coding process, a lot of what I have done this sprint was just refactoring the file structure and getting some documentation issues worked out (which come to think of it could probably use a little more work). Other than that I feel like I have done very little actual programming work in the past 2 sprints. I just feel like when it comes to doing things other than coding I have a little bit less interest and it is harder to motivate myself. This is a personal issue and I want to finish out the last sprint being as productive as I can be. I am definitely also a culprit of not communicating enough, so I want to make sure for our last sprint that I am keeping everyone updated on what I’m doing and when I’m planning on doing it.

Issue #18 Removed an old file that was a placeholder from a previous group called endpoints.js.

Issue #21 Merged the endpoints folder and the subProcesses folder to remove complexity within the system, keeping the endpoints folder as the main folder for the endpoints.

Issue #2 We discussed naming conventions as a group and I added a markdown file in the Documentation repository to keep track of any style conventions we want to keep a record of.

Issue #24 Created the endpoint for getInventory, using the endpoints from the API and the methods written in the Inventory.js file for functionality.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Reflection on the Unleash Your Enthusiasm Apprenticeship Pattern

This apprenticeship pattern really tries to tell apprentices, relatively new software craftsmen, to allow their enthusiasm and new set of eyes to help guide older, more experienced members of a group. It encourages us to speak our minds about issues, and offer new solutions that may be looked over by the more experienced members of a development team, but that we can see with fresh eyes. It’s mostly about the value that new developers can bring to a project, and how at this point in our career we can gain a lot from suggesting things, whether they’re accepted or shot down, we will still learn something from the experience, and really there’s nothing to lose.

The thing that I found most surprising about this pattern was that new members of the team are actually pretty important, they cited a study about aircraft carrier teams being more effective with new members, and stated that it is similar in the software field. The new members bring in new ideas and a freshness that the more experienced group members have lost, and that it all creates an important balance between experience and freshness. It is important in the early part of our careers that we harness the new, fresh, outlook on the field in order to bring more creativity to our projects, find new ways of doing things, and are given the opportunity to advance and learn from people that have been around for a long time. And then we will eventually get to be the ones to temper the new apprentices’ expectations, and teach them, but also learn from their ideas. It is just fascinating to think that we are part of this ecosystem that has lasted for generations of developers and that despite our relative inexperience we are still invaluable assets.

I know that after reading this, I am feeling a lot less nervous about graduating in the next few months and that my contributions to my future development team will be necessary for their survival, and I’m excited to learn what I can from them. However, I’m not sure how the “Solution” part of this pattern really addresses the core tenant of the pattern. Yes, it is a good idea to make sure that your voice is heard and have a more experienced person tell you if there are flaws in your idea and where to improve. However, for many of us, we’ve never really been in a professional environment so it is kind of hard to achieve their solution. However, I don’t think there is a real issue or something I disagree with, but it just seems like it isn’t fully attainable for everyone.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Reflection on The Deep End Apprenticeship Pattern

The Deep End is an Apprenticeship Pattern that encourages software apprentices to take risks, to challenge themselves, and to take opportunities they may not normally take. It makes sure to warn readers that this does not mean that they should jump into things that they are completely unqualified for, or do things with no thought or preparation. However, it is saying that we should be willing to take risks in order to further our learning, and should be willing to try things, even when there is a chance of failure.

I think that this pattern offers a very good way to ensure that we continue our learning, as stagnating at one job, on one project, is no way to continue our lifelong learning, tying into the Long Road apprenticeship pattern that I have discussed previously. We have to be willing to take risks and risk failure if we want to move forward (the same principle used in the Breakable Toys apprenticeship pattern). I also really liked the idea of keeping some sort of record of your own accomplishments, some archive of code we’ve written previously, how long it was, how many group members you worked with, and how large the codebase was. With this sort of history, not only can you track your progression and always look for bigger things and more learning opportunities, but you can also have a record of what you have done that you can go back to in the future, which also follows principles laid out in the Record What You Learn pattern. Being able to go back and see how you’ve changed can be an invaluable tool, and if you don’t risk failure, you will never be able to progress past a certain point.

This pattern has presented a great strategy as to how to keep track of my accomplishments and is great motivation to actually take risks in my professional career. I want to continue to grow my skills and grow, and unless I am willing to fail, I will never get anywhere. As for something I disagree with from the pattern, I guess the only thing I really disagree with is the idea that line numbers and team sizes are the metrics that your career should be based on. I think they can be useful to keep track of and consider, but in the pattern, it is kind of implied that these are the main metrics to measure your performance, and I’m just not sure they are the best ones. Regardless, I don’t think that invalidates the value of the point of this pattern.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Reflection on the Record What You Learn Apprenticeship Pattern

This apprenticeship pattern encourages apprentices to record what they are learning, in either a public or private place (or both). Either in a blog or wiki or even just a personal journal. Each has its pros and cons, but in each instance, they allow you to look back and reflect on what you have learned, what you were having trouble with and can give you a map of where you have come from.

While I was reading this pattern, I couldn’t help but think of this blog itself. While at the beginning I thought of this as something I would only ever use for class, I can see myself updating it in the future to be a far more professional blog space where I can record my experiences in my professional career. Even in the past year, I have found myself checking old blog posts about other patterns I read about to form connections between them. Like the Breakable Toy pattern, where I talked about starting a wiki being a good idea. That feeds right back into this pattern, already showing its effectiveness as a tool.

I never really thought about writing being a part of this field, but as someone with an innate interest in writing, and who has gone so far as to minor in it, I am really excited to see that this is a larger part of the lifestyle of other software developers. I hope to be able to continue writing, either professionally or as just a part of my own journey to mastery of the craft. It is something that has always been a big part of my life and being able to do it in conjunction with software development is really important to me. I think that this is as good an outlet as any for that seemingly unrelated skillset.

I don’t think I disagree with any part of this pattern really. I guess if I had to pick something it would be uploading it for everyone, but even then I think that way of doing it has some value, I just think you should have something private as well. Overall, it’s a fairly straightforward pattern and aligns with what I enjoy doing anyway. I’ve been looking into using Obsidion as a wiki-creation software, and I think that it has potential for this sort of activity. Clearly, this is a fairly common practice within the industry and I hope I will be able to find the motivation to keep up with it as my career goes on.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Reflection on the Craft over Art Apprenticeship Pattern

The Craft over Art Apprenticeship Pattern describes how despite us as software developers wanting to make artistic code, we must always prioritize utility over artistry. It is important to make code that serves its purpose over code that is technically challenging or code that has extra features. If we aren’t meeting what our customers want then we are no longer craftsmen.

I think that this pattern is pretty important to keep in mind. I often find myself trying to make code that is interesting or that I think will do a better job than what I am being asked to do, but this sort of over-engineering is not what isn’t what I am being asked to do. Despite wanting to do what I find more fun, the needs of the assignment or customer come first. Function over form. Most of my friends are artists, and my dad is an artisan over being a craftsman, so to me, this isn’t something that comes naturally. Moving forward, I need to make sure to keep in mind that what the customer is asking for is what they want, not what I think would be better. I really liked the emphasis that they put on utility as being paramount. Something that is technologically brilliant but has no utility is ultimately not the job of a craftsman, and not really what we should be looking for as software apprentices. They aren’t saying that we shouldn’t still strive for beauty though, which I am sure I will never quite be able to shake, but just that we need to prioritize the function. I think that this mindset will serve anyone well, especially in this profession. People that can’t listen to what the customer wants won’t last long in any professional field.

I do disagree with the idea that all software must be crafted for utility though. Technologically brilliant software, beautiful software, has a place and is ultimately important to the future of this profession. If developers never thought out of the box to create something truly amazing, we’d still be living in the dark ages. But I do agree with the overall point of function over form. Even in that mindset, however, I think that we should take creative liberties when it is appropriate, and allow ourselves to be shown in our work. Much like the world without art, code without beauty is miserable.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

Overall, with my work on the issues listed below, I think that the methodology of using the GitLab boards worked really well for us as a team, allowing us to pick which issues we personally wanted to tackle and notify everyone of what was currently being worked on. I also think that the methodology that we figured out as a group of requesting someone to check over our commits before we merged the branches worked really well.

Overall, I just don’t think we had a handle on the project when we made the first set of issues, so a lot of them were undefined and others really had no purpose. Our first sprint had no real direction and was just a bunch of random issues that we thought we had based on random comments in the code and what we thought should be done. This lack of direction, I feel, really hurt our productivity as we were focusing on things that had very little to do with each other and were just in there as things that could be done to grab some extra time units that it seemed like we needed. I also don’t think we communicated enough over the course of the sprint as to what everyone had done, which caused a bit of confusion. I also felt like I personally didn’t do as much as I would’ve liked, as some of my issues fell flat and left me feeling like I hadn’t contributed as much as I would’ve liked. The biggest issue we ran into on the technical end was the fact that our backend had almost no functionality at all, and needing a backend in order to properly try out and work on frontend behavior really put a damper on the amount of progress that was possible for us.

To improve our team issues I think we just need to flesh out what we need to do as a group, in order to fully grasp the scope of our sprint and what functionality the project needs as a whole. We also need to flesh out how we want to handle organization in terms of the file hierarchy and structure within the repos, as well as a proper naming system. These issues would be easily possible with a refactor I think. This first sprint was really a trial run, in my opinion. We are slowly figuring out and narrowing in on what needs to be done to get this thing working and finding examples to go off of to start to create some real functionality.

As an individual, I think I need to communicate more with the group and see if anyone else needs help, I guess so far I haven’t felt like as much of an active member as I would have liked. I also need to be less rigid about issues and not feel like I can add them as they come up because sometimes I feel like I shouldn’t add things to a sprint that is underway because of the seeming rigidity of SCRUM. There are things that can be done and issues that can be added or modified over the course of the sprint, at least I think there should be. I just need to let go of my personal hangups with SCRUM in order to work more effectively with the team. That and manage my time better, as this sprint, I kind of dropped the ball.

Issue #17 This issue represents work done by Sebastian and I trying to figure out how the backend worked, and our conclusion that it needed to be completely rewritten

Issue #62 I added dev containers to each of the repos of the project, however they may need to be updated as we go.

Issue #16 This was abandoned after figuring out that the file the comment was part of was just copy-pasted as a placeholder.

Issue #15 This was also based on a comment about a file being used as a test, I moved it to its own folder but have determined it has no functionality, but we will keep it around just in case we need some of the code.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Reflection on the Long Road Apprenticeship Pattern

The Long Road is meant to temper expectations. It lays out the path to mastery of software development as one of lifelong learning, and not one of chasing wealth or position. It is about taking jobs and opportunities that will help you continue your journey to gain more experience and knowledge and to prioritize this over promotions and salary raises. It is about finding the knowledge at the heart of software development.

I think that not only is this pattern good advice to software developers but offers good life advice as well. I personally believe that life is about the journey and that new experiences and gaining more knowledge is far more important than gaining more monetary wealth. I don’t care too much about money in general and I think that having this mentality about moving forward in my career lays out a life that will leave me a lot happier and more content when it comes time for me to leave it all behind. I didn’t get into computers to take a middle management job, I came here so I could enjoy what I do and get really bloody good at it. I just found the part about growth over wealth to be such a good way of looking at software development, and I think is kind of the opposite of why a lot of people get into it. I feel like a lot of people get CS degrees because they want to make money, and not so much for the love of the craft, and I think that’s just a path to disaster. I hope I’m wrong, but if you can learn to love the journey I think you’ll have a lot more fun along the way.

However, I do disagree with the notion that this pattern (and this book, as they say) is not However, I do disagree with the notion that this pattern (and this book, as they say) is not for people that want to take different paths. I think it is entirely reasonable to believe that even those who don’t want to continue a software development career for their entire lives still want to master the craft and continue their development journey even if they choose not to continue down a career in it. There are many people who don’t pursue full-on careers in software development, but still love coding and want to continue to grow their skills. Hobbyist game designers or developers are out there, and I think that that choice is completely valid and that this pattern still applies to those that choose something else. I just don’t like the gatekeeping nature of that comment in this pattern. Mastery does not necessitate a career in development. Do what you want, and enjoy the journey.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.