Stay in The Trenches

This week I have decided to write about Stay in the trenches. This refers to deciding to program even when the craftsmen receives a an offer that would pull him away from programming. Dave mentions that the minute the craftsmen stops programming, his skills will fade.

This has certainly been the case for me. In school there were semesters that brought me away from coding. There are many classes that are non programming and when I take so many of those non coding types of courses plus working part time, it was at times hard to find the time to code. So I could only imagine what would happen if I had a job where I couldn’t code every day. Especially with family obligations. I know that my uncle and folks that I have talked to in interviews mention that they don’t code anymore and that they miss it. So I completely agree that skills atrophy when the craftsmen does not use them.

Dave recommends finding alternatives to the managerial promotion. The craftsmen needs to figure this alternative out on his own and write down these rewards. This is something that I will figure out on my own as I have more work experience. I know that these days there are lots of oppurtunities for senior software engineers so I think that if I want to stay in a coding role I am confident that I this type of oppurtunity will exist.

This specific decision is a ways a way for me. But there are similar cross roads in the earler stages of my career. There are positions for new grads that involve different levels of coding. There are Quality Assurance roles that are part of the Software Development Life Cycle but it is not a role that is strictly coding. So it just goes to show that the apprentice will need to choose programming again and again. There are many roles in software that do not involve coding, and it is important to choose programming again and again. This is an important lesson that I will take into my career as I graduate and move into my career in software development.

Sprint 3 Retrospective

During Sprint three we ran into issues that bottle necked our project. But in the end we were able to overcome these obstacles and make some good progress.

What did not go as well was the planning of our issues, and not knowing how long each issue would take. One of our issues was connecting our API to our backend, and building our server. This issue ended up taking three people from our group more than two weeks. And we were unable to meanigfully test any HTTP calls until our backend was running properly. Looking back, we should have starting working on this during sprint 2.

What did go really well this sprint was working together to get the app running. We spent one class, all working together. Working through docker errors and making progresss that way. Chirstian made progress on his own as well. He made a docker file and reused the shell scripts from last semester to get the server running. The issue we ran into was that even with the server running, we could not execute any http call, without getting a connection error. This was the status of the issue for about two weeks.

I tried to work through the connections errors using stack overflow and other online resources, but to no avail. I then asked Jared, and sent him a screen shot and he said they ran into a similar issue in his group. Then, Duwal, Jared, and I jumped on a discord call and together we got the server running, so that we could call our http methods wihout connection errors. This was a huge break through for the team.

Another issue we ran into as a team was meeting to make our video presentation. We had a hard time picking a time in which everyone was free. Because classes had ended, and group members had finals and other engagements. The solution we came to was that everyone filmed their part and sent the video to Christian, who is going to edit it together and submit.

One thing I can do to improve as an individual is learning to ask for help, outside of the normal avenues. Once I asked Jared for help, he knew where to get started on our problem. So I learned that sometimes I need to ask an outside opinion for help. There is a limit to how much I can figure out by debugging and googling on my own. And sometimes an outside perspective, or somebody that has encountered this problem before can make all of the difference.

Below are the issues I worked on this sprint:

I added access token capability to the API repo. I added a schema for a 403 response. And I added that response to every path in the API repo. Link: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeperapi/-/issues/12

I researched endpoint testing standards and created a template js file in the backend repo. Link: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/29

I debgugged tbe connection / server problems in the backend repo. Link: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/40

I helped Duwal with the test file for returning the API version. Link: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/25

Nurture Your Passion

This week I decided to right about Nurture your passion. As I finish my academic career and move into the professional world, nurturing my passion is something I will be conscious of.

The problem laid out in this pattern is that the craftsmen is working in a workplace where his passion is stiffled. I think that everyone will experience this. For my part, I have gone to long team meetings that felt like they could have been half the time. And that is one of the best problems to have. Work places can be toxic, or there could not be oppurtunities to learn and grow. With this problem explained, Dave sugguests that the craftsmen should look to nurture his passion outside of his job.

