Confront Your Ignorance

For this week, now that I have read through “Expose Your Ignorance” in the Apprenticeship Patterns, I continue on to read through “Confront Your Ignorance”, as they seem to go hand in hand with each other. To sum up this chapter, it mostly talks about the advantages and disadvantages when taking action to fill up our knowledge once we identified the gap.
The problem posted for this chapter is that while we have a lot of tools and techniques available out there that we can get our hands on, a lot of developers like us do not know where to start and a lot of common things that people know, we are expected to have those knowledge when we start working. I feel like this is the exact current state of a lot of new people who just got into the field and this chapter seems to be important to know about when we get started. The solution that the author presented, which is picking one skill, tool, or technique to actively learn about it, caught me off guard as I would never imagine it to be a simple answer. It is true that we have a start somewhere and using those as foundations to learn others. He then moves on to explain that to do whichever ways work best for us like reading articles and FAQs or constructing Breakable Toys and ask around for people who knows better or simply just people who are looking to acquire the same skill. The best part of this pattern is when he stated that we don’t have enough hours to get all the skill we need, and making trade-offs is necessary in order to get better. This is what I always think about whenever I get into learning something new because I might potentially forget part of what I know now and there will be more and more to learn once I get used to new skills. The author begins to explain that confronting the ignorance can be done in private, but then it would promote the bad habit of being failure or openly learning something in a work environment is unacceptable. And worse side effects that can be found by applying this pattern would be to let our personal gain for knowledge affect the team and we should keep in mind to separate them when we do.
I do agree with every point that the author put out on this pattern as I am sure that it will prove to be helpful when I am required to learn something new. With such simple solutions and tips, I think this chapter is pretty straight forward telling us to keep on practicing ourselves outside of work time, which still keeping up with the team progress so that we can become better without stubble upon failing what we are supposed to do and I think it is useful for new developers to know.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

For this week, I continued reading the Apprenticeship Pattern and the first one that I got into is “Expose Your Ignorance”. To simply explain this pattern, it encourages the readers to basically no being afraid of feeling ignorance and stupid when asking about what we don’t know.

The problem of this chapter is presented with an example of a work environment that requires the developer to be familiar with required with technologies, but we simply just don’t have any idea how to use it. I like how the author says that it happens to everyone because it is true that people can’t know everything and this would let the readers know that it is common, furthermore encourage them to not be afraid and expose their ignorance. With the question of how should one exposing himself/herself to be the most effective, the author gave us one simple solution, which is to show other people that you might not know about it, but you are willing to learn how to do it during the process of delivering software. Leading off as the author acknowledge the common feeling that the societies are increasingly dependent on the competence as a developer and we just have so many zones of ignorance, the author shows us that we still shouldn’t be afraid to tell people the truth despite feeling those pressure. According to him, to let people know that you are in the process of learning that particular technology is important to either build a strong relationship with people or build your own reputation of our learning ability. I would say that this is very true because the fact that people would appreciate the time that we put out to try to learn and use it properly rather than just lying about it and then forcefully use it the way it’s not intended to or finding a walkaround. The author then encourages us to ask questions and adopt the ability to learn as it is the easiest way to get to know something. It is rather an uncomfortable process, but it’s probably the most efficient way to learn in the end.

I can see myself completely agree with what the author said to exposing my own ignorance. I believe that it is what a lot of people in the past did in order to be at their position right now and I also believe that a lot of apprentice like us should not afraid to be judged and do the same, just to get ourselves better every day. I know that I myself do suffer from the fear of asking. Sure, I do want to learn, but I also want to prove to others that I know a lot too, and this chapter helps me to realize that actively learning is also another way to positively prove to other people, and I should not be avoiding it when needed.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Keep Your Head Down Soldier

