Author Archives: John Pacheco

LibreFoodPantry Sprint 2 Retrospective: Controllable and Uncontrollable Variables

Here is what I worked on during this sprint:

Sprint Reflection:

It has been so long since the onset of this sprint that it is somewhat hard to remember how it even started. What I do remember is that coming into this sprint, my team and I were determined to get more work done than in the previous sprint. It looked like it would have been relatively easy since we had a longer sprint this time and our collaboration had improved greatly since the start of sprint 1. The start of the sprint proceeded smoothly and I took some intro to UI design courses to get the mock UI done within the first couple days of the sprint. We acknowledged that more work had been proposed for this sprint, but we had more time to get it done and I was confident that I would have the time over spring break to get both frontends completed. I think up to the point where all residents on campus had to move out because of the danger of COVID-19, I think my team’s communication between each other and planning was much better than the previous sprint. Issues on our board were much more granular and detailed and all of them were linked to the proper Epics and had the proper tags. I think all members of the team started to take the Scrum practices more seriously and it showed in our organization and communication.

This is when all of the uncontrollable variables of life hit us like a truck. All of the stress and changes in dealing with a worldwide pandemic definitely took a toll on my productivity. Rather than spend this whole retrospective talking about how COVID-19 ruined my plans for getting the frontends completed, I’ll talk about how we could have better prepared for this situation. Spring break was extended by two weeks and there was nearly a month without communication between our team. Over this time I felt uncomfortable asking for help or clarification about issues I was having with my team since I had no idea what anyone was going through. I decided it would be best to hold off on development until classes started up to give all members of the team time to adapt to the fully remote life that we are now living. While this is an extreme case, I think this is a good lesson in accurately weighing tasks as well as not adding too much work to a sprint. While creating issues I think my team and I fell victim to weighing everything using a “best-case scenario” approach. All of the weights created reflected the time it would take for us to complete a task if nearly nothing went wrong. As a software developer, I should have known that failure is expected and every task will almost always take longer than you think. Next time weights will reflect the reality that things go wrong so we can more accurately fill up our sprint with tasks. When determining what we would put in the sprint we were taking into account the time we’d have over spring break. This meant to get all of the work done for the sprint we’d have to put in a good amount of effort over the break. The misjudging of weights combined with this meant that an event as serious as coronavirus caused us to miss our sprint deadline for a lot of the frontend work.

Going Forward:

As an individual, I will be more responsible and truthful when weighing tasks. I will also communicate with my team and other teams as soon as problems arise so we can resolve any issues I am having as soon as possible. As a team, I think the place we could improve the most in is reviewing completed work. Allowing merge requests to pile up on GitLab causes development to slow down until those get merged. We decided to try and keep our “Needs Review” column to two issues at all times, but this was not enforced as much as it should be.

From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern Review 8: Find Mentors

The “Find Mentors” pattern from Apprenticeship Patterns by Oshineye and Hoover is one that has relevance no matter how far along on your software craftsman journey you are. Whether you are opening an IDE for the first time or are a seasoned veteran who has contributed endless amounts of knowledge to the field of software development, it is important to seek and learn from those who’ve been through the trials and tribulations that you have yet to face. There is a stereotype that programmers are these hermit-like creatures that rarely see the light of day and seldom speak to other humans. In their dark caves, they churn out program after program in a vacuum-like environment. This is simply not the case and every single person who calls themselves a software developer can benefit from collaboration, specifically seeking out those who have already made the mistakes and can expedite the growing process for them.

