Category Archives: CS448

Dig Deeper

“Dig Deeper” highlights the importance of acquiring in-depth knowledge of tools, technologies, and techniques in software development that help software developers to tackle complex problems effectively. Many software developers get trapped in a stagnant growth pattern and are content with a shallow understanding of their field.

The problem with this mindset is that a shallow understanding often results in challenges when faced with complex issues or unexpected bugs. This shallow understanding also often leads to frustration and hinders the ability of developers to provide meaningful contributions to their projects.

The solution then is to invest time and effort in acquiring a deeper understanding of the tools and technologies used in software development. Rather than merely skimming the surface, developers are encouraged to understand concepts such as concurrency models, type theory, and network protocols which equips individuals with the knowledge to tackle a wide range of challenges and contribute meaningfully to projects.

Moreover, deep knowledge of the field enables developers to explain complex systems, debug effectively, and make informed decisions about technology selection and implementation. This depth of knowledge enables developers to navigate complex problems with confidence and make informed decisions.

It is also important to research information from primary sources, such as specifications and original research papers, rather than relying on secondary or paraphrased sources. By learning more about the original context of ideas and understanding the problems they were designed to solve, developers gain a deeper understanding and can apply their knowledge more effectively.

In addition to looking at the source, software developers are encouraged to engage in activities that deepen their understanding of key concepts and technologies. This may involve implementing solutions from scratch, critically evaluating existing frameworks or libraries, or even keeping a record of their learning journey. By documenting their learning journey through blog posts or other means, developers can reflect on their progress and share insights with others.

As an undergraduate learning to become a software developer in school, I certainly sometimes a mindset more focused on “passing” rather than “succeeding”. I find myself often learning only just enough to earn that “A” instead of really diving deep into the material being taught. This mindset may get me past my academic career, but it will not get me far in my professional career. I will definitely need to devote more time studying about the deeper side of Computer Science, especially the subjects that I feel weaker in, such as Networking and Frontend work.

In summary, the pattern “Dig Deeper” motivates developers to have a deeper knowledge in software development. By investing time and effort in understanding the underlying principles and design considerations, developers can enhance their problem-solving abilities, contribute meaningfully to projects, and ultimately, lead them closer to perfection in their craft.

From Chapter Six, “Dig Deeper” in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Record What You Learn

The Apprenticeship Pattern “Record What You Learn” emphasizes the importance of documenting the journey and lessons that a software developer has learned to enhance personal and professional growth. This pattern addresses the common issue that many developers share of repeatedly encountering similar tasks or problems without retaining valuable insights. By maintaining a record of experiences in a journal, personal wiki, or blog, individuals can create a chronological account of the lessons they’ve learned, serving as both inspiration and a valuable resource.

Recording the solutions made to problems encountered along the software journey involves actively documenting experiences, insights, and solutions encountered. The primary problem of not documenting lessons learned is that it causes a lack of learning from past experiences, leading to repetition and inefficiency. Without a record of lessons learned, individuals may find themselves continuously getting slowed down by the same challenges without making much progress.

Maintaining a record of experiences offers several benefits. Firstly, it enables individuals to mentor others by making their journey explicit, sharing insights, and providing guidance based on past learnings. Additionally, it makes it easier to reflect, allowing individuals to identify patterns, make connections, and discover new insights.

To avoid falling into the trap of forgetting valuable lessons, individuals are encouraged to regularly revisit and review their records. By engaging in this process, they can prevent stagnation, identify areas for improvement, and continue evolving. Moreover, have access to and using both internal and external feedback allows the developer to receive more accurate self-assessment which motivates continuous learning and growth.

There are several examples in Apprenticeship Patterns that illustrate how individuals can implement this pattern in practice. For example, maintaining two instances of the same wiki — one for private thoughts and the other for shared lessons — allows for effective self-reflection. Similarly, transcribing ideas that shaped one’s learning into a text file allows it to be kept as a valuable resource for future reference and inspiration.

I believe that recording one’s learning progress it super important to any skill. So often I find myself making the same mistakes over and over again, but then I remember to look at my notes and the past resources I’ve logged for myself, and I find them super helpful in guiding my work to be more efficient and effective.

