Category Archives: Week-15

Improving Code Reviews

In this blog post, I will be talking about the various ways one can make their code reviews better. The blog that I am referencing is titled “How to Make Good Code Reviews Better” and is published on the Stack Overflow blog. The blog post outlines multiple strategies for people to improve their code reviews. These strategies include maintaining a respectful tone, offering specific and constructive feedback, and trying to focus specifically on high-impact areas. Furthermore, the importance of maintaining a balance between efficiency and thoroughness is highlighted in the blog, as balancing those two is very important if you want to ensure that reviews don’t become a barrier for your team during the development process.

I chose this blog because I thought that it would be a resourceful blog to read through, as these strategies can definitely help in the future for my professional career. This also relates to what we learned in class, as the blog heavily focuses on collaboration which can be tied back to our discussions about agile development.

This blog made me realize that code reviews should not be harsh critiques, but rather helpful conversations that provide insight on what should be improved in your code. It shouldn’t feel like a negative conversation, it should be supportive and friendly which creates a better working environment. For me, it also brings encouragement, as workers will feel more encouraged to improve upon their code if their coworkers are actively supporting them. Code reviews should be focused on the “what” and “how” rather than just listing all of the flaws of the code.

The blog also mentions how people should be reviewing for the future by providing insights that extend beyond the immediate fixes in order for the code to have better maintainability. The reviews should, of course, fix the immediate problems, but should also set up the program for better and for consistent success in the future. It should be focused on the sustainability of the code rather than just fixing all the short-term problems but not addressing how it will look in years. In general, every line of code that one writes should be written with the long-term impact of said code in mind.

Going forward, I am planning on applying these strategies of good code review in my professional career as well as my current academic career. If I am reviewing the code of a peer, I will aim to give constructive feedback that makes it feel encouraging rather than simply telling someone all the problems with their code. Doing this creates a better workplace environment where people feel comfortable with expressing their thoughts and opinions about things, creating a better team atmosphere and promoting teamwork and collaboration. I will also welcome feedback from peers about my work, as it is important to listen to the feedback of your peers, as in the end we are all working together towards a common goal.

Link: https://stackoverflow.blog/2019/09/30/how-to-make-good-code-reviews-better/

From the blog CS@Worcester – Coding Canvas by Sean Wang and used with permission of the author. All other rights reserved by the author.

AI Revolutions in Large-Scale Application Development

The advent of Artificial Intelligence (AI) is changing the software development landscape, making the creation of big project and their related application code faster, smarter, and more efficient. From automating repetitive tasks to optimizing code and enabling predictive analysis, AI empowers developers to achieve more with less effort. This blog explores how AI actual facilitated in normal coder and tester related workers and their tangible benefits give more reliable outcomes without any more works.

               AI acts as a force multiplier in software development, streamlining workflows, reducing errors, and enhancing productivity. Before AI the possibilities of traditional works are very lengthy and so much effort of manual strategy, particular for large projects. By using machine learning, natural language processing, and advanced algorithms, AI tools and platforms help developers at every stage of the application lifecycle, thus easing those challenges.

Key Areas where AI Growing:

Code Generation: In GitHub Copilot AI tools helps developers by generating raw codes, suggesting snippets, and writing full code according to their descriptions.

Bug Detection and Fixing: AI tools like Deep Code analyses coders code and give accurate and deeper result so it gives actionable recommendations in real bugs and fixes their uses in just one click.

Automated Testing: Machine learning algorithms can generate large scale test on minimum time so it actual carry the whole process testing in their application so workers can get time and effortless comprehensive testing.

Real-World Examples of AI in Action

  1. GitHub Copilot: This AI coding assistant generates suggestions in real time, helping developers write efficient and accurate code faster. It makes big projects easier to handle by lowering the amount of manual labor required for repetitive coding chores.
  2. Chatbots for DevOps: AI-powered chatbots doing multiple things automatically like server deployment, monitor application health, and resolve issue in one time so human interventions growth reduced.