All of the patterns that were carefully curated to appear in Apprenticeship Patterns have relevancy in practically all software developers’ professional careers. “Find Mentors” is no different as the knowledge that can be learned from a mentor can potentially be far greater than that learned alone because of the simple fact that they have walked the road and generally know the “path of least resistance” in their given field of expertise. This is why I feel this pattern is so important. Not only do mentors hold massive amounts of knowledge waiting to be tapped into for your benefit, having a mentor that you can show your work to can force you to hold yourself to much higher standards than otherwise. I think the realism the authors bring to the pattern when they explain that “no one knows everything” is important because it can be tempting to rely on a mentor too much and lose confidence in them when they don’t have an answer to a given problem. They are only human too, therefore they have gaps in their knowledge just like the rest of us. Note also that the mentors one needs throughout their career change and shifts just as much as one’s own knowledge does.

This pattern has made me desperately want to seek out people I can learn from who are further along in their careers. The benefit of having mentors to obtain guidance from is far greater than the fear of ridicule that has been generally holding me back from finding mentors that can help me excel in my career.

 

From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern Review 7: Sustainable Motivations

I feel like most people have been in this situation: you have passion for a hobby and decide that you want to take your craft to the next level. In doing so, a mountain of unforeseen stress and complications arise and at some point along the way you might even forget what motivated you to get to where you are in the first place. Sustainable motivations are important no matter what you are applying this pattern to. This pattern is especially important in the life of a software craftsman.

In an industry where it is all too easy to retreat into competence because the pay is “good enough”, it is easy to lose sight of the motivation that made you decide to devote your life to becoming a software developer. I can’t even describe the joy I felt as a sophomore in high school when I set out to make an, albeit shoddy, clicker game in JavaScript, and after slaving over the code for days I finally understood exactly how a game loop had to function in order to make the game playable. I proceeded to spend that weekend glued to my screen implementing all of the features I had only dreamed of days before, barely remembering to relieve myself periodically. It is that entering into a state of flow and  working through complex problems with the end result being something I created that made me fall in love with the craft. Sometimes I fall victim to forgetting what it is about programming that I love since it feels like I have been in school for a long time and the future in regards to employment and making ends meet is up in the air. To quote David Wood, “do what you love and the money will follow”. Making sure to never let your motivations become misguided is important into keeping energy and creativity levels as high as they can be.

An important distinction between motivations can be made. That is intrinsic versus extrinsic. The more intrinsic your motivations, meaning doing so because you find it personally rewarding, versus extrinsic motivations, doing so because you seek a reward, the more sustainable your motivations will be. I know I am extrinsically motivated by money and the desire to succeed for my family and teachers, and I am intrinsically motivated by the desire to create, the desire to increase the complexity of life, and the desire to solve problems. I find this pattern important because motivations truly change your outlook and mood when facing life. This pattern applies to everything in life and I think writing down motivations is a good exercise for my software development career and in life.

 

From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern Review 6: Concrete Skills

As I near the end of my college career I am giving more thought daily to what exactly I need to put forth to land my first job as a Software Engineer. Will companies value the fact that I am very creative minded and enjoy collaborating on projects or is are they only looking for the cold hard skills that I have gained over my years of study. The Concrete Skills pattern from Apprenticeship Patterns highlights the fact that, while soft skills are important, the ability to apply knowledge in order to provide value to the companies you are applying to is paramount. Why should a company take a risk on a candidate who doesn’t show that they have the skills the company needs when they can hire someone who does.

This pattern is all about identifying exactly what skills the job you want is looking for and gaining the skill. What may be even more important than learning the skill is building a project using that skill in order to prove your adequacy. While the ability to learn quickly is a great skill, having the foundational skills companies are looking for is important when searching for landing a job. It is important to research which skills are relevant to the positions you are applying for rather than trying to learn everything, since that is an impossible task.

I have recently started my job search and more and more I’m realizing the benefits of having projects that prove my competence in relevant skills for the jobs I am applying to. This pattern has made me realize that it would be a great idea to ask people in my network who are further on in their careers about what skills they put forward that helped them land a job. I can then use this list of skills I gather to slowly pad out my resume with projects that prove that I can provide value to the companies I am applying to. Since I am in my last semester I am pretty packed with coursework, but I am going to set out to learn at least one relevant skill every weekend. By the end of the school year my GitLab will be a place where all of my skills are shown off with well crafted, yet small in scope projects. Concrete Skills is a pattern that every software developer should read and implement because of the huge benefit that it gives you in your career as a Software Craftsman.