There are a few ways to do this. One is my making interesting side projects or Breakable Toys. I could see this being a nice change of pace, where I could focus more on learning instead of meeting the deadline. Another solution is to meet kindred spirits. Dave suggests meet up groups. One thought I have here is that if I am coding for six to eight hours, five days a week. I may not feel like building breakable toys, or going to meet ups. I like writing code, but not everyone has time to write open source in addition to working a full time developer job.

The action Dave recommends is to write three positive ideas down to bring up at work everyday. And bring one up if things turn negative. Finding happiness and positivity at work is important for anyone. So I think is is a very meaningful pattern.

I think the best advice here is that if the craftsman finds himself at a firm that stiffles his passion, it is time to move on. This piece of advice is very relevant now as we are in the midst of “The Great Resignation”. I think finding a job that a craftman can at least partially nurture his passion is very important. We spend so much of our lives at work. So it is very important to find happiness there, if possible.

The Long Road

This week I have decided to write about the long road. As we reach the end of the semester, it seems like a good time to acess the road ahead of me as a software craftsmen. Thus far, I have seen my road as just getting a software job. And everything else was secondary to that. That road included going to school, creating a resume, appying for jobs, studying for interviews, and interviewing. Many of these tasks included programming, but most of this time was not actually spent programming. Now I will be starting my first software job after graduation, and it is the perfect time to consider the road ahead.

Dave mentions that a craftsmen can achieve almost anything if he stays with his craft for 20 years. And that learning is a lifetime skill. He also mentions that the craftsmen should value long term growth over all else, including salary. I have seen online that senior engineers can make comparable salaries to technical managers. So I don’t think that craftsmen need to choose between salary and growing their craft. There seems to be plenty of roles that provide learning oppurtunities, and high salaries. But Dave argues that money should not be the main motivator of the craftsmen.

The action is to imagine my career 20, 30, and 40 years from now. It is difficult for me to say what my career will look like this far out. But I know that I want to work in tech for my entire career. I do know for the next five years I want to work as a Software Engineer. With the hopes of moving from Junior level, to a mid level engineer. From there, I may decide to take on a leadership role, while still focusing on the codebase most of the time. This could be a tech lead, or Senior Engineer role. Twenty years from now, I could either be in leadership, or a may be a very accomplished engineer. It would be very rewarding to be the guy that everyone goes to with questions, and I do like helping other people succeed. So this could be a good path. Thirty years from now I could see myself being a leader of a tech focused small business, or maybe freelancing. Going out on my own is something I have always been interested in. Forty years from now I will be sixty eight. So I will likely be getting ready to retire. But who knows, maybe I will still be coding at that time.

Draw Your Own Map

Draw your own map is a very interesting pattern. And a pattern that feels relevant to my journey. Draw your own map means that a software apprentice may need to leave his current job, if that employer is not providing the right path. What I like about this pattern is that it forces the apprentice to consider, and write down that path that is best for him. Instead of what his current employer wants.

This pattern feels relevant to me as I am graduating and starting my career in tech. I have worked at a company for a few years, in a mostly non programming role. But I have done some coding work part time. Upon my graduation in the spring, I was offered the oppurtunity to stay at my company, and join the automation department. Where I would be developing software. I was very happy to be offered the role, but I had to draw my own map. I knew that I would be able to grow as an apprentice more effectively at a bigger company, with more resources to train me. So I made the decision to move on.

There are many career paths in tech these days, as there are more oppurtunities that there has ever been. Some people stay in development for their entire career, and many switch to management roles. I don’t think that changing to technical management is a bad thing. But I do agree that each apprentice should draw his own path. Because it can be easy to just follow the road that your employer lays out. But it is much more rewarding and fufilling for an apprentice to draw his own path.

There will be more times in my career where I will change paths. I could change the industry I work in, or the tech stack I use. But the idea behind the pattern is that I should make these decisions for myself. As a developer, I am fortunate to have many possible paths, so it is very important that I consider which path will be the most rewarding to me.

Spring Two Retrospective

During spring two, we had more experience working as a team, and there were some big improvements and things that went well. There were also some areas in which we can improve, that we discussed in our Sprint Retrospective meeting. We started with what went well.