The pattern “Stay in the Trenches” talks about how you should avoid climbing into management or other positions that don’t involve coding when offered them. The pattern suggests that you suggests alternatives, such as pay raises and other incentives that can be offered to you, if a person is offered a job in management or another job that pulls them away from coding. The pattern also talks about how taking a management job can lead to loss of skill when it comes to programming since it wont be a daily occurrence for the person in management. The pattern talks about how a person should, as the name suggests, stay in the “trenches” or in a position that involves coding directly and where they can continue their craft. The pattern hopes to convince people that they should focus on excelling in their passion of coding and find other ways to be rewarded for their work, instead of pulling a person away from coding.
I feel like this pattern makes a great point that was discussed in the pattern “Practice,Practice,Practice”, which is that when people don’t code for a while, then they will most likely see a drop in their coding abilities and lose most, if not all, of the progress they have made. I think it’s important for any person in the computer science field to do things that interests them the most, either with the work they do, a side project or both. I can see myself continuing side projects of my own as a hobby even when employed in a coding job to not only further my skills, but to do things that I find interesting, fun, or both. I don’t fully agree with this pattern and believe that if offered the opportunity to get into a higher position in a field I’m interested in, I will, most-likely, take the opportunity as a chance to further my career and myself as person. While coding will always be one of my passions, I can not stop myself or hold myself back from trying to reach higher and higher goals in my career and life.

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

Learning how to Learn

Tonight I am continuing with my reading of the Apprenticeship Patterns with toady’s pattern being “The White Belt”.

This pattern helps to explain how to get over the obstacle of learning and implementing new information after mastering “your first language”.

This pattern feels applicable to me as I feel this is the stage I have reached with the first language I learned. I particularly connect with the problem area that describes a difficulty with learning new tools as this is something I feel I am beginning to run into (especially with Angular) while learning new tools for my work on the UpdateGuest project.

I do think that I try to take the approach mentioned in this pattern of forgetting what I know when learning new tools, but I think that now I am more consciously aware of the value of this I think it may further help with how I learn.

I also agree with the point this pattern makes about being afraid of looking bad when trying something new. I recognize that this has held me back in some of my work this semester as I did not want to commit code that I was unsure of. With the help of this pattern, I realize that I need to get over this fear and not let it hold me back.

One of my favorite parts of this pattern is the example code. I appreciate how the beginning of this is in Java, as this makes it easy for me to understand and it makes the comparison more meaningful. The real beauty of the example is how the multi-line Java snippet is condensed into one small line in the J implementation. This vastly condensed (and somewhat strange to me) implementation really helps me to appreciate and understand the point this pattern makes of needing different approaches when using new tools that are unfamiliar from what you already know. This example makes me want to take up this challenge of learning something that is new and completely the opposite from what I already know.

For me, I read this pattern at a great time, and I even wish I had read it earlier this semester as it could have helped me with my work developing for LibreFoodPantry. I am going to make a point of keeping this pattern (and the cleverly quoted advice from Yoda in The Empire Strikes Back) in mind as I continue to learn about new tools this semester.

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

Navigation in Android Applications

With the semester coming to a close, I have been taking all of the working pieces I have built over the past few months and began to put them together. This includes not only the Tensorflow code and the server, but also the Android application.

Having showed my current app to a few people to test the machine learning aspect, I was still presenting them with a clunky, ugly user interface with few features and poor-quality images. The user experience and interface is what I purposely saved for last.

The final app will be showcasing and describing digital signal processing techniques, as that was the focus of most of my work. As such, I had to begin setting up a way to navigate through different parts of the app and creating new “Activities” using the different “Fragments” I have created. This has been surprisingly smooth sailing so far. The tough part as been the navigation, because while it’s possible to create buttons that simply open up new pages, Android has principles that should be followed and even a Navigation component that can help define the user flow of the application.

The reason for defining navigation principles is to facilitate a consistent user experience across Android applications. For example, I have personally pressed the “Up” button on an app expecting to be brought to the previous page, but instead was brought to the Android home screen. This is a sign of poorly-maintained Activities, because previously visited pages should be on the backstack. If the Up button brings the user to the homescreen, it means the backstack was cleared at some point of previous activity.

But the user might enter a page using a deep link; going directly to a portion of the app that isn’t the normal entry point. In this case, you will still want the user to be able to return back to the standard “previous” page. To assist with this in Android, you can define a navigation graph in XML that describes how the user moves between pages. This looks very much like a user flow that should be created before implementing the app.

A top-level navigation graph
From https://developer.android.com/guide/navigation/navigation-design-graph

This also allows for nested navigation graphs, so that if one screen leads to 2 or more sections of the app, these can be defined in isolation and reused. In the image above, the “in_game” page is its own navigation graph, which the “match” screen navigates to. If the match page had a “game_options” screen, this could be another defined graph that could be linked to. Furthermore, the game options could be reached from any other pages just by linking to the defined graph. Because once in the game options, or any other portion of the app for that matter, the possible paths a user can take should not change. All in the name of consistent user experience.

