Category Archives: CS-448

Sprint 3 Retrospective

 


In Sprint 3 I worked on finishing the checkinventoryfrontend. With the
shorter time of the sprint, I went to work on fixing an issue I encountered
in the previous sprint where the frontend would only display an error
message saying that there was some problem in the html. At the same time I
was trying to figure out how to get npm to work in the new file structure,
since when I try calling npm in the terminal it kept failing. For the
longest time I couldn’t figure out how to get the frontend to display
correctly, trying all sorts of solutions from moving the package.json file
around to deleting the deprecated yarnlock file. Eventually, I settled on
figuring out how to change the npm files to allow npm to reach the new
frontend folder I made. At some point, Jason asked if there was anything the
rest of the team could work on in checkinventoryfrontend, and I said the
documentation needed to be updated and that nodemon needed to be
implemented. Jason then created a separate branch based on mine called implementing-nodemon, where he changed the package.json and gitpod.yaml files to have nodemon
and other dependencies. 

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/tree/implementing-nodemon?ref_type=heads


Somehow, over the course of these dependencies being added, the frontend
started working again. The error must have been rooted in one of the
dependencies not working properly, or something to that effect. I looked int
o the changes Jason made, and he added a section to the gitpod.yaml that
would of implemented certain npm dependencies.


https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/commit/997bd2bd2197def31c8ae29efea071f9d07e077f


 Either way I’m just happy to be able to finish up the work in the
frontend. I went into Jason’s branch and cleaned up some of the shell files
so that they work as intended. The frontend-dev-up.sh file needed to use
frontend-dev instead of dev since that is what npm recognises in this repo.
Also, frontend restart needed to use the proper name of frontend-prod-down
and up.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/commit/480596810546e3286f8821d24cafe68bcd0fc1df

Then I started on cleaning up my own work for the next semester. I removed
the branches I had created since they either were redundant or straight up
didn’t work. Then I cleaned some deprecated files out of the implementing
nodemon branch while I was fixing the shell files, like an extra package
json file that was created in the base repo. 

I learned a lot about working with the frontend throughout this sprint, and
the entirety of the semester for that matter. I definitely want to brush up
on how npm works and functions, because I feel like most of my problems stem
from a lack of understanding. I also want to give credit to my team, who
have helped me out more than they realize, especially since I have been
balancing my work and school life. Hopefully the final presentation
represents all of our efforts over the semester.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective Blog

As we conclude Sprint 3, it’s essential to take a moment to reflect on our experiences, the hurdles we overcame, and the knowledge we’ve gathered. This sprint has been a time of significant learning and adjustment, marked by both challenges and achievements that have contributed to our team’s development and cohesion. In this retrospective, we will explore the difficulties we encountered, the lessons we learned, and outline our strategies for future improvement.

One of the primary challenges this sprint was writing test cases for the frontend using Vue.js and Jest. What we anticipated as a routine task turned into a more complex issue due to the nuanced behaviors of Vue components and their interaction with Jest. Initially, our team struggled with the integration of Jest into our existing Vue projects, facing issues with mock dependencies and asynchronous data handling. However, this challenge provided a profound learning opportunity. We dedicated time to in-depth research and team discussions, which enhanced our understanding of both Vue and Jest. This ordeal not only improved our technical skills but also highlighted the importance of persistence and in-depth understanding in tackling software testing.

Another significant aspect that defined Sprint 3 was our collaboration with another team regarding testing strategies. Initially, communication gaps and differing expectations on testing methodologies posed substantial challenges. These issues were exacerbated by our remote working arrangements, which sometimes led to misunderstandings and delays. To address these issues, we implemented more structured communication protocols, including regular joint meetings and shared documentation. This approach not only smoothed out the wrinkles in cooperation but also fostered a stronger relationship between the teams, setting a foundation for more efficient and effective collaboration in future projects.

