Practice, Practice, Practice…

The authors of the Apprenticeship Patterns book do an amazing job of capturing my attention. The opening quote that the “Practice, practice, practice” pattern starts off with demanded that I pay attention to what comes next.

“People we know as masters don’t devote themselves to their particular skill just to get better at it. The truth is, they love to practice—“

When I read this quote part of me shimmers with hope because of the proper guidance I was just given to help make it in my future, and another part of me frets because practicing can be difficult and I don’t want to struggle or face the hardship of practicing. Now my issue with practice isn’t that it can be difficult, I don’t mind taking on a challenge. My issue with practice is that I don’t want to be practicing but doing it completely wrong and then feel like I have been wasting my time. The way I picture it is like doing a bunch of push ups but the entire time you’ve been doing them your back was “U-shaped”. You don’t know any better until someone comes along and tells you that you’ve been doing it wrong the whole time. Meanwhile you’ve “mastered” the U-shaped push up but in reality there is no such thing. All the arm strength and muscle memory you built to do that unrecognized form of exercise was for naught, and that’s how I feel I might end up when practicing alone. The pattern does recommend practicing in public places, doing “kata” or finding a coding dojo to code amongst others and have these flaws pointed out as you practice. This sounds like something that would cause my nightmare scenario to never happen but there comes this slight embarrassment when thinking about asking for help or making a mistake in front of others… I suppose it’s a small price you pay while getting better. After all, its better than the former scenario. An old manager of mine once said something to me that still sticks with me today “If you ask once, you’ll only feel dumb once. But if you never ask, you’ll feel dumb forever”. Perhaps I should do more than just think about the profound words and apply them.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

Chapter 4: Accurate Self Assesment

I need to continuously improve my skills as a Software Developer. What can I do to make sure I am taking advantage of every learning opportunity? This chapter provided more perspectives to me on the environment of interacting with my current and future colleagues.  If I am hired to develop software, I will then be responsible to develop software. It can seem daunting, but it shouldn’t be. This chapter helped me better my perception of a future in the workplace. If I am hired and on a team of developers that are far more skilled than me, I can’t be afraid. I need to be excited and ready to learn. This chapter helped me realize that this will be the best time for me. The best-case scenario is that I am the worst programmer on the team. That is because that will be when I learn the absolute most. If the time is put in and the gears in the brain are moving, I will be a sponge absorbing information. Further crafting and homing in my programming skills. If I am not as good, it is no big deal. I will just have to put in more effort. It is as simple as that. It would be an enormous opportunity to be around world class coders. If my colleagues are extremely far ahead of my learning curve, I must take advantage and put more time in to learn from them. The chapter helped me see this type of mindset. I also enjoyed that the chapter included a small story about two programmers who did not work together but were friends. They shared many of their experiences, learnings, and passions. This allowed them to even further better themselves. They weren’t talking about work related topics. They were just bonding over their passion for their industries. And it further developed their journey down the road. Which I completely agree with. I think these types of relationships will always be extremely important in any type of skill you wish to perfect. But for our case of a future in programming? This is a different beast. These types of friends, coworkers, mentors will all be vital to the process of growing and getting better at what we do.

From the blog CS-WSU – Andrew Sychtysz Software Developer by Andrew Sychtysz and used with permission of the author. All other rights reserved by the author.

Craft over Art

It is important to create things beyond that what is expected. You should go above and beyond the specifications of the application and create something that will wow the product owner.

I think it’s interesting to look at software development as craftsmanship and what you create as art. I do think that programming is a form of art because you have to use your creativity to make anything that you produce. Being artistic is a good way to look at creating an application, especially one with a user interface because it is what people will be looking at whenever they interact with the software. You want something to look beautiful and appealing just like a piece of artwork. In my opinion, someone would be more likely to use attractive-looking software than one that is unappealing to the eyes. It’s also important to make something that’s easy to navigate because that enhances the user experience.

I typically try to go above and beyond in the project that I’m working on. It is good for personal growth and reflects well on my portfolio. It is nice to be able to show a future client past work and be proud of the artistic design element of what I created. I prefer working on the backend, but I do enjoy creating a nice UI that users enjoy interacting with.