In conclusion, “Record What You Learn” encourages proactive documentation of experiences and insights to help developers apply what they’ve learned to everyday problems they may face. By methodically recording and reflecting on the lessons learned, programmers can discover valuable insights, avoid repeating past mistakes, and progress on their journey towards mastery.

From Chapter Five, “Record What You Learn” in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective Blog

With new experience gained from both Spring 1 and Sprint 2, Sprint 3 began without delay as I and my team worked to finish up all our loose ends before the coming end of the semester.

As a team, we all worked very well together in all stages of the final sprint. There was good communication through Discord and SMS to coordinate meeting times both in person and online, through which we collaborated to find solutions to the backlog issues. We were able to effectively work this way, evident through the team’s ability to complete eighteen out of the twenty-one weight we planned at the beginning of the Sprint. Some of the loose ends we needed to wrap were: 1) to get the frontend working, 2) to implement the buttons, 3) to update the Add Inventory Frontend documentation.

Because of the limited time we had, the team was not able to start implementing the new Add Inventory Frontend wireframe design which had been added in Sprint 2. However, we were able to get the frontend to run which we based off the code from Guest Info Frontend. This fix included adding a developer mode which allows for changes made in the code to be automatically updated to the frontend without needing to stop and restart. In addition, my team implemented the original button design and updated the documentation to reflect the new frontend features listed above.

My team and I decided that because there was not enough time to implement the Add Inventory Frontend wirefram design, it would be best to let the next Capstone class pick up where we left off. Firstly, the current layout is not the one represented by the wireframe. This would need to be updated. Secondly, the already created buttons would need to be linked to the backend using the appropriate endpoint call. Both of these are already issues in the backlog and can be used by the next team.

Seeing this sprint and the semester coming to an end, I feel accomplished with the work my team and I were able to get done. I personally learned a lot about the GitLab working environment, linters and how to use them through pipelines, designing frontend frameworks through Vue and HTML, and most importantly, meeting with a team to plan the backlog, collaborating to solve our issues, reviewing code solutions, and presenting our work to the professor at the end of each Sprint and to the entire class at the end of the semester.

Overall, this Capstone class was a growing experience through which I increased my ability to adapt to unfamiliar situations and became more comfortable with taking the initiative at certain times, especially when I was Scrum Master in the first Sprint. I am happy with the progress I and my team were able to make together this Sprint and throughout the entire semester.

Activity links:

Fix Frontend Build: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/49
Description: Redesigned how Add Inventory Frontend is build, implementing the developer build allowing for live change updates.

Update Frontend Wireframe: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/issues/12
Description: Updated the frontend wireframe in Add Inventory Frontend which had not been merged in Sprint 2.

Update Documentation: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/46
Description: Updated the Documentation in Add Inventory Frontend to reflect the new features added in all three Sprints.

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Practice, Practice, Practice

Mastery in any skill requires a love for practice and continuous improvement. Practice and improvement can be done through deliberate practice sessions which involves structured exercises tailored to hone specific skills.

One such form of exercise is code katas, inspired by martial arts but applied to software development, which emphasizes the importance of practice, fluidity, speed, and control. Coding katas are short programming exercises where developers solve specific problems or implement algorithms within a set time frame, typically ranging from a few minutes to an hour. Participants work individually or in small groups to write clean, efficient, and maintainable code. The goal is to encourage deliberate practice, enhance problem-solving skills, and promote continuous learning in software development.

Coder’s dojos, provide a supportive environment for practicing code katas in a group setting. These sessions, which are free from stress and interruptions, are crucial for skill development. Short feedback loops ensure that participants receive timely input to avoid developing bad habits.

Practicing different exercises helps discover nuances in skills and prevents stagnation. It’s essential to choose challenging exercises from fundamental computer science books to keep practice sessions interesting and educational. Some recommended books from Hoover and Oshineye, the author of Apprenticeship Patterns is “Programming Pearls” and “Etudes for Programmers.”

It’s often personally difficult to motivate myself to practice coding, though the idea itself is very logically sound. In my spare time, I like to learn new languages like Japanese or Chinese, and these languages, like any language, require lots of focus and practice. Programming is like a language applied to problem solving, so it too requires focus and practice. I should add coding katas to my routine to ensure that I don’t grow rusty on certain areas of my coding knowledge and instead, am constantly growing as a software developer.