Despite the hurdles, Sprint 3 has been pivotal for our team’s growth. We’ve sharpened our skills in frontend testing, deepened our understanding of effective cross-team collaboration, and strengthened our adaptability to new tools and environments. Open communication has once again proved to be the bedrock of our success, ensuring that every team member was engaged and that issues were addressed promptly and transparently.

Moving forward, we aim to build on the lessons learned during this sprint. Our focus will be on refining our testing practices further and enhancing our communication strategies with other teams. We plan to conduct workshops to share knowledge and best practices on Vue and Jest, aiming to elevate our collective expertise. Additionally, the establishment of a cross-team “best practices” repository for testing is in the pipeline, which will serve as a central resource to aid in future testing endeavors.

In conclusion, Sprint 3 was a testament to our team’s resilience and capability to adapt to new challenges. We’ve not only navigated through complex technical issues but also improved our collaborative processes, setting a robust precedent for future sprints. With a commitment to continuous improvement and a supportive team environment, we are well-equipped to tackle upcoming challenges and work towards our collective goals. The road ahead is promising, and with our team’s shared dedication, we are poised to continue our journey of growth and success.

Issues addressed during this sprint:
Write test cases for Header.vue
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/51

Get in touch with Team: 01-2 and discuss Frontend Tests and their findings
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/92

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

CS448 – Sprint 3 Retrospective

Last Tuesday, we concluded our final of three sprints for CS448 – Software Development Capstone marking the end of the semester/course aside from our final presentations and the ‘capstone’ to my undergraduate Comp. Sci. degree. This sprint and throughout the semester, my team demonstrated exceptional cohesion and proficiency as we learned new skills and frameworks, tackled challenges, and grew together. At the end of last sprint, we still had a few issues with some of the configuration files in the frontend repo we’ve been focusing on: CheckoutGuestFrontend which were causing Pipeline failures. So, we began this sprint by focusing on getting the pipeline straightened out and then moved into strategizing front-end testing frameworks and implementation after having discussed these topics last sprint with

Team 2.

As a team, we managed to finish all of our tasks for this sprint and come to a tidy/clean close to the semester and Thea’s Pantry project. We split the four .vue files which we needed tests developed for up by person, but all helped each other get the first one/configurations sorted:

‘Fix Pipeline for Frontend’ – As mentioned, there were some issues with the pipeline from our additions and designing of the .vue frontend files for CheckoutGuestFrontend in merging our additions. So, we started off this sprint by focusing on this; we did a group code review sharing screen and we were able to work as a team to identify and resolve the problems, passing the pipeline when we finished. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/49

‘After discussing with Team: 01-02, strategize Front-end test implementation’ – After resolving the pipeline issues (and having met with Team 2 to discuss frontend testing), we came back together as a group to strategize how we will go about implementing tests for the various components of CheckoutGuestFrontend. This resulted in creation of four new issues for our board, each representing the task of coding and implementing tests for one of the four .vue files in our repo – planning for one to be addressed by each team member. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/93

‘Test Layout.vue (most cases)’ – The .vue file which I worked on from our repo was Layout.vue. This is arguably the largest/most complicated of our files containing code for most of the objects on the screen and as the name suggests, assigning their layout on-screen to be cohesive and according to specifications. This also translated to having many components requiring testing, so I assisted in strategizing tests for some of the other files with my teammates so I could be a bit more familiar when designing my tests.  https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/52

Being a part of this team has been an amazing and enriching learning experience. My group was cohesive and helped each other out when they could, contributing to an enjoyable team environment. Through thorough analysis and collaborative problem-solving sessions, we unearthed and swiftly addressed the root causes of inefficiencies, ensuring a streamlined development process going forward. One of the most significant accomplishments of this sprint was our concerted effort to fortify our codebase with robust frontend tests. Recognizing the importance of software reliability, we dedicated time and resources to meticulously design and implement a suite of tests tailored to our repository’s specific needs. This proactive approach not only bolsters our confidence in the integrity of our code but also enhances our ability to catch and rectify potential issues early in the development cycle. As I look back on the sprint and semester, it’s clear that our team’s collective expertise and collaborative spirit were instrumental in achieving these milestones. By prioritizing quality and teamwork, we’ve not only overcome immediate challenges but also laid a solid groundwork for continued success in future endeavors.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