Challenges and Limitations is also part of this AI skills. AI-generated code may require careful validation so might be Accuracy Dependence is requirement in project-specific parts. It may be necessary to make an initial training expenditure in order for developers to comprehend how to use AI tools efficiently. Using AI in proprietary projects brings up issues related to biassed algorithms and intellectual property so ethical issue is also fixed it our terms and modifications.

               As AI continues to evolve, its role in software development will expand further. Innovations such as generative AI for full-stack applications, intelligent debugging systems, and adaptive learning platforms will redefine what’s possible in large-scale application development. In conclusion, AI is not just a tool for coders; it is one robot which give accurate result without any further large skills task. Diverse controlling in AI based application is sometime give innovation and creativity and every computer fields.

Citations:

  1. GitHub Copilot Documentation. (n.d.). https://github.com/features/copilot
  2. Amodei, D., Olah, C., et al. (2016). Deep Learning in AI Systems. OpenAI Research Papers.
  3. Applitools AI Testing Tools. (n.d.). https://applitools.com
  4. How AI is Revolutionizing Software Development [YouTube Video]. (2023). Available at: https://www.youtube.com/watch?v=IGQChbLYFqY

From the blog CS@Worcester – Pre-Learner —> A Blog Introduction by Aksh Patel and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patters Chapter 2 (Emptying the Cup)

For this week, I read the Apprenticeship pattern “Emptying the Cup”, the second chapter of the Apprenticeship Patterns. I found this pattern to be very interesting since this chapter teaches you how to effectively become a better apprentice, as well as how to use your experience of problem-solving to become a better member of a programming community later on. While the beginning of this Pattern explains the pouring of the tea cup, it is actually a metaphor that pertains to “clearing your mind of bad habits”, meaning that you should remove all distractions or de-motivators so that you can think more openly about the subject in mind.

I find it very interesting that the rest of the sections describing the “tools” to start your apprenticeship are sorted in a specific manner so that you yourself are familiar with all the experiences and different skills needed to learn a programming language. For instance, there is a problem and solution section in the “Concrete Skills” Section of “Emptying the Cup” that caught my attention. The problem state that a team believes that you cannot write a program, but that is where the solution tells you to learn about building concrete skills in order to convince the team to trust in you to be able to do the work. While the rest of the sections does not touch upon anything specific to programming, they all help you in showing your capability to help with coding.

What I found useful in this chapter was the “Your First Language” section that talked about the effective ways of becoming a better programmer. In the “Solution” section, there’s a specific segment where programmer Ralph Johnson explains in an interview on learning a programming language. When asked about which programming language to start with, he say “…the best way to learn a language is to work with an expert in it. You should pick a language based on people who you know. One expert is all it takes, but you need one.” Like the rest of the “Solution” section describes, I have learned that it is better to learn a programming language when you have an person or a group who can help guide you to writing better programs.

While the rest of the sections start to describe the many different problems and solutions to specific problems, the main takeaway I have from reading this apprenticeship pattern is to openly express your problems and work with your team on showing your commitment to programming in your career. I did not have any specific disagreements with this pattern, but I am still am curious about what the other sections have to show for learning the other patterns.

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

The Long Road

Summary

The long road pattern emphasizes the lifelong journey towards mastering software craftsmanship. In a culture that values quick success, it prioritizes long-term growth and continuous learning over immediate financial rewards and traditional career advancements. This path is more for those who are dedicated to mastering the craft than those seeking quick riches or executive rolls.

Reflection

With graduation behind me, it’s fitting to focus on the long road ahead. One of the lines from this pattern that stood out to me immediately was “For every step you take toward mastery, your destination moves two steps further away.” The ongoing theme through my computer sciences degree was that every time I would gain knowledge in a topic I would also gain even more knowledge about now much I don’t know. This really opened my eyes to how much it is going to take to master the craft. This started to feel daunting as it continued to happen, feeling like the destination is always getting further away. However, another key point in this pattern was that the journey is just as important as the destination.

