-
Unlocking Success Through Understanding Failure
Throughout the long road of lifes, we always strive to find success, but sometimes we may hit roadblocks and fail. Some of us choose to accept those failures and learn from them, but others may neglect those failures and choose to take an alternative route. The Learn How You Fail pattern, emphasizes the importance of embracing failure. Embracing failure is a crucial aspect of not only personal growth but also professional growth. This pattern encourages us to look for our weaknesses and patterns of failure, and instead of avoiding them, accepting and learning from them. If we can gain knowledge on how, why, and what led to our previous failures, we can learn from them, make adjustments, and pave a path to success in the future.
When we think of the word failure, we often think that it carries a negative connotation, referencing setbacks or disappointments. Yet, in our journey as aspiring craftsmen, failure is not just part of our professional learning, it is possibly one of our greatest teachers. We’ve all experienced some sort of failure at some point in our lives. But the most important part of dealing with failure is pinpointing why we failed, fixing it, and taking those issues head on.
I found this pattern to be extremely interesting considering many people give up after they fail. Failure isn’t something that should be feared or avoided. Instead it should be embraced as a catalyst for learning and self development. It underscores the idea that true growth comes from a willingness to confront our failures and adapt. What I find particularly interesting about this pattern though, is its emphasis on self-awareness and introspection. By actively seeking to understand our patterns of failure, we can empower ourselves to make better decisions about our personal and professional development.
After reading more, I was able to connect the pattern to the software development field. In the field, we cannot just expect to find success. Through lots of learning, practice, and trial and error, we can eventually find success. Instead of viewing failure as a setback or embarrassment, I view it more as an opportunity for reflection and growth. I now realize the importance of acknowledging my successes but also embracing my failures as learning experiences. In the future, I plan on having a more proactive approach towards identifying and addressing any of my weaknesses, rather than just ignoring them.
With this being said, the Learn How You Fail pattern, offers valuable insights into the importance of embracing failure as a means of personal and professional development. By learning from our failures, we can ultimately find success in our chosen fields.
-
Sprint #3 Retrospective
What Worked Well:
Sprint #3 was our last sprint as a team and appeared to be one of our easier sprints since we were all familiar with our team workflow, who was doing what, and reviewing processes. In Sprint #3, we were tasked with completing seven different issues for a total weight of 25 points. As a whole, we completed six out of our seven issues for a total weight of 24 out of 25 points. We managed to complete many issues as a team, which was extremely helpful. By combining five minds, we could work in an efficient manner. Something worth noting was our communication this sprint. In all three Sprints, we conducted weekly meetings either in person or over Discord. Additionally, we had weekly standup meetings informing the group with what everyone was currently working on, doing next, or needs help with. I noticed that once we finished one issue, nobody hesitated to start another issue. This helped propel the project forward. Connecting all three sprints, Sprint #1 was a learning process, Sprint #2 was learning how to efficiently work with each other and complete tasks in an effective manner, and Sprint #3 was combining everything we have learned and putting it together. Sprint #3, whether it was our workflow, completing issue process, review process, or communication, we were able to combine everything and find success. One thing I particularly enjoyed was the comments we made on issues. Everyone on the team wrote comments informing the team what was going on within an issue, what the issue needed for completion, and any changes made to contribute.
Improvements As A Team:
We made some drastic improvements from the previous sprints in regards to how we took on work, the time we worked on it, our review process, and much more. Considering this is our final sprint as a team, I believe we are more than capable of bringing what we have learned into the workforce. To continue growing individually on our own teams, I believe it would be important to continuously build on communication. Regardless of the group or team we are on, it’s important to always provide updates, feedback, and details upon what we are working on, completing, any problems, any help needed, and so on. By continuously building on communication, asking questions, and continuing to refine and develop our skillset, we can set ourselves up for success in the future regardless of the team we are on.
Improvements As An Individual:
During Sprint #3, I was able to work on four different issues. My first issue I completed individually and it was Update and Review InventorySystem/Documentation. This issue required me to go through the different files and add any files, comments, or updates, so that everything was corrected for future sprints. My other three issues I completed with my team included, Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages in the InventorySystem/InventoryAPI, Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages in the InventorySystem/InventoryBackend, and Determine what needs to be done for GuestInfoFrontend. For the Verifying issues, these involved adding and enabling the different linters in our system and testing their respective pipelines to ensure they passed. If they didn’t pass, we needed to go into their specific files to make changes to correct them. For the Determine what needs to be done for GuestInfoFrontend, involved the team building the frontend to view its contents and code. Here we created new issues for future sprints in regards to what needs to be completed, what can be changed or implemented better, and how we can improve the GuestInfoFrontend. For individual improvements, I’d like to continue being more of a team player where I’m open to help and support anyone on my team and voice my thoughts and opinions. Even if it’s just reviewing work and mentioning some tips or ideas, it can be extremely valuable. Additionally, when writing code or fixing documents, I’d like to add more comments. By doing so can allow anyone to understand my thought process while I’m working on issues. It would also allow other people to understand my work and not get lost or confused, allowing for anyone to contribute, add on, or provide feedback on what I’ve completed. Keeping that in mind, I believe it’ll help me grow as an individual and a teammate, and help me in numerous ways with my professional career.
-
Sprint #2 Retrospective
What Worked Well:
Sprint #2 was another productive learning experience for our team. We were able to continue building upon the momentum gained from Sprint #1 and were able to achieve commendable progress. In this sprint, we were tasked with completing eight different issues to reach a total issue weight of 30. We crushed this number, completing all eight of our issues on our issue board before the end of the sprint. Something worth noting was our familiarity with the project, what tools we needed, and the process. When comparing last sprint to this one, we found ourselves navigating through GitLab and GitPod more efficiently without any major issues. This resulted in a much smoother workflow. Additionally, I thought that our communication throughout the Sprint remained a cornerstone of our success. We stood up to date with scheduled meetings through Discord and in-person, allowing us to touch on some points, any updates, problems, discussions, and allowed for collaborative problem-solving. This consistent communication fostered a sense of cohesion within the team and ensured that every team member stayed aligned towards completing our tasks. I also found our workflow to be great. We completed some issues together and some individually, but as we finished one thing no one was hesitant to pick up another issue, help someone out, or review work. In regards to what didn’t work well, I don’t have much. Sprint #1 was a learning process for the entire team and once we understood everything, how to time manage our work, and how everything functions in the system, we brought what we learned into Sprint #2. We were able to complete tasks in a very timely manner while also knowing exactly what’s happening in the system and how to correct any issues.
Improvements As A Team:
We made some drastic improvements from the previous sprint in regards to how we took on work, the time we worked on it, our review process, and much more. Although I really liked the progress our team made throughout this sprint I believe one possible area for improvement could potentially be commenting or adding notes for work being completed. As stated, some tasks we completed individually. With this being said, when having other individuals of the team review work, it can be a little challenging to actually see what was changed, added, or the thought process behind someone’s work. By adding some comments directly to issues or connected to merge requests, it allows for both reviewers and anyone going through the work to easily understand what was completed, added, or needs to still be done. A simple message such as, fixed linter errors or solved merge conflicts can go a long way.
Improvements As An Individual:
During Sprint #2, I was able to complete one issue individually and two issues with my team. My first issue was Get Inventory Backend Test Working in InventoryBackend. In Sprint #1, we had some issues with the Inventory System test pipeline. I wanted to really get that testing pipeline to work to continue progressing the project forward. This issue involved me creating a test-runner file, along with an automated_testing_docker-compose.yaml file to integrate into the project. I also communicated with other groups for what they were completing to then integrate our work together and have the testing pipeline run and pass. My second and third issues were completed with my team. This being Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages in the GuestInfoBackend, and Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages in the GuestInfoAPI. These issues involved adding and enabling the different linters in our system and testing their respective pipelines to ensure they passed. If they didn’t pass, we needed to go into their specific files to make changes and correct the issues. In regards to improvements as an individual, I’d like to see myself become more of a team player for our last sprint. Sometimes I tend to get so focused on fixing and completing one issue that I forget to check in with the needs of the rest of the team. For me, this could be jumping in to help someone that’s stuck on a specific issue, reviewing the team’s work and providing feedback, and even voicing my thoughts, interests, or opinions more to my team. By doing so, I believe it’ll help me grow as an individual and a teammate, and help me tremendously with my professional career.
-
Expand Your Bandwidth, Expand Your Mind
In the fast paced Software Development field, staying ahead is not just advantageous but essential. Yet, many of us tend to find ourselves stuck in a rut, focused solely on the task at hand and neglecting the broader landscape of knowledge and innovation. The Expand Your Bandwidth pattern emphasizes the importance of continually expanding our knowledge and skills beyond just the day to day tasks we complete. Additionally, the importance of actively seeking out new information and participating in various learning opportunities to help accelerate our professional growth.
What I found particularly interesting regarding the pattern is the notion that we all want to achieve mastery following the long road, but achieving that mastery level is more than just mastering a specific technique or technology, but rather about cultivating a broad and adaptable skill set. The pattern also presents an analogy for learning through a straw and a fire hose. By immersing ourselves in a fire hose of information, while it may be overwhelming, is incredibly empowering. Therefore challenging the notion of compliance and encouraging us to continually learn, explore, and experiment.
After reading more about this pattern, it has changed the way I think about my approach to learning and professional growth. Previously, I tended to focus solely on completing immediate tasks, projects, and work, ignoring the broader landscape of knowledge and innovation. However, this pattern has inspired me to adopt a more expansive mindset and go out of the box to seek different opportunities for learning and growth.
While I embrace the message from this pattern, I do think it is important to limit how much information we try taking in all at once. If we don’t manage all the information properly or carefully, it could lead to an information overload and overwhelm or stress us out.
With this being said, the Expand Your Bandwidth pattern helps serve as a powerful reminder of the always changing and evolving field and the importance of continually trying to learn more and more to increase our skillset. By embracing this pattern, I am confident that I will not only enhance my skills as a developer but also create a mindset of lifelong learning and adaptation, which is essential for success in our dynamic field.
-
Success Begins By Sweeping The Floor
In the Software Development industry, every journey begins with a step forward and is often in the form of menial tasks. The Sweeping the Floor pattern emphasizes the importance of starting off small and embracing humbling tasks as a newcomer to a team. This means volunteering to do simple yet essential tasks to help contribute to the team’s overall success and grow as a developer. These tasks may not seem as exciting, but they help form the backbone of the team and provide valuable learning opportunities.
While learning more about the pattern, I found myself reflecting on my own experiences. This pattern brings up the idea that we should try to tackle not just simple tasks, but challenging ones as well. This helped me realize that regardless what our level of knowledge is, every contribution matters and serves as a stepping stone towards future accomplishments.
In a field that is often associated with complexity and innovation, I found it interesting for a pattern to highlight the importance of starting from the ground up and acknowledging that mastery is a journey that comes with time, rather than a destination. Also, by taking on tasks within our teams, we are gaining additional knowledge. The patterns focus on filling knowledge gaps through hands-on experience and learning underscores the importance of practical learning in the field.
Sweeping the Floor has led me to reevaluate my approach to the field. While I have always recognized the importance of continuous learning, this pattern has reinforced the idea that no task is beneath us as craftsmen and apprentices. This helped inspire me to contribute more to any team I’m on, even if it means taking on some of the more challenging tasks.
While I agree with the message of the pattern, I believe there’s a fine line between taking on humbling tasks and being pigeonholed into a role with limited growth potential. I believe it is essential to seek opportunities for growth and development beyond just menial tasks. While Sweeping the Floor is a part of the apprenticeship journey, it’s also crucial to strike a balance and demonstrate knowledge for more significant challenges and roles within a team.
With this being said, the Sweeping the Floor pattern can serve as a reminder that with dedication and continuous learning, we can follow our own paths to mastery. By embracing the humbling tasks from the beginning rather than pushing them away, and reaching for various opportunities for growth, we as apprentices can then lay a solid foundation that’ll set us up for success in the future.
-
The Importance of Finding Mentors
Beginning a journey in the Software Development field is like walking through a maze. Every turn presents different challenges, different opportunities, and different outcomes. Having a mentor can be the guiding light that we need through our journeys. The Finding Mentors pattern underscores the importance of seeking out help and assistance from experienced individuals who can provide both support and guidance while navigating the complexities of the field.
Reflecting on my own experiences, having a mentor can have quite a profound impact on shaping skills, gaining knowledge, and viewing things from different perspectives. I’m yet to experience this within my software development journey, but experienced it on numerous occasions with my athletic career where I was coached by a number of professional athletes. This in turn enhanced my skills and knowledge and resulted in me becoming a better overall player and athlete. I would assume the same would happen within the development field. Having a mentor would overall increase our knowledge and skillset, allowing us to further walk down our professional journeys.
What I found particularly interesting about this pattern was the emphasis on the give and take nature of mentorship. While apprentices seek guidance from experienced individuals, they then also have the opportunity to mentor others. This creates a culture of continuous learning and collaboration within the software development community as a whole. Additionally, the pattern has reinforced the notion that mastery can be achieved through the guidance and mentorship of individuals who have already walked the path we are trying to take. This allows us to take a step further in our learning journey. Therefore, this has prompted me to actively seek out mentors and engage more proactively within the development community to accelerate my personal learning and growth.
Additionally, while having a mentor can be an extreme plus in our own personal development, we should acknowledge that finding mentors can be challenging. This is due to the fact that some individuals may lack access to established networks or communities. In this case, we can look into alternative approaches to finding a mentor through online platforms or peer-to-peer mentorship programs.
Therefore, the Finding Mentors pattern can serve as a guiding light for us as aspiring craftsman, utilizing the power of mentorship in our professional development. By embracing the core message outlined within the pattern and seeking out mentorship opportunities, apprentices can then navigate through the complexities of software development with purpose and confidence, while also growing and learning for their professional career.
-
Walking The Long Road To Mastery
In our modern world, the journey to mastery is often overlooked in the software development field. Traditional notions of career advancement can cloud our vision as aspiring programmers, leading us away from the path of true craftsmanship. The Long Road pattern is a reflection on our journey of becoming masters in the field and emphasizes the importance of lifelong learning and growth.
Reflecting on The Long Road pattern, I found myself in agreement with its core message, while also grappling with the implications it holds for my own career path. The pattern’s emphasis on mastery as a lifelong journey stood out to me, serving as a reminder of the importance of patience and persistence in the pursuit of excellence and success.
The pattern also presents an analogy to martial artists attempting to receive the black belt and connecting it to software development. This highlighted the discipline, patience, and perseverance required to master any craft. Additionally, we should embrace our path, rather than just fixating on the destination. This reminded me that we should appreciate the process of learning and growth, rather than being solely focused on achieving immediate success.
The Long Road has challenged me to essentially reassess my approach in the field. Instead of chasing after quick promotions or higher paying positions, I now see value in prioritizing long-term growth and development, and measuring progress based on understanding and my quality of work. Therefore, encouraging me to adopt a more patient and deliberate approach to my career, knowing that mastery is a process that’ll unfold over time.
While I agree with the message expressed in the pattern, I couldn’t help but wrestle its implications with our rapidly changing industry. Today, new languages, methodologies, and frameworks evolve and emerge by the daily. The notion of dedicating a lifetime to master a single craft could seem unreasonable. While I value the importance of patience in honing my skills, I believe there is merit in adaptability and versatility. As developers, we must remain agile and responsive to change, continuously evolving our skill set to meet the demands of the evolving industry. Therefore, while I understand the message, I believe it’s equally important to embrace flexibility in our journey.
This pattern has left a mark on my perspective as an aspiring craftsman. It has challenged me to embrace this journey of mastery with patience and perseverance, even when faced with uncertainty. As I continue to grow and walk down this path, I am committed to the principles of lifelong learning and growth, knowing that eventually reaching true mastery is a destination worth striving for.
-
Sprint #1 Retrospective
What Worked Well And What Didn’t:
After completing our first sprint and conducting our retrospective meeting, I would say that sprint #1 went really well. As a group, we were given three weeks to complete a total of thirteen different tasks for a total weight of 25, and only fell short of one for a total weight of 20 out of 25. What worked well with the team was that we all knew each other, allowing us to be comfortable with asking different questions or for assistance. Additionally, we were able to schedule weekly meetings whether virtually through Discord or in person. These meetings allowed everyone to be informed about project progress, issues, and next steps. Communication was a major successor for this sprint, further accelerating our knowledge within the project. For what didn’t work well, our timing of working on the project was slightly off. We gradually contributed but didn’t get the ball moving until the end of our sprint. I could understand this as some of us were unfamiliar with the functionality of GitLab and GitPod, and what was completed in the project. For the next sprint, working on the project little by little right when we start and understanding what we are dealing with, will provide us time to discover issues, figure out how to handle them, and complete our tasks in a timely fashion. Additionally, we should consider having a better review process to ensure everyone gets to review work.Improvements As A Team:
To improve as a team, it would be great to further improve our communication. On days that we don’t have scheduled meetings, possibly posting an update on what everyone is currently completing, any problems they have, if someone needs something reviewed, and if they need help from another person on the team that may have knowledge on what they are working on could be beneficial. Also I believe we should begin working on our issues from the start rather than stressing and cramming everything all at once at the end of the sprint. We should also implement a better reviewing process.Improvements As An Individual:
As someone who had just stepped into the project, I was unfamiliar with navigating through GitLab to find different things, what was completed within the project, and what needs to be worked on. After researching different things and searching through various repositories, I was able to figure this out. I was able to complete three issues individually and one issue as a group particularly working within the InventorySystem of the Theas Pantry project. My first issue was GitPod Dev Environment in InventorySystem/General. This involved having the Theas Pantry project work with VSCode in GitPod, rather than devcontainers. The second issue I completed was also GitPod Dev Environment in InventorySystem/InventoryAPI. I completed the same work to have VSCode work in GitPod rather than in devcontainers. My third issue was Move From ‘commands’ to ‘bin’ in InventorySystem/InventoryBackend. This issue involved changing the file name from commands to bin, updating all script paths to use bin, and ensuring pipeline stages like build, test, and release all functioned properly. I ran into an issue with the test pipeline for this specific task as files were missing. To correct this, I had to disable the test pipeline and plan on fixing this in the next sprint. The last issue I worked on was with my group, GitPod Dev Environment in InventorySystem/Documentation. We completed the same work to have VSCode work in GitPod rather than in devcontainers. To improve as an individual in future sprints, I would like to complete a little bit of work each day, rather than trying to just complete as much as I possibly can all at once. I spent a lot of time working on my issues and when something didn’t work, I’d burn myself out trying to figure out what the problem was. In future sprints, completing issues piece by piece can allow me to have a fresh mindset each time I work on the project and complete tasks in a faster, more efficient manner. Additionally, by completing a little bit each day, it can take away stress from time constraints and allow me to ask questions, get reviews, make changes, and improve the quality of my work. -
Building Your Toolkit With Concrete Skills
The Concrete Skills pattern emphasizes the importance of acquiring practical, demonstrable, concrete skills in the Software Development field. By possessing the ability to complete simple tasks such as building files and having a familiarity with popular frameworks, can allow for an immediate contribution to any team. Additionally, this pattern highlights the need to go beyond theoretical knowledge and focus on building skills that can immediately be applied from day one on any team.
As I navigate through my path in the software development field, this pattern resonated with me as it aligns with my belief in the value of hands-on experience and practical application. What I found particularly interesting was the challenges that new developers come across when trying to join a new team. I feel as if every new developer goes through this as new teams may be uncertain of what knowledge you possess and what skills you can particularly contribute to the team. These teams may not want to take a chance on someone who is new in the field and may lack certain abilities. Therefore, highlighting the need for new developers to essentially bridge this gap by having concrete skills. This approach can not only enhance employability, but can also create a sense of confidence and credibility within the industry.
After learning more about this pattern, it has reinforced my belief in the value of continuous learning and skill development. It has motivated me to identify what skills are in demand for my desired position on a team, build those skills, and then directly apply them. From this, I can learn what skills I may lack, enhance my knowledge, and then contribute to my team in a positive way. Instead of relying solely on academic credentials or generic experiences, I now understand the importance of creating a portfolio of achievements or accomplishments that can effectively showcase my capabilities to potential employers.
While I completely agree with the message of the pattern, I believe that we should balance concrete skills with other soft skills like communication and adaptability. With that being said, I believe by having an approach that encompasses both technical skills along with interpersonal soft skills can be key in our ever growing field.
In conclusion, the Concrete Skills pattern can serve as a guiding light for aspiring developers. By embracing this pattern, anyone can make powerful contributions to their teams as well as pave a pathway for success in the foreseeable future.
-
Embracing The White Belt Mentality
As software developers, we are on a quest for both personal and professional growth, but there comes a time where we reach a plateau. We’ve mastered some skills and embraced pride in our knowledge, but despite what we’ve accomplished, there’s a fear that our development is at a standstill. The White Belt Pattern involves taking a new approach to this challenge. This involves possessing a beginners mindset and setting aside previous knowledge in order to learn and understand new knowledge.
I found the concept of the White Belt mentality to be extremely intriguing. In our modern world where new techniques and technologies evolve daily, we would figure that expertise and mastery would be most important and the idea of embracing a beginners mindset may feel counterintuitive. However, there’s always something new to learn and we should approach these situations with an open mindset.
Learning more about this pattern allowed me to reevaluate my approach to the software development field. In a field where continuous learning and adaptation are essential, I now understand the importance of just taking a step back to avoid becoming complacent with my knowledge and open to new perspectives and ideas. I love programming in Java and Python, but if I focus on mastering those two languages, then I wouldn’t be able to learn other languages like C or JavaScript.
One part that resonated with me was the emphasis on collaboration. By acknowledging that we don’t have all the answers and can’t solve every problem, creates a space for collaboration and problem solving. Therefore by having the White Belt mentality, we can create a deeper connection with individuals in our workspace, while also possessing a genuine desire to learn new things.
A challenging aspect regarding this pattern is the idea of stepping back for growth. I understand we should challenge our knowledge, but believe there’s also value in building upon our existing knowledge. Instead of disregarding what we’ve mastered, we should find a midpoint where we can learn new things and see different perspectives while still utilizing our previous successes.
Overall, the White Belt mentality allowed me to reevaluate my approach to personal learning and growth. Instead of viewing mastery as a destination, I now see it as a continuous lifelong journey with plenty of opportunities for learning and discovery along the way.
-
Subscribe
Subscribed
Already have a WordPress.com account? Log in now.
Conner Moniz Blog 