CS-448: Sprint Retrospective

Sprint 3 Retrospective

What worked well

The issues the team had made for this sprint were larger in scale, but broken into smaller issues. This was done mainly to have enough issues for everyone to work on. However we found that working together during the scheduled class periods led to greater success rather than working on the issues individually. The team utilized mob programming in order to complete many of the issues for sprint 3. We preferred this approach because some of the issues were dependent on other issues being completed first. Therefore each member would have to wait until the previous issue was completed to work on their issue. Because most of the team members had little experience with the topics related to the issues we worked on, mob programming was also beneficial in allowing us to problem solve together.

What didn’t work well

One thing that did not work well was how the team managed our time during this sprint. By the end of the sprint, the team had completed most of the issues in weight, but failed to complete all issues. The team could have communicated better to ensure we had completed all the issues before the sprint review. Although the team benefitted from mob programming, mob programming did not have to be as heavily relied on if our issues were better written. In the effort of making the issues small and concise, we may have went to far when breaking down issues. Because this was the team’s third sprint working together, we have had enough time to get used to how each other work, the workflow, and GitLab itself. Therefore for this sprint, there was more that worked well than what did not work well.

Changes to make as an individual

A change that could be made as an individual is to encourage others to voice their opinions on what they think should be done. As stated above, the team completed issues through mob programming which led to multiple in person meetings and discussions. During some meetings, when we would get stuck and unsure what to do, I noticed I would list ideas of what I thought the team should do. Rather than always voicing my opinion, I would make the change of asking the other team members what they thought was the best plan to solve the current issue. This change would help everyone feel that they are included in the discussion and voicing their opinion is encouraged.

Changes to make as a team

As a team, a change that could be made is having better time management and keeping better track of important dates. As mentioned previously, the team failed to complete all issues from this sprint. This was partly due to the team thinking we had another in person meeting to continue working on our issues. This could have been avoided if we had been more on track with due dates. There were times where a team member did not communicate well resulting in missed meetings and confusion. A change the team could have made is to work with each other so that everyone stays on task and does what is necessary to forward the team’s progress.

GitLab Activity

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.

Sprint 3 Retrospective

This sprint was heavily focused on the InventoryBackend repository. One of the main goals of this sprint was to have made some meaningful refactorization to the backend that would take care of out of date code. This old code would turn out to cause a lot of confusion later on when we would attempt to write automated tests for the backend.

Our team met with members from OL Team 2 to discuss what resources they had to help us implement nodemon. This was then taken over by another member of the team as I mainly worked on designing the tests for the backend. Afterwards I would work with another team member who was working on researching and setting up mocha and chai in the backend. Together, we would take the tests I designed and attempt to develop working tests for each of the API calls. The biggest issue we ran into was that the test we were using as an example from the GuestInfoBackend seemed to be unit testing the endpoints rather than testing the API calls. This paired with the errors involving Gitpot and trying to connect to a local host left the team unable to get working tests by the end of the sprint. However, the information we have learned can still be documented so that the next team/developer who looks at this issue wont have to start from square one.

What Worked Well:

This sprint felt like we had a better understanding of the issues on our board before going to the sprint. This led to us having a good plan for the order in which the issues needed to be addressed. This also means that unless one of us ran into an issue, a lot of these issues could be handled individually. While this was great for cutting down on the lengthy meetings we were having in the past, it did also hinder the communication between the team.

What Didn’t Work Well:


Throughout this sprint, we had significantly less time in meetings. Although it feels like the same amount of team and individual effort was put into this sprint, the overall takeaway from the sprint feels less. With most of the work being done individually, there were a lot of opportunities for information to not be shared with the team. This made it hard to keep up with issues and what was going on outside of the standups. 