When I think of what I know now compared to what I knew even just 2 years ago, it’s such a drastic difference. Even with the feeling of the destination getting further away, each step I took was still forward in my journey. With each step I grow and gain skills that I can continue to use. 

As I look to begin my career as a software developer, I understand that quick wealth is not feasible with my current lack of experience and knowledge in the field. This however is not something that will change overnight, which is something I am already aware of. As I look for a job, I really am looking for an opportunity to gain experience and learn while getting paid. This mindset values the knowledge and experience just as much as the monetary value gained from the position. As long as I keep this mentality moving forward I see the experience and knowledge paying for itself down the long road ahead. 

From the blog CS@Worcester – CS Learning by kbourassa18 and used with permission of the author. All other rights reserved by the author.

‘Breakable Toys’ Pattern

The “breakable toys” pattern from chapter 5 is one of if not the most important pattern contained in this book in my opinion. This pattern specifically talks about the necessity of learning from failure even if your work environment does not allow you to do so. A situation like this is common within industries such as software engineering and the example the book gives of a juggler and how someone who can juggle three balls would not attempt to juggle five while actually performing which relates to software engineering as this pattern encourages you to make mistake and learn from your failures on your own time if your workplace does not allow it. “Breakable Toys” also suggests constructing a similar system to the one you may work on at work in order to be able to experiment on your own time and learn from your mistakes in an environment that directly resembles the one you are in at work. You should push yourself to find learning opportunities for yourself through the use of this pattern as if you do not have those opportunities at work then you must make your own in order to continue learning and get better at your craft. It is also stated that your “breakable toys” should be things that you find fun or have interest in so that even though they are meant to provide learning experiences for you, you are still engaged enough to where you look forward to working with them.

I think that this pattern is very important especially to a software engineer. No matter what company you work at there will eventually be a job where you are expected to make nearly no mistakes and you will not be able to try different solutions due to this expectation. But if you are able to experiment with different solutions on your own and see why they may not work or why they do work you can not only learn for yourself but you can also help the team you are working on evolve from using one standardized solution to using one that could be more efficient or faster.

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

Capitilzing on your Title

This week, I chose to read the “Use Your Title” apprenticeship pattern under the “Walking the Long Road” chapter. I found “Use Your Title” interesting as it points out that titles like “senior,” “architect,” or “lead” aren’t accurate reflections of one’s personal skill level. Titles like these won’t alone mean an apprentice has become a journeyman, and due to the lack of craftsmen, apprentices still receive these titles, which can potentially cause feelings of inadequacy or overconfidence. This pattern emphasizes maintaining focus on continual learning and self-assessment, viewing titles as indications of company workflow patterns rather than reflecting a craftsman’s advancement along their journey.

This pattern spins a new perspective on the traditional view of titles, suggesting that titles can provide insight into a company’s structure and values. For example, if a title feels inflated or undeserved, it might indicate a lack of rigorous standards within an organization. On the other hand, a lack of recognition might point to an environment where contributions are undervalued.

It’s interesting how the pattern also brings up formal titles such as “senior” while also acknowledging the existence of informal titles. Informal titles are team- or company-wide accepted roles being fulfilled by certain employees without having a title to reflect such. It seems that both have sway in the perception of the validity of one’s work, but informal titles, in my opinion, seem more applicable to one’s skills rather than workflow.

Looking at Dave Hoover’s testimony solidifies things my mentors have told me in the past as well. If you move up the totem pole, it doesn’t always correlate with your development and is more a reflection of a company’s need for more craftsmen. I’ve been told that as a rule of thumb, gauge your progress at your current position every three years. If you feel like your work is underappreciated or your title is inflated or undeserved, then it might be time to move on to better fulfill your personal development. A position at a company may work at first, but over time it is important to also take an objective look and figure out if that position still suits your development or hinders it.

From the blog CS@Worcester – Eli's Corner of the Internet by Eli and used with permission of the author. All other rights reserved by the author.

Learning How We Fail Until We Hit Growth

