The pattern I read for this week was “Draw Your Own Map”. It was about how to create your own career path and not worry about what others think of it. This was a great pattern to read because it is so true. Everyone is living their own life in their own situation, and no two people are exactly alike. It was interesting to look at the different ways I can create my own career map, and be prepared for the future. This pattern started making me think about my own map now that my college days are coming to an end.

This pattern taught me to not take my current map too seriously as it can always change, and the map I have right now might not necessarily be the same map I have next year, and I am free to change it however and whenever I see fit. I have always worried about the big goals, and this pattern has also taught me to focus on the little goals that will build up to create the big goals. This can even make the big goals seem simpler as the little goals will build into the big ones. 

I do not have anything that I disagree with in this pattern as it all seems to be given as options for you, and not anything said as a fact. Your map should be your own, and nobody can tell you if it is wrong or not as nobody is the same. I think this pattern did a great job at making sure that, in the end, this is only for yourself, and it will be different from everyone else. There might be times when your map intersects with others, but it will never be the exact same. This pattern is very important for anyone to read no matter what your career choice is. Everyone should draw their own career map with whatever goals they have to go through their path. In the end, your career map should be unique to you, it can change as many times as you need throughout your life, and it should include all your goals you wish to achieve.

From the blog CS@Worcester – Anesti Blog's by Anesti Lara and used with permission of the author. All other rights reserved by the author.

Ive grown to have struggled with my communication skills. I would propose that it comes from feelings of inadequacy. Growing up I spoke solely Khmer at home and going into school there was a short time of transition from one language to another. Fast-forward a decade or two the tides have turned, and I now struggle with Khmer.  What I recognize is the common factor within developing language and communication is one’s ability to write in each language. For one key factor as introduced in the Record What You Learn pattern, it says “You should not also underestimate the power of writing itself….You can lose your larger sense of purpose. But writing lets you step back and think through a problem. Even the angriest rant forces the writer to achieve a degree of thoughtfulness.” During my earlier stages of life, I don’t think I would ever have been able to understand this idea so much so that it would have led me to loathe writing in its entirety.

Though, as a graduating student, like many things, I have learned to love and develop a healthier relationship with things that may feel adverse. Like an opposing force school has been, I have learned to pull rather push against such a struggle. As I begin to make a shift, I wish to utilize writing more in any way that would serve me. As of now I see writing as a way to develop my language skills both natural language and coding/computer language, continue to use it as a way to develop ideas, and have it be part of my lifelong existence.

More specifically writing such as the writing in this blog has been an empowering way to process thinking and how to think. Of the many ideas that this blog has helped me develop, with the subject matter being the patterns in the reading, I’m learning to reflect on myself and record those reflections in way that crafts my “larger sense of purpose”. For example, recognizing that I like talking up all these ideas but never act on them, and starting to transition into learning how to take action and start making these ideas come true. The role in which writing has played has served as an oath to grow to my higher self, a mastered self. If I am true to myself these writings must be treated as a nursery to my ideas and the visions of the future that I have.

It is not only myself that I serve, but also for those that may have struggled as I did.

From the blog CS@Worcester – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.

Since beginning this undergrad program (really, the CS transfer program at my previous school) and starting my internship, I’ve found myself working in several different environments with several different tools. I’ve been able to scrape by in most of them, but haven’t stuck around with any one of them for long enough to become really familiar with it. I can specialize template classes and manage pointers in C++, but I don’t know how to use most of the standard library. I’ve grown from using a couple of Linux commands in a Manjaro VM to writing increasingly useful Bash scripts, but I’m not rapidly adding Linux commands to my toolbox. I’ve programmed in at least 10 different languages in the last year, but I’m not happy with my proficiency in a single one of them.

I think that this means that I need to start making use of the related Familiar Tools and Concrete Skills patterns, or at my own dot product reinterpretation of the two. The Familiar Tools pattern is all about developing consistency with a tool that you already trust yourself with, and Concrete Skills is about developing a proficiency foundation to build on. I have some foundation, but it’s split across a bunch of different technologies, and I need to rebuild it starting from a single tool that can become familiar to me.