I think it is important to put extra time and effort into the products that you are creating for your clients. However, I think it’s important to not get lost in the details of creating something more than they asked for. Sometimes it’s possible to add features and create things that the client might not want and then you are forced to remove them. There are other times where you might put in extra work, and you were taking time away from yourself for other projects that need attention. Even though it’s good to have just to have the learning experience, I think it’s also important to make sure that projects for clients, that you put in extra effort into, should get some form of acknowledgment.

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

Sprint Retrospective 2

By this sprint, everyone had an idea of what they were doing and what needed to be done. So everyone was on track with required workflow. In this sprint, people started to add issues of their own. I should have added issues I found in this project, but I just discussed with the team members, and they added it. Overall, for this sprint, I have a mixed feeling about it. I felt as if I didn’t do much help to the team, but at the same time I felt like I gave my all to the team. I did solve a couple issues during this sprint.

The first issue I solved was simple enough that I forgot to add it to the project issue board. Logically, it made sense to fix this issue so that the form doesn’t become annoying to the user. Imagine clicking on the input field every time the form loaded. So guest 1 comes and swipes, guest 2 comes then you have to click on the input field, guest 3 comes click again. Doing that over and over again would have been exhausting. I didn’t really notice this issue until I tested the code with card reader. At first, I thought I had to write some method so that the text would automatically focus on the input field. I was lost and had no idea about how to make it work. At the end, I felt really stupid because the solution was simple, and I was overthinking it. The solution was in the HTML input attribute type. All I had to add was “autofill” in the input attribute. Refer to this commit. Here

For the second issue I fixed, it really took the best of me and my time. My goal was to on a click of a button which is in one of the child component in Vue, I had to get the data from localhost, store it as an object then pass it to another child component so that those data would automatically fill the form. Sounds simple and easy. But the thing is, you cannot pass data from one child component to another. So the process was to get data from one child component, pass it to parent component using emit and then pass that data to another child component from parent component using props. Michale had already passed the data from component to component and I thought it would be relatively be the same. I couldn’t be any more wrong. I did everything same as Michale and everything worked as we wanted. Since our API was not fully done, I tested my method using Jsonplaceholder and sent the data to another component. I put the Jsonplaceholder’s ID number as a zip code, and it displayed as I wanted it to be. The major problem was that I was using options:Lifecycle that would assign the data before the form loads, which leads to not being able to edit the form data. Removing the lifecycle and just mounting it to v-model worked, but it rendered the first child component twice in the same page. Other than that, everything was working. I was able to get the data, pass to the form and edit then submit the edited data. I am not really sure how this worked, but to fix the issue of rendering the component twice, I hid the first component when the submit button is clicked. After that, everything worked as we wanted. Refer to this commit for code details. here

On to the third issue, when swiping the card, the input field only picked up the correct ID on the first swipe only. This issue was taken by another teammate, but since he wasn’t able to complete it, I took it from there. After a couple of hours of debugging, I was left with nothing. I understood the code the previous developers left, but I wasn’t sure why the issue was as it is. I started to think that if it worked on first swipe, let’s make every swipe as first one. So the solution was simple. Refer to this commit on line 93. here

This Sprint showed who is really dedicated to the project, who is really passionate to the software developing. It seemed as everyone was giving their 100% effort to the project and were all liking the process. I don’t have a single doubt that we won’t be able to finish this by the end.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective #2

During this sprint, we worked on a new back end since the old back-end version did not work as expected. So rather than focusing on fixing and developing from the old back end. One of our team members suggested that developing an entirely new back end would help save more time and effort for the team.

The back end ended up working properly and T (one of our team members) played an important role during this sprint. She amazed us with the progress that she had made during this sprint. The other teammates were also able to contribute with the same efforts and knowledge.

Besides building a new back end during this sprint, we also developed Unit Test using chai. The test was up and running. However, we did not see much of the result from the test due to the lack of input. We also think that this issue contributed to the failure of the test itself.

We had been able to fix a couple of issues that we had from the last sprint about communication. However, there were other issues that I believe we did not make good efforts. The communication between team members was still behind compared to other teams. We did not anticipate well enough in making decisions and exchanging ideas on Gitlab. Also, this sprint had seen a step back in communication via Discord as well. From what we had seen during this sprint was the work was distributed unevenly. This meant that T was devoting and contributing most of her time building the new back end without much help from our team members. That was also a setback with the first sprint.