From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern Review 5: Craft over Art

I am not lying when I say I have been avoiding delving into this pattern from Apprenticeship Patterns, for fear that it would hit close to home. Upon reading “Craft over Art”, I’d argue that this pattern is full of more enlightening information than any I have discussed so far. Oh yeah, and it also hit very close to home.

The context for this pattern is very general, as it states that you are being paid to deliver working software to a customer. The pattern argues that delivering working, useful software is paramount to building some magnificent thing in order to display skill or artfulness. We are trying to become craftsman not artists, and while there is a time and place where making the most beautiful code and software is appropriate, a line must be drawn. As explained in the pattern, it is important that a bottom line for quality is determined and met at all times, even under pressure. It is important to note that the authors argue that “utility and beauty are not opposed, but interdependent.” This means that we have to constantly choose a balance of the two that work for any given situation, and this will change constantly.

As I am an extremely creative minded person I find myself often trying to create “art” when I am trying to deliver working software, especially when I am working on self-directed projects. I find myself working on all of the frivolous parts of a project, expending all of my energy on minimal functionality. The end result tends to be me giving up on self-directed projects because I get burnt out working on all of the bells and whistles, while minimal actual functionality is present. A conversation between me and an observer tends to go like this:  “Wow that looks awesome! But what does it do?,” the observer exclaims. “Nothing but it looks cool right??,” I say, sweating slightly. My point is historically I tend to put valuable functionality lower than fancy technology and fluff. After learning about the Agile principles and Scrum frameworks I have been getting much better at reflecting and making sure what I am working on is valuable to the customer.

This pattern is packed with information that I will continue to think about in my career. It is fun to have a romanticized idea of what being a software craftsman is, but at the end of the day the most important thing is that utility is what I’m getting paid for.

From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective: Trial by Fire

Last week our team concluded our first sprint working on the Approve Guest module for the LibreFoodPantry project. This project is part of my Software Development Capstone and has us working on an open source project using Agile principles and the Scrum framework for software development. While I think the project has been going well, there are definitely aspects of our workflow that can be refactored in order to increase our productivity.

What I Completed This Sprint:


For this sprint I took the role of Scrum Master for my team of four. I felt like this would be a great way to put my knowledge of the Scrum framework into practice. While I tried to make sure I was available to the team to answer any questions about Scrum, I feel like I didn’t emphasize the importance of following the scrum framework as well as I could have. I facilitated the stand-ups at the beginning of each class period as well as planning and review meetings. Our team did a good job of explaining what they had done prior to the stand-up and what they were going to work on, but the stand-ups were never used to raise questions about logistics or talk about progress towards meeting our Sprint goal. I feel this is because much of the Sprint was used for getting adjusted to the slightly more structured workflow that we are working with. If I continue to be Scrum Master for our team I will make sure that we utilize class time to the fullest in order to have open discussion about what we need to complete and how we can deliver working software as fast as possible while doing only the minimal amount of work necessary.

I think its important that, as a group, we start to utilize GitLab and our issue board to a greater extant than we did this Sprint. In the beginning of the Sprint we were having trouble coming up with what issues to work on because we didn’t have much information about exactly what it was we are building. I feel like not only our team, but all teams were very concerned with granular aspects of the project such as, what attributes should we be storing in our databases and what style guidelines should our applications use. All of the information that was up in the air was making it difficult for us to feel like we can start developing since everything is subject to change, but it is important for us to remember the Agile principle, “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage”. We should be building this expecting requirements to change, rather than feeling the need to wait until requirements are finalized to start working. Also, I feel like even though our communication with each other and the other teams improved greatly from the start of the Sprint, we should be communicating as much as possible in order to maximize our productivity. We had good discussion with other teams but left minimal evidence of this on GitLab, which is something that we will need to be more vigilant about in the future.