Team Improvements:

Moving forward, if we were to have another sprint together I would say that our biggest improvement can come from better documentation. Our first 2 sprints we were lucky enough to have a lot of time actually working together as a team. Having less verbal communication this sprint meant we were very reliant on our stand-ups and any documentation we created for issues. Creating better comments in the issues keeps everyone on the same page for what has been done to fix the issue. Especially if we are stuck and ask for help from another member of the team. 

Personal Improvements:

When it comes to working on sprints in the future, I plan to keep myself involved in what the rest of the team is doing throughout the sprint. While it was great knowing I could trust my team members to handle the issues on their own, it still felt like I was missing information or not keeping up with the collective knowledge. 

Issues:

Meet with OL team 2 to discuss implementation of Nodemon:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/100 

Design unit tests for InventoryBackend:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/96 

Weight accepts the wrong type of input in the frontend:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/56 

Create removeInventory automated Test using Mocha and Chai:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/55

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

CS448 Software Development Capstone – Sprint #3 Retrospective

The third sprint was uniquely challenging for our group, because each of our members were faced with personal challenges and setbacks while we worked to resolve our assigned issues. I was primarily concerned with writing a unit test for the ‘InventoryBackend’ microservice that would evaluate the operation for adding a weight value to the weight stored in the inventory. This test was supposed to ensure that responses were returned for either of the operation’s two outcomes – a ‘200’ HTTP status reflecting a successful addition to the Inventory’s weight, or a ‘401’ HTTP status, indicating that the HTTP request contained invalid values for one or both of the ‘weight’ and ‘Id’ fields.

While discussing the unit test design process with Professor Wurst, we realized that the HTTP ‘401’ error code was the incorrect choice for communicating the error to the user. According to the list of HTTP response codes hosted by Mozilla, the ‘401 Unauthorized’ error code from the server reflects an unauthorized or unauthenticated request from the client. In our situation, where there exist invalid values in our HTTP request, the error code ‘400 Bad Request’ would be more appropriate.

I was not able to get my unit test to a point where I felt that it was ready to be merged into the main ‘InventoryBackend’ branch. I was having difficulty getting the backend server to build in my Gitpod workspace with the ‘bin/up.sh’ command, which caused the portions of the test which checked for a valid HTTP response to fail. I also had doubts about the construction of my test, as one of my groupmates had pointed out that my test should be using the getInventory function to monitor the value of the Inventory’s weight as the operations are performed.

One of the things that was holding me back the most, in addition to the challenge of researching and learning unit test design, was that I got sick in the middle of the sprint. It wasn’t anything serious, but my energy levels and ability to concentrate were impacted, which ultimately had an effect on my work this sprint. I would have liked to contribute more than I was able to in this last sprint.

Another thing that was holding me back form designing the best unit tests that I could was that I need to spend more time studying and reading about HTTP backend operations. I’ve realized the importance of setting aside the time to read, absorb, and reflect on the material through writing and taking notes as part of the learning process. Over the summer after this semester, I want to take the time to read a book on software unit testing and take notes as I read. I’ve been considering taking the advice from the Apprenticeship Patterns textbook to build my own personal wiki as a way to organize my notes on all the subjects I’m interested in, like software development, information technology, and data science.

Despite the challenges in my own life during the sprint, my team was a tremendous support during the sprint and I’m really proud of all the things they were able to get done while I wasn’t feeling my best. We all did our best to communicate over text between meetings to coordinate our next moves, and we all still showed up for our scheduled voice calls to work on our assigned issues together. I would be happy to work with any or all of them again, and I’m hoping to keep in touch with all of them after graduation.

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

Sprint Retrospective April 30, 2024