One thing that we improved with was using GitLab to better organize our collaboration. We used comments in the issues section of GitLab so that our development can be better documented. We were using discord and talking in person during the first sprint, when we should have been using GitLab comments. Another thing we did well was approving Merge Requests Asynchronously. During sprint one, we merged all of the requests as a group during class. This was tedious at best, and at worst led to merge conflicts, with branches being many commits behind. This time, we created a system in which any time a team member is the second to approve a Merge Request, he will merge the branch into Main. This streamlined the merging process.

Another area we continued to excel in is getting issues completed, and evenly dividing the work. With the exception of Issues that are not in our control, we completed all of our assigned issues. And we evenly divided the work. We faced some delays, as we had spring break, followed by a week of cancelled classes. But we still managed to get a lot done. We have a lot to celebrate as team, but there are some things that we can improve on.

We had a two week break from classes. And our productivity decreased during that time. We got better at using discord to collaborate remotely. And if issues like this arise again, we will be better equipped to handle them. Another thing we can improve on is naming issues more descriptively, and link issues to epics. We can also work on being more proactive with asking our instructor for help as needed. As a group those are the things we need to work on. And as a team member, I need to contribute to this.

I think I did a great job during this sprint, and I learned a lot. But there are some things I can work on. Going back to some of the group feedback, I need to be more specific in naming issues. This is extremely important, so that if another team member works on an issue I created, he is working on the correct piece of the project. Another thing I can work on is the way I help other team members as problems arise. A few team members needed help getting Chai to work. And were facing a “Chai is not defined error”. I thought this was due to Chai or node not being installed. As when I was in my branch it worked fine. When I moved to main and pulled all of the changes I found that I was getting the same error. It was due to a missing import statement in one of our testng files. I learned that I should take a closer look when trying to help another team member. Meaning that I should switch to their branch and pull all of the recent changes.

The issues I completed / worked on during Sprint two are as follows:

Test File for products: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/general/-/issues/3

Create Data file for Products: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/5

Test File for Returning API: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/13

Use the Source

The pattern I am writing about today is use the source. The problem is that an apprentice can be using bad habits, but he will not know if he is not reading someone else’s code. The author specifically mentions that the apprentice should look at the source code of the tools he is using. One reaction I had to this was an interview experience I had. I solved a coding problem, and my interviewer asked my what the time complexity was. I was using the Java library method Arrays.sort() but I did not look up what the time complexity of that library method. I eventually figured it out. But it made me realize that I should know more about the libraries that I am using in my code.

The author also mentions the importance of refactory code. When reading somebody elses codebase. The craftsmen should look for ways to improce the codebase, and understand why the project is built in the way that it was. This experience could also lead to apprentice refactoring his own code. The author also mentions code reviews. This is something I am really looking forward to as a professional Software Engineer. When we learn the fundamentals school, we are usually working alone, or in a small group. But in the professional world, we collaborate. This will give myself, as an apprentice an oppurtunity to learn from the source code of my coworkers. Open source is another great way for new craftsmen to gain this experience.

The author recommends that the apprentice contribute to open source, so he can read source code, and learn from it. He also mentions that if a programmer can understand a program from the source code, that means he is a good craftsmen. This makes a lot of sense to me, and understandy the code base is typically what a programmer does on their first day or days on the job. In order to contribute to a project of any size, the craftmen should know what the code currently does. So I agree that using the source is an incredibly important skill.

Sprint 1 Retrospective

As we just completed our first sprint, my overall thought is that we did very well, and we have learned from our mistakes. One of the things we did well was that we spit up the work evenly. Everybody had an issue they were working on at all times. And as a group, we agreed that we each did a fair amount of the workload. Another thing that went well is that we completed all of the issues we set out to, from the beginning. Another thing that went well was the merging workflow. With the exception of the first week of development, we were able to complete issues, and merge to main with minimal merge conflicts. How we were able to do this, was making sure we had the most current version of main, before commiting, and making sure to stay within the scope of the issue while coding. Overall I am pleased with our performace, but there are some things that did not go as well, and could be improved upon.

One thing that did not go as well was our communication in GitLab. We were mostly discussing our issue in person. So the discussion within the issue descriptions were not showing the entire story of an issue’s development. We were also relying too heavily on discord, instead of using GitLab comments. On a related note, many of our issues in GitLab were not named clearly. We also had issues that were created in the wrong project. Our naming conventions in general need to be standardized moving forward. We can also improve on only having one person working on an issue at a time. There are a few things we can improve on outside of GitLab communication.