In short, taking action is crucial. A software developer needs to find or devise challenging exercises, solve them weekly, observe their progress, and adapt accordingly. This iterative process helps identify strengths and weaknesses, enabling targeted improvement. By embracing practice and seeking constant growth, such as through coding katas, individuals can advance their skills and strive towards mastery in software craftsmanship.

From Chapter Five, “Practice, Practice, Practice” in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Find Mentors

Finding mentors is essential for aspiring software craftsmen, as they provide guidance and support in navigating the complexities of the field. Of course, software developers should strive to be hard-working and growing apprentices to eventually become masters at their craft. However, finding an ideal mentor is rare, especially in today’s world.

The process of finding mentors can be challenging, as mentors may not always be readily available or possess the desired expertise. For this reason, most real-world apprentices often seek guidance from multiple mentors with varying degrees of expertise.

Additionally, reaching out and asking for mentorship can be intimidating. However, the potential benefits far outweigh the risks, and even informal advice from experienced developers can be invaluable. Apprentices also have a role to play in mentorship by being willing to share knowledge and provide guidance to others. Passing on lessons learned from mentors contributes to personal growth and development as a craftsman.

Lastly, it is crucial that apprentices be active in approaching mentors, to learn more about them and gain their attention and help. For example, apprentices can sign up for active mailing lists related to software development, they can observe, and identify patient teachers within the community, and seek informal advice from potential mentors at conferences.

As an introvert, I often find myself struggling to take action in the networking aspect of my career, even though I realize how important it is for my success. There is a lot of fear and anxiety that comes with putting yourself out in the open and asking for help. However, if I learned one thing from my internship last summer, it is that I cannot afford to be afraid to ask questions! By asking questions and showing my weakness, yet still in a spirit of curiosity and willingness to learn, I found myself growing faster than I could have ever imagined under the mentorship of my advisor, who was patient and helped me to improve little by little.

In conclusion, mentors play a vital role in shaping the development of aspiring software craftsmen. Actively seeking mentorship and being open to providing mentorship to others are essential components of the journey toward mastery of one’s craft. By embracing mentorship, apprentices can gain valuable insights, overcome challenges, and ultimately achieve their goals in the field of software development.

From Chapter Four, “Find Mentors” in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Sustainable Motivations

Programming is automatically motivating for programmers when they have the freedom to work in their preferred manner. However, apprentices often face real-world challenges with projects that have changing demands. Such projects can be rigorous, chaotic, and frustrating, making it essential for programmers to have a constant motivation to adapt and remain resilient. While there are some days where everything flows smoothly, there are also more common days that are filled with complex and tedious tasks, particularly in money-driven programming jobs.

Motivations for programmers can vary, including financial goals, the sheer enjoyment of programming, or building a reputation through open source projects. However, relying solely on financial or reputational motivations can lead to what’s known as the “Golden Lock” phenomenon. This trap involves sticking with known skills because they’re lucrative, even if they no longer align with personal growth or interests. To combat this, an ambition for constant improvement towards mastery is vital, helping developers realize when they’re falling into these traps and guiding them to seek new challenges.

While passion for programming is valuable, it can also lead to overcommitment. For example, Marten Gustafson found himself overcommitting to projects due to his passion, resulting in project “death marches.” It’s essential to nurture this passion while maintaining a balance with other life aspects to avoid burnout.

David Wood offers a simple yet enlightening piece of advice: “Do what you love and the money will follow.” Following this advice helps developers discover that doing what they love fuels their creativity and energy, leading to greater financial rewards in the long run.

To better understand personal motivations, it is encouraged that programmers list at least fifteen motivations and then another five. This exercise helps identify motivations based on personal feelings versus external factors caused by other’s judgment and perception. By prioritizing the top five motivations and keeping them visible during challenging times, programmers can stay focused and resilient on their journey.

On a personal level, I find programming very entertaining and fascinating. But as a student, I often find that my motivation for programming can become fueled by academic reputation. One motivation could be, for example, a fear of getting a bad grade and not making the Dean’s list. While this is certainly a real feeling and truly motivates me to meet the expectations of my professors, it stops at that. Such a motivation is not to become a great programmer, but rather, to become successful in school and therefore in my career. While this way of thinking will probably get me through university, it does not guarantee me a successful career.