During this sprint, I worked on three issues that were assigned to me. As a group, we all did well in our first and second sprints and felt we had much to improve on during both of those sprints as well as this one. There was mainly one area where we could improve as a team. The first issue that I worked on this issue was issue #99 “Investigate InventoryFrontend to ensure hot-reloading the backend doesn’t affect functionality”(3).

When looking into this repository’s script files I was initially very concerned with the possibility of nodemon being able to be implemented without causing functionality issues. Within the script files there was code that would need to be refactored, and code that connected the backend to the frontend was also outdated and would need to be refactored, they were both using an outdated way of classifying inventory weight. They were using individual item objects instead of a weight integer. I met with Dr. Wurst to discuss what would need to be done in order to progress, thankfully I was mistaken in thinking that both repositories would need to be refactored before nodemon could be implemented, I was told to look into the inventoryFrontEnd to see how I should implement nodemon. The next issue I started working on was “Research nodemon as a way to run backend in ‘development mode’ “(1).

I spent a very long time on this issue looking through nodemon documentation, articles discussing implementing nodemon on pre-existing repositories, blog posts discussing the best ways to implement nodemon into pre-existing projects and only after all of that, I decided to look at the inventoryFrontEnd which had already implemented it. After looking at where it was implemented I was very confused as the solution seemed to be deceptively simple. The implementation of nodemon falls under issue #98 “Edit script files to accommodate hot-reloading for InventoryBackend”(2).

Only one line of code was needed to properly implement it. I was both relieved and very upset by this. I had spent hours researching and reading what needed to be done being very confused by conflicting information from different articles and blog posts only for one line of code to be written. While I did not need to do as much research as I had done, I did learn a lot about nodemon and how it works. The last thing that I will discuss in this blog post is how our group worked together and what we could improve upon for future sprints.

Our group learned a lot from the previous two sprints and this sprint we were able to improve upon our performance significantly. However, we definitely could improve with checking the calendar for when the meetings with Dr. Wurst are. When the sprint review came up I had completely forgotten that it was that day, thankfully we were able to reschedule for the next class to have the review. We got very lucky this sprint, but in future sprints we would have to be far more careful with deadlines and important dates.

Issues:
(1) Issue 97 : https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/97
(2) Issue 98 : https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/98
(3) Issue 99 : https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/99

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

Embrace Growth: Be the Lion’s Tail Instead of the Fox’s Head

Summary of the Pattern:

In the pursuit of professional growth, stagnation can often be a hindrance. The pattern, “Be the Worst,” advocates for seeking out environments where one is the weakest member of the team. By intentionally placing oneself in a position where there’s ample room for learning and improvement, individuals can continue to progress in their careers.

Reaction to the Pattern:

“Be the Worst” challenges conventional wisdom by advocating for humility and a willingness to learn from those more skilled. Initially unreasonable, this approach fosters an environment conducive to continuous learning and development. The personal narrative of David H. Hoover underscores the transformative power of embracing this pattern, highlighting the significant gains that can be achieved by putting oneself in a team of exceptional developers.

Interesting Insights:

The notion of deliberately positioning oneself as the weakest member of a team prompts reflection on personal growth and professional aspirations. It underscores the importance of humility and the recognition that true progress often stems from embracing challenges rather than seeking comfort in familiarity.

Impact on Professional Perspective:

For individuals navigating the dynamic landscape of their profession, “Be the Worst” prompts a re-evaluation of traditional career trajectories. It encourages a shift from a mindset focused solely on achieving positions of authority to one centered on continuous improvement and skill acquisition. This pattern has the potential to redefine how individuals approach their careers, emphasizing the value of learning and adaptability in an ever-evolving industry.

Disagreements and Considerations:

While “Be the Worst” advocates for joining teams where one is the least skilled, it’s essential to acknowledge potential challenges. The risk of feeling overwhelmed or inadequate may deter some individuals from fully embracing this pattern. Moreover, the pattern’s emphasis on humility and learning from others may not align with certain cultural norms that prioritize individual achievement over collaborative growth.