Hey Everyone! In the nonstop pursuit of excellence, the “Learn How You Fail” pattern reminds us of a old forsaken truth: failure is not a curse but a catalyst for growth. It challenges us to confront our weaknesses head-on, to seek out the patterns and behaviors that lead to our missteps, and to use that self-knowledge as a powerful tool for transformation.

The whole point of this pattern means a lot to me deeply, as it recognizes that true creativity and work ethic are not born from a quest for perfection but actually a willingness to form somewhat of a imperfection. As Atul Gawande states, “Ingenuity is often misunderstood. It is not a matter of superior intelligence but of character. It demands more than anything a willingness to recognize failure, to not paper over the cracks, and to change.”

Personally, I find this pattern both humbling and it gave me a sense of confidence. After reading it a couple of times, it forces us to confront the uncomfortable reality that our successes are often counterbalanced by our failures and weaknesses. I’ve always related to the fact that you have to get out of the comfort zone otherwise you’ll stay there forever. Reason is, in that discomfort is the seed of growth – by consciously acknowledging our limitations, we open ourselves to the possibility of going past them.

This pattern has profoundly influenced my perspective on the intended profession. It has reinforced the idea that your craft is not a destination but a continuous journey of self-discovery and self-improvement. By embracing the idea of “learning how we fail,” we create a mindset of resilience and adaptability, qualities that are essential in the ever-evolving landscape of software development, especially after reading about these patterns.

One aspect of the pattern that resonates particularly is the hard point on making conscious choices. By gaining self-knowledge about our patterns of failure, we empower ourselves to make informed decisions, sort of how some work better under pressure– whether to work on fixing those weaknesses or to acknowledge our limitations and focus our efforts elsewhere.

Lastly, the “Learn How You Fail” pattern is a powerful reminder that failure is not an enemy to be feared but a guide to be embraced. It is a call to take in vulnerability, to find the illusion of perfection, and to strive as more self-aware, adaptable, and the best version of ourselves we can be in and out of software development.

andicuni
May 15, 2024

From the blog CS@Worcester – A Day in the Life as a CS Blogger by andicuni and used with permission of the author. All other rights reserved by the author.

Embracing the Cycle of Growth

Hey Everyone! The “Create Feedback Loops” pattern shines a light on this predicament, reminding us of the fundamental importance of going outside the box, objective feedback to fuel our growth and development.

At its core, this pattern challenges the idea that self-assessment alone is enough for recognizing our strengths and weaknesses. It acknowledges the built in biases and limitations of our own perspectives, which can be hooked by the very teams we work with or the environments we are around. The solution is in actively creating methods that provide us with a mirror, reflecting our true selves through the eyes of others.

What resonates with me about this pattern is its emphasis on the nature of growth. I’ve always been one to say how we never stop learning in this field and by requesting feedback early, often, and effectively, we can create a clean cycle – one where we become conscious of times where we lack understanding, take action to improve, and then seek further feedback to validate our progress. We need to understand there is nothing wrong with taking criticism. This continuous loop not only fuels our personal development but also helps search for a mindset of success and openness to learning.

Personally, I find the pattern’s recognition of the difference between useful and ineffective feedback is definitely a new way I would’ve originally thought about it. It highlights the importance of constructive criticism from distractions, separating obtainable data from well-meaning but misguided advice. This judgment supports us to focus our efforts on the feedback that truly matters, giving us a new way to make targeted improvements and avoid the mindset of false confidence or unnecessary self-doubt.

So to speak on how this impacted me, I like when the patterns give me a different influence on my perspective on the intended field in a positive way. It has strengthened the concept that true mastery is not a isolated push but rather a collaborative journey, where we actively seek out and embrace the perspectives of others. By creating feedback loops, we not only improve our own skills but also contribute to the growth of those around us, fostering a culture of mutual support and shared learning.

In conclusion, the “Create Feedback Loops” pattern is a powerful reminder of the importance of seeking objective, actionable feedback in our quest for growth and mastery. It challenges us to be open to the idea of okay to listen, okay to fail, and okay to continue trying. By cultivating this cycle, we encourage our own development but also add to the supportive growth of our peers and technical community.