The tool that I’d like to become familiar with is Rust. I share a lot of the general and technical priorities of that project. It’s great that it’s flexible and able to progress and fix mistakes without being paralyzed by a need to forever remain backwards-compatible. More importantly, I want to eventually work mostly with statically typed languages, and I love that it lets you opt into fewer levels of abstraction. For example, how cool is it that you can inline assembly in the same language that considers C-style undefined behavior to be a design failure?

Now that my formal education is ending, I’m going to use some of my spare time to develop my concrete skills in Rust by working on small projects. Hopefully, one of those will be working through Sedgewick & Wayne’s Algorithms again in Rust, some will be collaborative projects on fun things that I can’t yet get paid to do, and some will be projects where I figure out how to integrate a Rust backend with other tools that I need to learn more about anyway such as web APIs and AWS CloudFormation and Timestream.

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.

The pattern I read for this week was “A Different Road”. It was about how sometimes the career you think you will have now can change, and you want to take a different path in life. Even if the change occurs, you will still take what you have learned through this path and apply it to the rest of your life. I really enjoyed this pattern because it has always been a worry of mine to suddenly want to go down another career path.  This pattern did an amazing job on that topic. It was interesting to read the views given through the pattern that were very useful to settle my worries.

This pattern taught me that it is ok to go down a different path than the one envisioned in the beginning because we are constantly changing as people, and we are not the same people today as we were yesterday. As I mentioned before, it was always a worry of mine to suddenly want to go through another career path after all the hard work I went through to go through this one. This shows how big the lesson that this pattern taught me truly is as I now am looking forward to whatever life has to bring me, and just hope that in the end, I am doing what I love as that is all that matters.

I do not feel like there was anything I disagreed with in this pattern. It brought up something that everyone thinks about at least once, and did not try to make a controversial take, instead left it to the reader to make whatever decision they think is right. That is a great way to deal with it because it does not give them a specific side on if you should stay or go, but instead lets the reader know that the decision is only for them to make. Whatever decision they come up with is the right one for them in the end. I think everyone should read this no matter your career path as career changes are universal and not only for software development. It might even help someone contemplating this dilemma come up with their decision.

From the blog CS@Worcester – Anesti Blog's by Anesti Lara and used with permission of the author. All other rights reserved by the author.

In this penultimate blog post for school, I’d like to revisit the construct your curriculum chapter and talk more about a specific pattern in the chapter and further develop thoughts on it as I realize it was only briefly mentioned in said blog post. The specific pattern I would like to develop some of my thoughts on is the familiar tools pattern.

During this period of time, it seems to be quite advantageous to familiarize myself with the tools that I have been given, especially having a bit of an understanding of the job market, some foresight on my own abilities, and my general outlook on life and the world. Through a formal education I have been given more tools than I know what to do with; spending some time to clarify what those tools are, recognizing which tools may be most valuable to me, and gaining some practice with said tools, may support me in a way that is confidence inspiring and overall fulfilling.

When asked by those closest to me what was next for me after graduating college, despite some fears of rejection and judgement, I would respond with “I would like to spend some time getting my bearings”. Getting my bearings in a way that propels my career development and transitions me into a journeyman by utilizing my own reflections and acting upon them to eventually becoming masterful.

Setting Sights on Being a Journeyman

By no means do I see myself in the position to appoint myself to a journeyman, but I think it’s important to set a goal early on so that you have a clear vision of what you may be working towards. I wanted to revisit the intro as this is where journeyman is discussed.

Like my blog discussing the introduction I think that this is a fitting time to be considering such ideas. In the same way as the topics discussed in said blogpost, I believe that this not only applied to CS but can be applied broadly to life and career goals outside of CS. This idea is supported by the existence of apprenticeships in many other fields and careers.

There are two quotes from the journeyman paragraph in the intro in which I would like to explore more personally “This new focus is on the connections between practitioners, the communication channels within and outside the team.” And ends with a snippet on “Some of the patterns we will discuss are not appropriate for a journeyman, precisely because he has a greater responsibility to others who may see him as a mentor.” Seems crucial to keep this in mind and leads me into my next post.

From the blog CS@Worcester – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.

Craft over Art is a pattern I’d like to start keeping in mind as I program. Because every functional specification can be implemented in more ways than any of us can imagine, I tend to think up the one best way that I can imagine how to solve a problem, and then continue solving the problems that come up on the way to that result.