We were able to finish all issues in the Sprint before the end, which is a sign that we gave ourselves too little to work on. I think as a team we made an acceptable amount of progress this Sprint as it was our first ever sprint working as a team. Going forward we can more accurately gauge how long each issue will take us to complete and make sure each member of the team delivers a reasonable amount of work by the end of the Sprint. Reflecting on what I delivered this Sprint I know for a fact that next Sprint I will need to give myself more issues to work on. I wanted to start working on our actual web applications, but the fact that our requirements were vague made me decide maybe we could leave that for the next sprint. I think my own fear of the unknown had me making many spike issues, when we could have made greater progress on the application itself.

“Working software is the primary measure of progress.”

 

From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern Review 4: Retreat into Competence

When a software developer gets overwhelmed by the complexity of their current project or the fact that there is so much they don’t know, it is okay to “retreat into competence”. In the face of a challenge that seems insurmountable, taking a step back to see how for you’ve come and what you have accomplished is okay. While retreating into competence can be the right prescription for times like these, it is important to use the traction gained while retreating to propel yourself beyond where you first had stopped.

The title of this pattern almost seems contradictory to the whole concept of becoming a software craftsman. A software craftsman should always seek to move forward in their knowledge and career, why would the authors be telling us to retreat? While being able to continuously march forward indefinitely, steadily increasing project complexity and your responsibilities would be ideal, it almost never works like this in the real world. I find this pattern to be quite important, because without it, it seems that one would be going directly against the principles of a software craftsman to step back from a problem and retreat into competence.

One thing to note is I feel like it is especially easy to fall back on this pattern too much. If you consistently find yourself pressing the “eject” button whenever you reach a problem you might not know how to solve yet how will you ever go forward. It is important to set constraints on how long you can retreat in order to protect yourself from truly going against the principles of software craftsmanship and living a career filled with mediocrity. This is a powerful pattern, use it responsibly.

I feel like this pattern can be used in many situations in order to get over hurdles in one’s career that seem too great. Allowing yourself to create things you feel comfortable developing can help you regain faith in yourself and software development as a career. This is a pattern I have used myself and have seen great success with. When I find myself lost or over my head with a given problem, I like to solve small programming challenges, sometimes referred to as kata, in order to instill confidence in myself and remind myself how much I have improved over my career.

 

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern Review 3: Confront Your Ignorance

“Confront Your Ignorance” is another pattern that struck a chord with me from the Apprenticeship Patterns book. I chose to talk about this pattern now because of its strong relationship with the “Expose Your Ignorance” pattern which I talked about in a recent post. As a developer who is relatively early in their journey, I realize that there is some skill or tool that I should know that I may be unfamiliar with almost daily.

Confronting your ignorance is all about taking the list of skills and tools that one creates when exposing their ignorance and setting aside time to learn that skill. The approach with which one learns a given skill or tool is unique to the individual. The main goal of this pattern is to be able to confidently say that you understand how to implement a given skill or effectively use a tool after confronting that gap in your skill set. It is important to reflect often and decide, once you have reached satisfactory knowledge in an area, whether you should switch topics or delve deeper into the current one. If a developer does a great job of exposing their ignorance without ever confronting it they can never take the step to being a software craftsman. They will find comfort in their ignorance and rely on others to fill in the gaps. Conversely, if a developer always confronts their ignorance without exposing it, it creates a work environment where everyone pretends to have a skill and then learns it in hiding to appear adequate. This would be a bad application of this pattern and should be avoided as much as possible.

For myself, I find that my learning and application of a skill tend to go hand in hand. I find myself confronting my ignorance at the same time as trying to deliver a product which tends to end in frustration and a sense of failure. In employing this pattern I can save myself the frustration by setting aside time to toy with a tool and learn a skill. Inevitable failures when learning how to use a tool no longer equate to failures in being able to deliver a product. After reading “Confront Your Ignorance” I will immediately start to employ this pattern in daily life. I will expose my ignorance and then give myself the time to fill those gaps in my skill set.

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern Review 2: The Deep End