For the next sprint, we need to make substantial changes in communicating and distributing the work. As a team, communication is a key essential, therefore the team would not function well without the right key. To help the team succeed, we need to work on our communication. As I have mentioned in the last sprint, the problem was repeated during this sprint. The work was not divided evenly which led to someone having ended up doing more work than the others. With that being said, team members need to put in efforts to offer help without being asked to do. For better team communication, we ought to learn to use the tools at our disposal such as Discord. Everyone would need to develop the perception of helping and offering hands if needed and the person who was doing most of the work as well needs to learn to share work with others.    

In this sprint, I was responsible for building a unit testing system. However, the task was much more work for one person than I thought. I should have asked my team to help me with the development and building. I also did not do good with time management. I crammed my work during the end of the sprint which led to the work was not satisfied. The result might be the same but the amount of work that I put in would be more effective without stressing me out excessively.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/26

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/19

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

Week 9: Sweep The Floor

For this week, I chose to read the pattern ‘Sweep the Floor’ from Chapter 4: Accurate Self Assessment. This chapter is on, as you can read from the name of the chapter, accurate self assessment. I did another pattern from this chapter not too long ago but I think this chapter is easily the most relatable for me at least. For this pattern, the context of it is that you are a new apprentice on a project. I chose this because I could relate this back to when we were first starting our group projects and getting into our teams. It was a foreign experience to me since I hadn’t had an internship yet or anything of the sort. For the problem of the pattern, it revolves around you being unsure of your place on the team and the team is unsure of you. This was relatable to when we first started, we didn’t know each other and our work flows. Luckily, we were doing Scrum so we had a leader basically ease us into things. Additionally, the problem also is wishing to find a means of contributing to the team’s work, earning the team’s trust and growing as a craftsman.

For the solution, it followed the same approach as most of the solutions in this chapter were. Pushing yourself to do tasks in order to grow as a craftsman. With this pattern, the solution was to volunteer for simple, unglamorous tasks. This is ‘sweeping the floor.’ Doing tasks that are mandatory to the program’s success such as maintenance reports, bug fixing, code review, etc. I thought this was interesting because my approach to getting trust from a team is doing the hard work first in order to show I know what I’m doing and to show that I won’t let them down. However, this approach seems more personable than my approach and much simpler, on paper, as well. This solution does come with caveats though, as mentioned in the solution. One problem is you may become the team’s gopher, this means being condemned to doing menial tasks no one else will do. I, for one, don’t think that’s a big problem but I guess it depends on the person and their ambitions. Another problem is that you may find yourself intimidated by doing anything other than sweeping the floor. I can kind of understand where this point of view comes from but for me, I don’t think it would be much of an issue transitioning between hard tasks to relatively simple, menial tasks.

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

“Draw Your Own Map”

Jennifer Gayle once said “You are the author and writer of your own story. Turn the page, start anew, and make sure it is a story worth telling”. In life, we have an open road that we are set upon. Sometimes there are factors that narrows that path. Upon reading Draw your own map, it has explained that we are not to be limited from outside factors. Such as a company with their own set expectations that conflicts on what you are interested in instead therefore, we must be more open to search for more opportunities. That it is alright to make modifications to our own maps to further gain motivation and values. 

I enjoyed the section of the solution for this matter; it piqued my interest where we must take the first step to make a motion forward. Even though it may be terrifying, but we must be willing and determined to walk forward. I also aggreged that we do not have make big goals that are broad but instead make smaller ones that can be achievable. This way we can make further adjustments to our map. It would not hurt to make bigger goals for long term but to break them down into small goals to conquer those bigger goals. There was not any part of the pattern I disliked as I believed this is very useful information. 

Using this pattern towards my life and career will be deeply considered when I go into the software development profession. To always remember that I can find many other opportunities that aligns with my interest of what I am looking for. And if it ever comes to fall out of place from my map that I will branch out my path even further to keep the love and interest I am intended to keep on going. Understanding that after having to trying out a new path and having a new set of values is essential to our mindset. To keep in mind that we ask ourselves is it worth it? Could this step hinder our truest potential? That is why we must keep expanding our choices and chose whichever is best in one’s interest.

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

“The Long Road” Apprenticeship Pattern

Summary:

This apprenticeship pattern concerns the long term journey that a programmer / developer will take throughout his or her lifetime. In a society that continuously values decadence, it’s important to find a path that is right for you, no matter how weird or seemingly unusual it may be. As we gain experience as programmers and developers, there will be temptation to mindlessly progress down the path of greater income and short term gain. Instead, this pattern is for those who aspire to progress down a fruitful path in software development, gaining experience in a lifelong career.

What I find most thought provoking about this pattern is the prospect of leaving the field of programming permanently to go down another field of salesmanship or to a high ranking position in a corporation. Software development to me is a very intricate and professional field that requires a lot of research, experience, and experimentation. Someone who progresses far enough into the field only for them to change directions because of their experience seems somewhat confused to me. On the other hand, it at least makes some sense as someone who has a lot of experience in software development can have a lot more skill as a business owner or a salesman in selling software, and recognizing development cycles for a product.

This pattern has indeed somewhat caused me to change my view of my future. I knew that within the software profession there were many different ways that one could go, and that we would need to be experienced with different tools if we needed to create a competent product. I wasn’t sure, however, of the potential of an opportunity arising to shift to a different career

I generally agree with this pattern. The part I agree the most is on the matter of strange roles that one may possibly find himself in in the future. Personally, my work and perspective on planning my future took a drastic turn almost a year ago, where I actively tried to search for a career as a programmer based on the tools that I already knew. Then, I found out that it’s better to learn and gain experience with new things that I don’t know, based on the demands of a job and the industry.

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

Apprenticeship Pattern: The Long Road

This week I decided to take a look at ‘The Long Road’ apprenticeship pattern that covers the expectations and the reality of becoming a software craftsman. The pattern begins by explaining that society expects immediate results without really thinking about the journey. Usually one would aspire to take the highest-paying job and the first promotion as opposed to building up your skills. The pattern encourages you to value learning and long-term growth over salary and leadership positions. Keeping a long term goal in mind allows you to hone your skills as you work towards it. Of course this pattern is not for everyone, the long road is just one of many that a software developer can take on their journey.

Reflecting on what I read in the pattern, it is certainly more realistic to set a long term goal as opposed to trying to go for the high paying jobs immediately. I am definitely guilty of having the desire for overnight success. I agree that the biggest factor for this would be today’s culture and as well as my family’s expectations of me. But when it comes to software craftsmanship, I would like to spend more time accumulating knowledge instead of settling down and potentially stop improving. The only statement that stuck with me was, “Along the way, it is not unlikely that you will take on roles of power and responsibility or find yourself quite wealthy. However, these roles and benefits are not the main motivation of the successful apprentice—they are merely by-products of a lifelong journey.” I would say that I would probably not be ready for an executive job or being a team leader, but I can’t deny that money is one of the bigger motivators when it comes to working. That being said, you always have to start from somewhere, and I have much to learn. This pattern is more so a reminder for me to take the time to improve my skills and success and money will come after.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Blog 1: Expose Your Ignorance

This pattern is about shedding light to dark or unknow spaces of a craftsman knowledge. The context and problem given are that the people who are paying you to be a software developer are depending on you to know what you’re doing, and your managers and team members need confidence that you can deliver, but you are unfamiliar with some of the required technologies. The solution suggested is to show the people who are depending on you that the learning process is part of delivering software and to let them see you grow. The book also mentions how hard it is to practice it because it is scientifically proven that the need to appear competent is ingrained in most people. That being said, there is no need to hide an area of ignorance because one of the most important traits that a craftsman can possess is the ability to learn, identifying an area of ignorance and working to reduce it.

I can absolutely relate to the context given in this pattern because it’s quite frankly where I am currently at. As I am navigating working my first “real” jobs, I quickly realized that I do have many zones of ignorance and it is extremely difficult to just lay them out because there is a lot of pressure to deliver what I have been hired for. Reading this has definitely reassured me in knowing that most people feel the same. The pattern suggests asking questions as a way to expose one’s ignorance and I have really found that to be true. Often, I would just go straight to google, stackOverflow or any similar website when I was presented with unfamiliar material or when I didn’t know how to approach a task and I would ask question after I ran out of ways. I have then realized that it should be the other way around because hearing from the employer/client and asking the right questions first made my tasks easier to achieve. I found interesting the emphasis they added on expertise not being the destination but being a by-product of the long road we’re all on. It just means that with time and some practice you get the extra knowledge that make one an expert at something.

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