With more defined in XML and handled by the Android framework, less care must be taken to monitor and control navigation through the app. While navigation components are not required in Android, it vastly simplifies the process of adhering to Android guidelines.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

Dig Deeper

With the final sprint of the semester underway, I have had to learn several new technologies for our LFP microservice over the semester. This has led me to obtain only the necessary knowledge to move forward in the project. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman,by Dave Hoover and Adewale Oshineye, has a pattern that addresses this problem: “Dig Deeper.”

“When you read a tutorial, you should not be looking for code to copy but for a mental structure in which to place your new knowledge. Your goal should be to understand the historical context of the concept and whether it is a special instance of something else.”

The apprenticeship pattern, “Dig Deeper,” discusses the downfalls of having a shallow knowledge base and the need for obtaining a deep knowledge of how the tools and technologies work. There are several advantages to having this level of understanding, including: improving confidence, providing a starting point when joining a new team, and improving interview skills. The pattern refers to programmers with this knowledge as “cathedral builders.” These “cathedral builders” can debug, decompile, and reverse-engineer code. The best way to obtain this knowledge is to read specifications and familiarize yourself with debuggers.

The need for this pattern’s practice is like the need to learn history. Learning the history of a tool or technology will prevent repetition of previous mistakes and illuminate the reasons for the inner working’s current state. In addition to learning the history, it is important to dive into the different layers behind the tech and learning how the system works as a unit.

I realize my current understanding of the technologies I have been using for our LFP microservice is shallow and now, I have a direction I had not thought of looking into yet, debuggers.

A problem I have with this pattern is deciding where to start, as any time used to dig deeper is time that cannot be used for learning a new tech. This problem will likely resolve itself, though, once I decide upon a career path. For now, I can just dig deeper into our LFP microservice’s technologies: MongoDb, Node.js and its packages, angular, docker, and all the testing frameworks.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

The White Belt

The overall idea of the white belt apprenticeship pattern is that when you are learning a new skill for example a new language you need to actually need to learn a new skill and a new process. You can’t just apply the old process to the new skill. That will only result in, as the pattern says in its programming example, “writing fortran in any other language”. It says you can accomplish this by unlearning some of your previous skills and starting from scratch with the new skill. It also says that many people are scared to do that because they worry about looking foolish or ignorant. In the example of learning a new programming language it’s important because if you don’t unlearn some of your habits from a programming language you already know and unlearn how to code in that old language you will end up never learning how to use some of the new features of the new language. This is the overall idea and point of the white belt apprenticeship pattern.

I like and agreed with applying this pattern and its main point. I like how it says that in order to learn something you have to start from the beginning and let go of how preconceived notions about how code should be written. I agree with how it says if you don’t do that you won’t be able to write in the new language the way it was meant to be used. I also agree with how it says also that if you dont you will miss out on some  features of the new language.

I found a lot of it interesting and useful. I found it interesting how there was a saying about writing a new language like the old language. I found it useful to remember that when learning a new language it’s important. I found it thought provoking how it says that it’s important to unlearn before you learn. It’s kinda the opposite of what you would think at first. However it makes sense. I will definitely keep this in mind and use this in my future career when learning new languages or skills. Overall I really like this pattern.

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

Beginning the Patterns

This evening I began my reading of the patterns in Apprenticeship Patterns, starting with the first pattern “Your First Language”.

This pattern provides guidance in selecting the first programming language you will learn as more of a beginner and the importance of this first language. The pattern also explains how to move on from this first language to learning others.

I liked this pattern as it let me reflect about my overall usage of Java, the first language I truly learned as a computer science major. Reading this pattern has made me question my usage of this language and particularly if I over-rely on it. I am also wondering if this is the best language to continue using or if I should switch to another language as my primary programming language.

I agree with the advice given of picking a real project for helping to learn a language. This is what I would like to do more of with my side project, and I would like to use this project more for learning new tools and languages.

I liked the idea of using tests as a way to verify your comprehension of a language, instead of just testing the code. I particularly like how this idea is a different approach to thinking about testing and its usage and how to use testing when starting out with a new language. This point is definitely something I want to keep in mind when I learn new languages.