andicuni
May 15, 2024

From the blog CS@Worcester – A Day in the Life as a CS Blogger by andicuni and used with permission of the author. All other rights reserved by the author.

Teaching to Learn: Understanding Through Sharing

Hey Everyone! As apprentices in the making , we spend countless hours absorbing knowledge, honing our skills, and making our craft as efficient as possible. However, the “Share What You Learn” pattern reminds us that true growth lies not just in getting knowledge but also in generously sharing it with others.
The essence of this pattern is fairly captured in the quote from Twyla Tharp: “Look at the luckiest people around you, the ones you envy, the ones who seem to have destiny falling habitually into their laps… they involve their friends in their work, and they tend to make others feel lucky to be around them.” This resonates deeply, as it highlights the equal relationship between sharing knowledge and creating a fulfilling, comfortable community.
Personally, I find this pattern both thought-provoking and inspiring. It goes against the idea of knowledge is a finite resource to be put aside, instead advocating for its free exchange and somewhat of distribution. By sharing what we learn, we not only empower others but also solidify our own understanding. As the saying goes, “When one person teaches, two people learn.” I’ve never resonated with a quote as much as that one. Teaching forces us to organize our thoughts, anticipate questions, and articulate concepts in a clear manner – a process that always deepens our understanding.
Moreover, this pattern has influenced my thoughts on our field. I now recognize that true mastery extends beyond individual expertise; it follows the ability to communicate effectively and uplift others. The pattern explains how a skilled craftsman who fails to share their knowledge ultimately limits their impact, while one who embraces this pattern becomes a trigger for collective growth, leaving a lasting legacy that goes past their individual contributions.
One aspect of the pattern that I agree with a lot is the perspective of knowledge sharing. It serves as a reminder that not all lessons are ours to share, particularly those that may harm others or breach confidentiality. This way highlights the importance of wisdom and care when sharing knowledge, ensuring that our actions contribute to a positive, trustworthy environment.
Overall, the “Share What You Learn” pattern has inspired me to embrace the joy of knowledge sharing and to view it as an important part of my professional journey. By defining what I’ve learned, I can make stronger connections within my community, validate my own understanding, and help to the collective improvement of our craft as we say how we never stop learning. It’s a upright cycle that benefits all involved, to continue to make an environment of continuous growth and mutual support.

andicuni
May 15, 2024

From the blog CS@Worcester – A Day in the Life as a CS Blogger by andicuni and used with permission of the author. All other rights reserved by the author.

CS-448: Week 15

The Long Road

The pattern “The Long Road” is about how in today’s culture, we value overnight celebrities, rising stars, and quick results. This leads to the conditioning of assuming that the shortest path possible is also the best path. With this thinking, people say to take the highest paying job and the first promotion available; however, this takes away from developers being able to slowly build up their skills.

The first step to this pattern is to accept that this nontraditional way of thinking may be considered strange because the focus is set on learning and the long term rather than a high salary and traditional views of leadership. The pattern highlights the importance of planning for the long term, and to plan on being a software developer for decades. Planning for the long term will help to influence what jobs to take and future ambitions. The pattern emphasizes planning for the long term because it takes a long time to comprehend the deeper, more complex topics that come with software development.

The pattern states that this is not a pattern for people who’s main focus is monetary gain. This is not to say that those who follow this pattern will not be able to make money, but it is not their main focus. If monetary gain is the main motivator for someone, they may find themselves counting down the days to retirement as opposed to the craftsman who will joyfully work until the end of their career.

In order to plan for the long term future, the pattern suggests thinking about yourself a long time from now, 20 plus years ahead. With that in mind, imagine what you would want your professional history to look like, and the biggest influences. Using that as a baseline can help plan for future career choices.

Conclusion

I found this pattern to be interesting because it showed a perspective that most do not talk about. The idea that the journey of a craftsman is a long road, so should be treated as such changed the way how I view going about my own career. Rather than focusing solely on how high the salary is, focusing on learning and long term goals will lead to a more joyful and enjoyable career.

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