In conclusion:

“Be the Worst” serves as a reminder of the transformative power of humility and the value of surrounding oneself with mentors and peers who inspire growth. By embracing the discomfort of being the least skilled team member, individuals can unlock unparalleled opportunities for learning and advancement in their professional journey.

From the blog CS@Worcester – Site Title by rkaranja1002 and used with permission of the author. All other rights reserved by the author.

CS-448 Week 14 Breakable Toys

The “Breakable Toys” pattern offers a solution to a common problem faced by software developers, which is the lack of opportunities to learn from failure in a professional setting. The purpose of this pattern is to create a safe environment where developers can experiment, make mistakes, and learn without fear of repercussions. By building toy systems that mimic real-world settings but with reduced scope and complexity, developers can gain valuable experience and develop their skills more effectively.

The intriguing thing about this pattern is its emphasis on the importance of failure in the learning process. In many industries, including software development, there’s often a stigma attached to failure, which leads to a culture where taking risks is discouraged. However, this pattern changes that mindset by suggesting that failure is not only acceptable but also a necessary step toward growth and improvement.

As someone whose goal is to become a software developer, this pattern has certainly changed my perspective on my approach toward learning and skill development. It highlights the value of creating a learning environment that prioritizes experimentation and iteration over perfection. This helps get rid of the fear of failing and being afraid to make mistakes, and now I see them more as opportunities to grow and learn.

One of the aspects of the pattern that resonates with me is the idea of “budgeting for failure”. By allocating time and resources to build and experiment with breakable toys, developers can proactively invest in their own professional development. This proactive approach to learning is essential in this industry due to the continued growth and evolution, where adaptability and continuous improvement are key to success.

While I do like this style of thinking, I can also see potential challenges in implementing this pattern in a corporate environment that may prioritize productivity and efficiency over learning and experimentation. Convincing management or team leaders of the benefits of breakable toys may require a shift in mindset and a willingness to embrace a culture of learning and innovation.

Overall, the Breakable Toys pattern offers a refreshing perspective on how to approach learning and skill development in software development. By creating a safe space for experimentation and failure, developers can cultivate a growth mindset and become more resilient and adaptable in the face of challenges.

5. Perpetual Learning | Apprenticeship Patterns (oreilly.com)

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

In this week’s blog post, I will be discussing the “Expose Your Ignorance” pattern discussed in chapter 2 of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This week, I chose this topic for my blog post because I think being able to show that you don’t know everything and can have confidence in learning is essential to growth, both professionally and personally.

This section of the chapter discusses that learning is an essential part of the development process. “Show the people who are depending on you that the learning process is part of delivering software. Let them see you grow. According to research by the social psychologist Carol Dweck, the need to appear competent is ingrained into people of most industrialized societies. These societies are increasingly dependent on your competence as a developer, as software creeps ever-deeper into our everyday lives. Yet because of your inexperience, you have many zones of ignorance. You are in a bind. The people around you—your manager, your client, your colleagues, not to mention yourself—are all under tremendous pressure to deliver software. You can see the need for confidence in people’s eyes when they ask you how long feature X will take you to finish. There can be tremendous pressure to pacify them, to reassure them that you know precisely what they want, how you’re going to give it to them, and when.” The need to appear completely in control and competent when you are new is a very difficult instinct to let go of, but it is essential to free yourself of it if you want to progress.

You must be honest with your colleagues and clients, don’ just tell them what they want to hear because what they want to happen might be impossible. “Software craftsmen build their reputations through strong relationships with their clients and colleagues. Conceding to unspoken pressures and telling people what they want to hear is not a good way to build strong relationships. Tell people the truth. Let them know that you’re starting to understand what they want and you’re in the process of learning how to give it to them. If you reassure them, reassure them with your ability to learn, not by pretending to know something you don’t. In this way, your reputation will be built upon your learning ability rather than what you already know.”

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.