There are two problems with this approach, both of which can be addressed by following the Craft over Art pattern. The first issue is that often, when trying to do a new thing, what I learn along the way indicates that there is some easier or more useful solution. When I treat programming as an art, these concerns are secondary to finishing the beautiful thing that I first set my mind on. In many cases, though, these realizations are a sign that it’s time to change plans in order to achieve some other goal that will be more useful or achieved more quickly.

The second problem with my process is that the best way I choose to set out on is often one of the artistically best solutions I can think of, not the way that most quickly results in a product with acceptable quality. As the author says, the professional goal of software development is to make useful things, not to write beautiful code.

I do think that, to some extent, writing programs in the most perfect way that you can is good exercise for developing mastery in an area of programming, as is continuing to learn and implement new ways to do things. After all, some problems really are suited to specific solutions, especially when some form of performance is important. For example, determining a superior route between nodes is a problem that should often be solved after considering the methods of graph theory. Sometimes, though, the stakes are low, and there really are no other concerns besides a solution’s approximate correctness and the speed with which it is implemented.

One of the main reasons that I like programming is because there is so much opportunity to be paid to work in a way that’s artistically fulfilling to me. But as an apprentice who wants to improve, I think that limiting this impulse to appropriate times is one of the most valuable skills that I can learn over the next few years.

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to my blog.

After presenting what we did in this capstone class, the apprenticeship pattern “Expose Your Ignorance” was brought up and I wanted to check out what this pattern was. The pattern “Expose Your Ignorance” in “Apprenticeship Patterns” by Dave Hoover encourages apprentices to embrace their ignorance and actively seek opportunities for learning and growth. Rather than hiding gaps in knowledge or pretending to know everything, the apprenticeship pattern suggests acknowledging what you don’t know and being open about it. Embrace the lack of knowledge and use it as a stepping stone for learning. “Expose Your Ignorance” is about normalizing the learning process. It is about showing your willingness to learn, and acknowledging that the only way to fill gaps in your knowledge is to first admit that these gaps exist.

I can use this pattern in many scenarios, such as during team meetings. Instead of pretending to understand a concept, I should ask questions about it. This would help me learn more about that concept and might also help others too if they had the same questions. I have already done this in our standup meetings for the capstone class. Another example is when learning new tools. I’ve noticed other people in my group using this apprenticeship pattern when we wrote the chai tests. I wrote a chai test and when the other members in the group saw the test, they immediately asked me to explain it since they did not know how the test worked. The chai test scenario can also be applied when problem-solving. Instead of pretending that I know how chai worked, I told the group that I was not sure how to solve it and that I would research how to do it.

“Expose Your Ignorance” will definitely be one of my most used apprenticeship patterns since the world of computer science is very vast and it is hard to know everything from new technologies to every programming language. Embracing imperfection is a large part of the learning process. Using this pattern will speed up my learning process and promote collaboration with my peers and I.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Technical debt is a programming theory that refers to the necessary work that gets delayed during the development of a software project to meet a deadline or deliverable. It is an idea that shortcuts are taken to quickly deliver a product, but this decision incurs a “debt” that must be paid in the future when the work is eventually completed. Technical debt is often the result of a tradeoff between perfect products and the short timelines often required for product delivery. Developers may choose the easier route with messier code or design to deliver a product faster, but this can lead to technical debt that must be addressed later.

Technical debt can accumulate “interest” over time, increasing the difficulty of implementing changes and leading to software entropy. It is important to manage technical debt to avoid these negative consequences. This involves identifying technical debt, accounting for nonfunctional requirements, and implementing best practices and agile practices to minimize it. It is also important to be proactive in reducing technical debt in new initiatives by carefully planning and designing projects from the start.

I selected this post because I wanted to learn more about technical debt as I found the concept to be particularly interesting and relevant to my future projects. This topic also seemed important as I found it amazing that despite the large file structure for projects in this class, it was not too difficult to add and update code for the assignments. That showed me how a codebase can avoid technical debt to a degree, and how it simplifies for maintainers (or a group of students) the process of adding and updating code to the codebase. After reading through the blog, I gained a better understanding of what technical debt is and how it can accumulate over time. This really resonated with me as I can see how important it is to consider the long-term implications of the decisions, we make during the development process. One of the most valuable takeaways for me was learning about the various types of technical debt and how to identify them. This will be especially useful as I continue to learn and grow as a programmer. I also appreciated the discussion of best practices and agile practices for managing technical debt, as I can see how these approaches can help to minimize the amount of debt that is incurred. I expect to apply what I learned in my future practice by being more mindful of the potential impacts of my decisions and actively working to minimize technical debt whenever possible.