“The Deep End” is another extremely useful pattern taken from Apprenticeship PatternsThis pattern is best used when you feel as though you are stuck in a rut and not much progress is being made to further your software development career. In order to save yourself from a career of mediocrity something must be done. “The Deep End” prescribes the developer to set aside fear and jump into a project greater than anything they’ve done before. While this could end in failure, even failure is a better outcome than never starting in the first place since so much knowledge will be gained in the process. More often than not, it seems as though jumping into a project that seems too complex or too large when compared to previous work tends to be the best way to supercharge your learning.

I agree with this pattern wholeheartedly. I have already acquired countless examples in my relatively short career of software development where forgoing my fears and jumping into a project that I didn’t know I could complete helped me get out of a rut. One of the hardest things for me to remember is to keep jumping into “the deep end” whenever I can instead of getting into ruts of self doubt and fear. I also agree with Hoover and Oshineye that while this notion of “the deep end” is a key to becoming a software craftsman, one can not blindly jump into a project that is way beyond their comprehension and expect to swim. It is extremely important to take into consideration the prep work and skills at your disposal when deciding if an opportunity is right for you. While I do think the idea of recording the size of projects you have worked on could help when utilizing this pattern, I don’t think its necessary. Instead of getting bogged down by wondering if the project you want to work on is bigger or more complex than the last I think the most important thing is that you take the leap and start working on the projects that can propel your career forward.

This pattern will stick with me because I’ve seen it work in my own career previously, yet I’ve never had a concrete pattern to remind me of it. It will come in handy when I’m working on my capstone project. It’s imperative that I never let fear get the best of me and I instead choose to continue working through problems that I think there’s a possibility I fail at. I will keep this pattern close at all times and whenever I feel like declining an opportunity because of fear I will remind myself of “The Deep End”.

 

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern Review 1: Expose Your Ignorance

This blog is the first in a series of posts that will be covering software craftsmanship patterns I find compelling from Apprenticeship Patterns by Oshineye, Hoover. With these posts I aim to summarize the pattern and explain its relevance to me and software development as a whole.

In short, the “Expose Your Ignorance” pattern is aimed at dealing with a fundamental issue with people living in industrialized society. Software developers are under extreme pressure from managers and team members to know how to use many technologies. Especially in the case where those relying on you are under the impression that you understand how to do something, it can be extremely hard to make it clear that you actually don’t know how to do that something yet. Acknowledging the fact that there is a push to reassure everyone that you know everything and going directly against this is essential to learning as quickly as possible. This is the gist of “exposing your ignorance”.

I constantly feel the pressure to reassure my colleagues that I understand whatever it is we are talking about. I’ve always felt like doing otherwise would make me seem incompetent when in reality it is a sign of maturity. Immediately after reading this pattern I feel as though it made a fundamental shift in my approach to problems. It makes complete sense that mastering this pattern would yield great benefits throughout my career. “The most obvious way to expose your ignorance is to ask questions”(Oshineye,Hoover). Being able to ask questions whenever I am unsure of something can greatly abridge the time it takes me to learn a given skill. Also, in a world where we have near infinite knowledge at out fingertips at all times, I feel that a desire to learn is a much greater skill to possess than “knowing” a lot.

I find it very interesting that the authors make a distinction between software craftsman and experts. I agree that not being able to ask questions can shoehorn a developer into becoming really good at one skill, yet never branching out into others. I personally feel like being an expert rather than a craftsman can make a career in software development grow stale. Being able to nurture a desire to learn is important not only in the context of a software development career, but in everyday life as well. “Expose your ignorance” truly is a pattern that I feel will improve my career as a software developer.

 

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.