Programming offers intrinsic motivation, but navigating the challenges of real-world projects requires adaptive motivations. It’s crucial to balance financial goals with personal interests and ambitions for mastery. By avoiding the Golden Lock, embracing learning opportunities, and nurturing passion while maintaining balance, programmers can find long-term success and fulfillment in their careers.

From Chapter Three, “Walking the Long Road” in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective Blog

With new experience gained form Spring 1, I entered into Sprint 2 starting strong with more understanding of the basic workflow and how to navigate Thea’s Pantry on GitLab.

As a team, we all worked very well together in all stages of the sprint. There was good communication through Discord and SMS to coordinate meeting times both in person and online which shows by our ability to complete twenty-three out of the twenty-four weight we planned for the start of the semester. Because we were more used to the workflow process, we were able to spend more time together figuring out our more in-depth issues to implement button functionality to the AddInventoryFrontend project.

Some issues we ran into however, was not being able to build and run the Frontend to see how our vue file code ran. Instead, we had to rely on a vue playground which we found online to test and run our code. In addition, we were unable to access the wireframe to edit it, so the team resorted to detailing the revised wireframe through PowerPoint Presentation. These were simple issues that can be fixed in the next Sprint. As expected, we did not repeat any of the workflow mistake we had done last Sprint.

For the next sprint, we plan to have a “Workflow tips” shared document that includes all our mistakes from Sprint 1 and their solutions so that we do not make the same mistake again. For example, instead of waiting to review everything at the end, the team will review issues as they are completed. We also know to create merge requests directly from the issue, and to edit the merge request properly so that it meets all workflow requirements.

For the next sprint, we plan to continue working on the AddInventoryFrontend project. The first step before implementing the revised button wireframe would be to fix the frontend so that it can run on GitPod rather than having to rely on Docker. Then we will add code to allow the frontend to run on devmode, which makes it so that updates pass through as we work on the code rather than requiring the frontend to be rebuilt each time a change is made. After both of these are completed, then we plan to confirm that the current vue code works. Once that is confirmed and running, we will then update the frontend to reflect the revised wireframe.

This Sprint, I was not the SCRUM master, but I attended all our meetings and worked with my team to come up with solutions to our issues. I would say I am much more organized than last Sprint and am happy with the progress I and my team were able to make together.

Activity links:

GitPod Dev Environments: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/documentation/-/issues/9
Description: Verified that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages.

AddInventoryFrontend Redesign: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/39
Description: Created a revised wireframe for AddInventoryFrontend. The revised wireframe will be added to Thea’s Pantry GitLab in Sprint 3.

Implement Frontend Wireframe: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/45
Description: Developed the submit and cancel buttons following the basic wireframe before revision.

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Art over Craft

Richard Stallman calls programming a craft rather than a fine art, focused on building useful objects rather than purely aesthetic creations. While programming can be truly elegant and beautiful, its real purpose is to solve a customer’s problem. This is what makes it a craft.

The pattern “Craft over Art”, in this sense, is all about strong relationships and delivering value to customers. It is important to prioritize customers’ needs over personal artistic expression, because true craftsmanship involves building something that is both beautiful and useful. Software should never be simply beautiful but useless artifacts.

However, there are often many demands in software development, many of which are conflicting. It is important that a developer balance these conflicting demands, for example, delivering value to customers while adhering to professional standards. This is what it means to sacrifice the beauty of code for utility.

By focusing on the craft over the art, a developer gains many benefits. A developer is able to look past doing things solely for self-satisfaction, and instead, is able to aid customers and help solve real problems for real people while honing their craft.

To apply this pattern, software developers should find an opportunity to prioritize utility over beauty throughout the day, building a habit of being aware of the tradeoffs. A developer could also reflect on past choices where they prioritized artistry over utility and suggests afterwards think about alternative choices to understand the potential outcomes. “Craft over Art” advocates for a balanced and customer-focused approach to software craftsmanship.

I particularly found this pattern very helpful, because I find myself often working to make something perfect to the point where it hinders me from getting my work done. And often, because I have spent so much time making the code “perfect”, I grow so attached to how my it looks and is running, that I struggle with the idea of refactoring it to make it function better.

Understanding the difference between craft and art will make it easier for me to see my code as something that is always changing and improving rather than something that I try to write perfectly the first try. There is always room for change, to hone my craft.