Source:

https://www.bmc.com/blogs/technical-debt-explained-the-complete-guide-to-understanding-and-dealing-with-technical-debt/#

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

KISS is an American rock band formed in New York City in 1973. The band is known for its elaborate stage shows, which often feature pyrotechnics, fire breathing, and other special effects, as well as the use of makeup and costumes by the band members. In all seriousness…

The KISS principle, or Keep It Simple, Stupid, emphasizes the importance of simplicity in design and systems. By keeping things simple, you can better understand and meet the needs of customers and create products that are more user-friendly and effective. In the world of software and technology, the KISS principle is especially important, as people often have many options to choose from and may not understand complex technology. By following KISS, you can build a minimal viable product (MVP) that allows you to confirm or disprove your hypothesis with minimal work and deliver your product in a straightforward way that is easier for users to understand. Amazon, for example, lists the KISS principle as a core leadership principle, stating that leaders should always find ways to simplify. When designing, it is important to wireframe religiously, use universally understood concepts, and avoid distractions. By following KISS, designers and developers can create products that are more efficient, effective, and user-friendly, and that are easier to maintain and update over time. The KISS principle is often applied to the design of systems and user interfaces, as well as to the development of code and algorithms, to create products that are intuitive and user-friendly.

I selected thispost because I have always been interested in the principles of good design and how they can be applied to create better code as a result. The KISS principle is a concept that I have heard of before in other classes and especially in the Robotics class last semester. I wanted to learn more about this principle and after reading this post was impressed by the emphasis on simplicity and how it can lead to better products and user experiences. The post also focused heavily on real world applications and its outcome which helped me visualize it better. I found this material to be very informative and made me think about how I can apply the principles of simplicity and user-friendliness in my own projects and for other CS classes in the future. I expect to use what I learned from this resource in my future practice by being mindful of the KISS principle and always striving to create products that are simple, efficient, and user-friendly.

Source:

https://www.freecodecamp.org/news/keep-it-simple-stupid-how-to-use-the-kiss-principle-in-design/

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

The Two of the fundamental aspects of coding, Abstraction and composition, are discussed thoroughly in this blog as well as the overall impact these processes can have on the code as a whole, we discussed these two towards the beginning of the classes and how they have there rolls in being able to not only code better but to understand and lay out the structure of the code.

At first I didn’t really understand how reducing a problem to its most basic form could help when I need to make code to very Specific actions and work a certain way, however after utilizing those processes in order to simplify the problem, then follow up by building up from those basic models allows me to utilize basic code to solve my more advanced problems. This opened up my thought Process when it came to Writing code as now I could think of all of the previous Projects I had where I had to create multiple objects and set Attributes for each specific one, and now I could seamlessly do it on a larger scale reusing other basic code.

For abstraction, it is the process of reducing all of the but the most important details in the code and leaving all of the extra out, it is important as it all owes for the most basic process to be worked on, and then subsequent work can be delegated to the more advanced versions of that the problem. an Example would be to rather than making multiple functions for different things, we could makes basic function that can be implemented repeatedly and reused. We can look at an example of the duck Project where we looked at different models of these classes and we noticed that certain ducks needed specific flying actions or squeaking actions, so rather than making multiple classes for multiple different types of ducks we made a basic duck class and created specializations for them In order to better the overall structure and reduce clutter. Then the using Composition you may make the connections to the different Objects in order to share information. Using the Duck Project Again, we made different types of ducks with Connections being made to the main Duck class with all of the Parameters, then we made connections for the squeak and Fly behaviors.

The Writer Focus on some key Traits for Good Abstractions, that being Simple, Concise, and Reusable. These are the things to look for when you want to simplify the work you do.

Elliott, Eric. “Abstraction & Composition.” Medium, JavaScript Scene, 28 May 2020, https://medium.com/javascript-scene/abstraction-composition-cb2849d5bdd6.

From the blog cs@worcester – Marels Blog by mbeqo and used with permission of the author. All other rights reserved by the author.