Confront Your Ignorance Pattern

For this week’s apprenticeship pattern, I did a reading on “Confront Your Ignorance”. Confront Your Ignorance is about how to start the process. What I mean by this is to pick a tool, skill, or technique and use it to fill in the gaps of your knowledge about it. Confront Your Ignorance is overcoming your lack of knowledge in an area and doing your best to learn more about it to become knowledgeable about it. This pattern ties close together with Expose Your Ignorance pattern. However, implementing this pattern is a bit more doable since it is less of a challenge on your pride since it can be done privately. Other solutions besides learning on your own would be to ask your mentors or anyone that you know that may already have the skill and is willing to share what they know.

My initial reaction after reading this pattern is that it is a reflection of what I am currently experiencing. I have mentioned before that I have limited experience in the professional field of software engineering, I am constantly trying to fill in any gaps of knowledge to make me more of an ideal candidate to companies compared to those who have multiple internships under their belt. The reading was quite interesting and very useful. Interesting because I can relate to what it is talking about and useful because it helps me with my current job hunt and figuring out ways to tackle this issue. Even before reading this pattern, I’ve been trying to find ways of attaining skills and knowledge that I haven’t gained before.

The pattern has not changed the way how I view my profession because I know going that transferring from school life to being a professional Software Engineer, there will be a gap of knowledge I won’t have. I know that I am going to be required to research and learn new things in my career. Therefore, I am constantly practicing my skills and working on side projects to help myself get a good grip on how each technology works and how to incorporate it in what I want to do with my professional career.

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

Unleash your Enthusiasm

Will you let your voice be silenced?

As a software developer, you will almost certainly be working as part of a team. The majority of teams are not overly enthusiastic about technology. There are risks in unleashing your enthusiasm on a well-established team. If you find yourself on a team that does not accept your enthusiasm, you must find ways to nurture it. You may not bring deep knowledge or hyper-productivity, but it is your responsibility to energize your team and challenge everything.

When I was an intern at PCI, I had very little knowledge on how to develop apps or create a backend or frontend. I was coming in green as they come. The company took a chance on me and challenged me by assigning me task that were out of my specs. So instead of feeling defeated and craving to become a better programmer, I took on those tasks and began to seek assistance and help from outside sources because the team I was assigned to was more of an individual tasked team. It was like being thrown into the lion’s den as many tasks that I was given were for real life clients and not a class assignment or project.

There were also times where I had great ideas and felt like my thoughts were not heard. That can be expected when an intern since technically I am just a student, however the idea that I had would have made their system more manageable. I was suggesting creating a database that will hold all their financial and student records based on the classes they teach to different organizations. I created a mockup using MySQL database and created a backend code to follow. I presented it during one of our standup meetings and at first was ignored and pushed to the side. I later went ahead and waited till the end and presented my database again and this time, my scrum master saw how beneficial and time effective this will be along with organizing the records they have since they were currently spread everywhere.

The next challenge was creating an app that will be functional. I spent the rest of my internship working on the app, something that I was not familiar with at the time. Constantly growing my knowledge in the computer science world.

This is the time in your career when taking risks and speaking up makes the most sense. Your ideas and passions will enrich and diversify your team. Even a master craftsman can be made more productive by a well-chosen apprentice.

This internship helped me this past year especially last semester where we learned about creating backends and frontends. Then with this semester with creating functions apps along with the backend and frontend. Having an idea allowed me to become more proficient in that field, making me a more diverse engineer. The moment you stop wanting to learn or express your ideas, that’s the moment that you find yourself limited. With groups or any situation you can find yourself feeling muted out but speak up and voice your ideas because at the end of the day, we are all software engineers

From the blog CS@Worcester – The Dive by gonzalezwsu22 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Concrete Skills

Christian Shadis

In the apprenticeship pattern Concrete Skills, Hoover and Oshineye explore the importance of developing discrete, demonstrable skills with specific technologies. This is an important pattern to implement as a young programmer because often in the hiring process, your skills are often more surface-level, and your value lies in your potential. Developing concrete skills makes you a more valuable candidate and thus more likely to receive an offer.

This pattern makes a lot of intuitive sense. My skills (outside of specific languages) are top-level, and I do not have a lot of projects to demonstrate specific skills and value that I can immediately provide to the company/team I am joining. Currently, my appeal as a candidate lies primarily in my successful academic career and ability to quickly learn, and secondarily in the skills I already possess. In order to successfully find a job, supplementing my portfolio is necessary.

This pattern coincides well with the Breakable Toys pattern in that building those personal, low-stakes projects will allow the developer to demonstrate their skills in a discrete, specific, and demonstrable environment. The toy can then be used in the hiring process, or to develop a demonstration for the hiring process. Having that project available to demonstrate during the interview process will reassure employers that not only does the candidate have potential to contribute greatly as time passes but can also contribute immediately.

I hope to use this pattern throughout the next several months while trying to secure my first career position. I have identified the biggest weakness in my resume to be my lack of full projects to display my skills. I have worked on multiple programming projects that I can use, but they all seem too simple to truly impress a hiring manager. I have a great academic record, but little to concretely prove my development skills. In conjunction with the Breakable Toys pattern, I will look to develop a full-stack project over the coming months that I can add to my portfolio and increase my chances of being hired.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Emptying the Cup. In Apprenticeship patterns: Guidance for the aspiring software craftsman. O’Reilly.

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