From Chapter Three, “Walking the Long Road” from Apprenticeship Patterns by Dave Hoover and Adewale Oshineye

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective Blog

Being the first sprint of the Capstone class, there was a lot for me to learn working as a team and also as an individual.

As a team, we all worked very well together in all stages of the sprint. There was good communication which helped us coordinate meeting times both online and in-person. Evidence of our synergy would be through the fact that we were able to meet our estimated 20 weight completion by the end of the sprint. I would attribute the large success of our sprint to our commitment to meeting at least once in person every week throughout the duration of Sprint 1. This allowed us to really work together as team to figure out the issues and workflow, which was brand new to us all.

However, it was not all sunshine and daisies. The team made multiple mistake along the way which had slowed us down on occasion. Two big problems for all of us was navigating GitLab and getting used to the workflow. Aside from getting lost and figuring out the UI, we were unsure at first how to post our issues and how to create branches for our changes. It was also confusing how and when to approve merge requests. We had waited for all our issues to be completed before doing the review, which created merging conflicts and caused certain pipelines that were dependent on the other issues to fail.

For the next sprint, we plan to have a “Workflow tips” shared document that includes all our mistakes from Sprint 1 and their solutions so that we do not make the same mistake again. For example, instead of waiting to review everything at the end, the team will review issues as they are completed. We also know to create merge requests directly from the issue, and to edit the merge request properly so that it meets all workflow requirements.

As for me, an individual member of the team, I acted as SCRUM master and worked to communicate with the professor for the team during meetings, preparing notes and organizing the thoughts of the team. However, I had failed in some parts to organize tasks for myself, missing one stand-up post due to negligence. Now that I have a better understanding of how the workflow and meeting dates work, I will be more prepared in the next sprint.

Activity links:

GitPod Dev Environments: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfointegration/-/issues/23
Description: Moved Settings and Extensions from VSCode to GitPod Dev Environments.

Add AlexJS Linter: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/documentation/-/issues/6
Description: Added AlexJS Linter to pipeline check.

Move `commands` to `bin`: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/documentation/-/issues/5
Description: Changed command folders to bin to avoid naming convention conflicts.

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Expose Your Ignorance

One of the patterns addressed in Chapter 2 of Apprenticeship Patterns by Dave Hoover and Adewale Oshineye is titled “Expose your Ignorance”. It is a pattern that helps a programmer identify their weaknesses so that they can better know how to promote their personal growth.

When a company hires a software developer, they are trusting that the software developer is well suited for the job and knows what they need to know to do the job well. However, sometimes even the most experienced developer may come across an issue or technology with which they are unfamiliar.

To combat this, it is necessary to “expose your ignorance”. This does not necessarily mean to down-sell oneself by listing out all weaknesses and struggles, but rather, to be open with one’s learning progress and improvements. Being open is a road that leads to trust and reputation in any software developing team.

How does one healthily expose ignorance?

Ask questions! Learning from experienced software developers is the most direct way to becoming an experienced software developer oneself. Asking questions exposes ignorance, but it also exposes one’s ability and willingness to learn.

What happens if one does not expose ignorance?

The opposite to exposing ignorance is hiding it, and while it may save face in the short term, hiding ignorance will only stunt personal growth. This is bad for both the software developer and the team who depends on the software developer to be able to do their job well.

What are my personal experience with exposing ignorance?

When I was starting off with my research projects, I suffered from “imposter syndrome”. There was simply so much I didn’t know and had to learn to catch up and progress through my research. However, instead of hiding in my shell and trying to keep up a facade, I swallowed my pride and let my advisor know when I wasn’t understand something, or when I needed help. I had to remind myself that this fellowship is a chance for me to grow and gain experience! My advisor does not expect me to know anything and is there to help me learn.

Because I was willing to ask questions and exposed my ignorance, I was quickly able to learn and gain a deeper understand of my research project.

From this experience, I became to like being surrounded by people who know more than I do because it gives me the opportunity to learn so much. It exposes my ignorance not only to those around me, but arguably more importantly, to myself.

Seeing where I struggle pointed out clearly to me, it gives me the chance to address that weakness by doing the necessary research and practice to strengthen my understanding in an area that I would be otherwise unaware.

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.