One unrelated thing we can improve on is keeping our stand up meetings to the alloted 15 minutes. I know that this is very important in the real world. We can achieve this by staying on topic, and by not interrupting each other. As a group we have discussed how to improve moving forward. But in order to work effectively, I also need to consider how to improve as an individual.

One thing I can improve upon is staying on task when working on issues. In independent projects, or larger academic projects I did not use issue based Scrum development. So I could jump from one method, class, or subproject to the next, as I realized I would need them. This is not an effective strategy for large, group based development work. During our first week, I had to review a yaml schema, and I decided to validate the yaml, using node modules. I ended up spending an hour doing work that I was not assigned to, and made changes to the branch outside of the issue. This was an important lesson for me, and something I will avoid moving forward.

Issues completed:

Add Standard Files to API repository: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/3

Add Paths for CookingMethods and CookingTips: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/16

Test Class Template for Backend: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/19

The issue that stood out the most to me was creating the Test Class template for the Backend. It was really interesting to learn about Unit testing in node. We are using J Unit in CS443. So it helped me solidify that knowledge to see unit tests written in a different programming language.

Practice, Practice, Practice

This week I chose to write about Practice, from the Perpetual learning portion of the book. I think that this is an important topic because practicing is important in any skill or craft.

As a Software Apprentice, practicing is crucial. Practice will help me develop concrete skills in new areas. Concrete skills are necessary to land my first job. And the author poses the problem that my daily programming activities do not give me the oppurtunity to learn by making mistakes. This last part is not true for me. I do have the oppurtunity to make mistakes quite often.

One thing that Dave mentions is that practicing has to be done in a relaxed environment. So personal projects outside of work are an important part of the software craft. This makes sense to me. Because when programming for work. There are calls, meetings, and deadlines.Coding for school projects is similar. But if I am practicing for my own sake, I can relax and focus on learning. Dave also mentions to carve out some time everyday to practice. This makes a lot of sense to me. At the end of the pattern, Dave recommends that I complete the same excercise from scratch, once a week.

Over the winter break, I had some spare time one my hands, and I decided to take on a personal project. I wanted to learn about the React framework, so I decided to build a calculator with React. I made a calculator website one year before with vanilla JavaScript. It was nice to be able to learn at my own pace. And I had to remind myself that I was coding to learn, and it was okay that the project took me longer than expected. This was a good learning experience. I made an app that does works as expected, and I have something new on my GitHub. So practicing helps me to achieve the skills, and as long as I put the code in a public place, the projects become part of my resume. Creating personal projects will be part of my coding journey, and one of my favorite parts too.

Your First Language

This week I chose to write about “Your First Language”. The problem laid out in the beginning of the chapter is that the apprentice only knows basic knowledge of a few languages. This is a problem I have spent some time thinking about. But it is difficult for me to pick, which language I want to fully dive into. I have programmed in Java, JavaScript, C#, C++, and Python. I know the Java standard library better than any other language’s library. And I know the data types, and data structures better in Java as well. Java is what I learned in Intro to Programming, and Data structures. Java is also what I use for coding interview prep. Many of my peers are language Evangelicals, but I feel like a man without a country. I have never built anything in Java, that wasn’t an academic project, or a coding interview problem. I have used JavaScript and C# do build web apps. With all of this being said, I knew I needed guidance from this design pattern.

The author suggests that the apprentice choose one language to solve problems with. And stick with that language for years. And that his first language will be the basis on which he solves problems. For me, I think I am going to let fate decide. Whichever language I need for my first job, that language will be my first language. Many entry level software job postings just say ” “proficient in one modern language” and the assessment can be taking in any language. The author suggests that the apprentice seek out an expert in the language, so he learn from the expert. When I am on the job, I will have access to experts, and a lot of time to learn. For now, I will keep practicing LeetCode in Java, and build web apps in JavaScript for this course. I don’t have time for much else. But this design pattern has made me realize how important having a strong foundation in one language is, and I am eager to start working towards that goal.