Stay in the Trenches

This apprenticeship pattern talks about how software developers should stay in the trenches. As software developers gain experience, they tend to gain a reputation for being exceptional at delivering software. Many organizations tend to reward with promotions in the hierarchy. However, such promotions might end up leading apprentices away from their craft. This pattern elaborates how apprentices should not confuse promotions into management with success. Being promoted might seem like a good sign that you are on the right path, however, one should understand that they will not remain a “technical” manager for long.  A craftsman who strays from their craft will have their mastery over it fade. The more time you spend not programming, the further away you are moving from being a journeyman.

If an apprentice wants to remain in the craft, then they need to draw their career map accordingly. For example, one could try to discuss with their employer the possibility of finding different mechanisms which they may find rewarding. This could come in the form of higher compensation, or it could come in the form of nontraditional technical leadership roles such as internal consultancy. In the case where the employer is inflexible, then perhaps it might be best to look at other opportunities elsewhere. This way you will remain in the craft and prevent yourself from being promoted away from it.

I personally think that this apprenticeship pattern is useful for people with a specific set of values. It is useful for anyone who values their passion for staying in software development and wants to stay active in the craft. If you are someone who loves software development and want to continue However, some people might value things like status, compensation, and greater responsibility more than remaining active in the craft, and therefore, going into management might be the right move for them. Since different values can lead to different career paths, it is important for software developers to constantly reevaluate their career map to see whether the path that they chose is aligned with their values and circumstances or if they need to consider a different path.

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

Apprenticeship Patterns Blog Post 1

This week I would like to look at the “Confront Your Ignorance” pattern. I feel like this is always a good one to look at as despite how good of a programmer you might be, there is always something more to learn, and there is always something you don’t know.

This pattern means there are things you still need to learn/know, and some of these things are things that many others may already know, so it is expected of you to also have this knowledge.

I feel like it is always important to confront your ignorance, as there is still much to learn, even when you have seen a lot. This pattern is very similar to the “Expose Your Ignorance” pattern, but this one is about learning in private, so you do not need to hurt your pride by making others aware like in “Expose Your Ignorance”. However, it is still important to know to expose that ignorance as well, since always learning in private can have some negative side effects, like having failure be unacceptable instead of just another step of the learning process. You need to be able to learn and grow in a way that will positively affect you and those around you.

But should you choose to not learn in private, a great way to confront the ignorance is to ask questions, as many people may have already had the problem you are currently facing, and are hopefully happy to help you overcome the issue. A common cause of ignorance is focusing too heavily one one particular skill or context, which causes you to become ignorant of the other skills. One must be able to learn, and identify the areas of ignorance, and actively work towards reducing those areas.

You must also always be able to admit your faults, in this case admit that your knowledge is lacking, as how will anyone know your knowledge is lacking unless you tell them? This way, everyone can work together to achieve better learning. Of course, it may hurt your pride in the short term, but it is always better to be known for your willingness to learn more, than to know a lot about a few things.

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

Sprint Retrospective – Sprint 2

I think that we as a team, as well as me as an individual, improved during this sprint compared to the first sprint. While for the first sprint we had no experience working with scrum sprints or in any sort of team development environment, so the whole thing was completely new to us, whereas at least now with the 2nd sprint we had at least a tiny bit of experience. This means that we were able to improve upon some things from our first sprint, because we could see what we did wrong and could change our plan in order to avoid our previous mistakes and optimize our workflow overall.

The first thing we optimized and improved upon was our sprint planning. From our first sprint, we could better judge what we could get done during a sprint by how much we got done during our first sprint. This way we could efficiently work on items, getting as much done as possible during the sprint and not assigning too much during the sprint to the point that we end up not getting most of it done. We could also better assign weight to each of the items because we could better judge how long it would take for us to get each item done, and better judge the importance of each item to the overall project and current objective.

The second thing we optimized and improved upon was our overall communication. We still did most of our communication in class, but we now made sure to communicate through the issues on GitLab. When an issue required additional clarification or explanation, we could leave a comment on an issue and ask the creator of the issue for more details, and the creator could easily respond right on the issue. This not only improved upon the frequency of our communication, but it also helped us to differentiate and easily see what string of communication was pertinent to what issue, helping other team members to see what was discussed respective to what issues. This way, if a team member was working on an issue similar to or previously worked on by another team member, they could easily see what kind of issues that team member faced while working on it, and that could help them work through it without even requiring more help from the team. This makes the workflow as a whole much more efficient because any communication is saved, categorized, and easily searchable.

For the team as a whole, we could still improve upon our communication. Although it is efficient communicating through GitLab issues, and it does have some benefits, it is also good to have some non-official communication that doesn’t directly relate to a particular issue. Leaving this communication on GitLab would be messy, so it would be better if we did this additional communication through discord. For me as an individual, I think I could’ve helped more with the sprint planning, and better assisted my team members. For the spring planning, I could’ve better helped with coming up with weights for issues and assigning them. Finally, I could’ve better helped my teammates by being more active responding to open issues with comments and helping them finish open issues if I’m done with all of my issues.

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

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.