Additionally, I liked the idea of picking languages according to the knowledge the people you know have. With my experience, I agree with this sentiment and I think there is a lot of value in having someone you can go to that can help you get back on track with coding problems. At the same time though I do somewhat disagree with this idea and I think that someone should decide on which language to learn based more on the availability and quality of the resources available for learning a tool or language. The reason for this is that I would prefer to have a reliance on resources rather than having to rely on someone else.

I further agree with the notion of getting “stuck” in the first language you learn. This is something that I am afraid of doing, especially with the longer I use Java as my primary language.

This pattern has helped me to reflect on my current knowledge and usage of programming languages. It has increased my wanting to learn a new language and I will keep it in mind as I switch to learning and using new languages.

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

Apprenticeship Patterns: Sustainable Motivations

This week, I would like to discuss the “Sustainable Motivations” pattern. This pattern explains that professional software developers often must work on messy projects with unclear specifications and conflicting demands. Such chaotic projects are exhausting and frustrating to work on, which can cause developers to lose their motivation to pursue software craftsmanship. The pattern’s solution emphasizes that developers need motivations that will adapt to the difficulties presented by these projects. Developers should have multiple sources of motivation so that, when is damaged by an infuriating situation, they will have other reasons to push through their frustration until the situation gets better. The pattern recommends writing down our different sources of motivation to help us understand which are the most important. When we find ourselves loosing the desire to continue developing software, we can refer back to this list to remind us why we should continue.

As I have explained in my past couple posts on Apprenticeship Patterns, I have really been struggling with motivation over the last few years. Many software-related projects I have worked on during college have been exhausting, frustrating, or unclear. I found it difficult to complete such projects because I simply couldn’t find the effort to work on them. This pattern resonated with me because it focuses on this very issue. I especially relate to the second bulleted example given by the solution, which describes a developer whose main motivation is their enjoyment of programming. For me, this was the main reason I decided to pursue software development, and it has been discouraging to feel that enjoyment dwindle.

However, the developer in the example continued programming due to financial motivations despite a loss of passion, and they eventually regained their love for programming. Similarly, I have continued to pursue software development because of my desire to finish college. I’ve never really considered my education to be a reason to program, but in retrospect it has clearly been my main motivation for the past several years. Clearly, reading this pattern has helped me think differently about my motivations. I’ve always thought my enjoyment of programming was the only motivator I had, but I now realize that other factors, like finishing college and gaining experience, have actually been motivating me more. Hopefully, these other motivators keep pushing me to continue programming until I am able to regain my passion for it.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

Create Feedback Loops

The apprenticeship pattern Create Feedback Loops is an interesting way to learn from yourself and your own interaction with your environment. This apprenticeship pattern is about finding ways to review or “give yourself feedback” regarding your level of skill and competence on whatever you may be working on. 

Working in a team environment you may want to find out your team’s opinion on you and your contribution to the work. It’s not enough to judge your success based on the team’s success, whether that success is good or bad. Being on a team that is great and completes tasks efficiently it is important to know if you are a key contributing factor, or as this pattern put it, a “backup singer”. Just the same if you are on a team that is not producing good work, you can’t get stuck thinking that you are the best on the team and blame the failure on others. Even if it’s not your fault you have to realize that you are not contributing yourself correctly and this could hold you back from furthering your career.

Testing yourself on your own is also important in setting a realistic but higher standard for yourself. Test your work early, learn to expect failure and don’t be discouraged when you do. This pattern is about overcoming your failure by understanding what you can improve. Creating clear feedback is basically a criticism that can be acted upon. “Reinforcing feedback encourages you to do more of something. Balancing feedback encourages you to do less of something”. See both of these types of feedback require you to act, they aren’t stalling you with no clear direction.

One of my favorite examples from this pattern was that of asking for feedback from job interviews or team members. Asking people’s opinion of yourself can help you understand how you are contributing to your environment. A job interview that rejected you could be a great source of knowledge to prepare you for your next interview. Building from failure is how you create success, the more you have from failure the more you can put together to succeed. I find it vigorously motivating to ask my team members their opinion of me and my contribution. Of course I take pride in hearing positive feedback, but I often find that the criticisms help motivate me to be better. Now as long as feedback is delivered to you respectfully it’s great to receive in order to help with your direction. Your team members will also find that an open and friendly environment of communication helps team morale and forward progress.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.