The White Belt

For this week’s blog post, I decided to write about The White Belt.  This section is in Chapter 2 which is called Emptying The Cup, and if I remember the introduction for Chapter 2 correctly, this chapter 100% belongs in this section. Like all sections in this book, it is split up into 5 sections, context, problem, solution, action, and see also. The context is a short sentence that basically explains the reader is now confident in his abilities in a certain language, and people rely on them for help. I was actually shocked to read this because typically the white belt symbolizes the beginning, and this book’s description of a white belt is knowing a language and helping people. That’s shocking to me because that just means I have no belt because I feel like I’m in no position to be helping people with the skills I have now.

The next section is the problem. This section was also very short, but it should be because it is only discussing the issue. The issue for this section is that it is difficult to learn new things, and that your “personal development may have stalled” (Oshineye, Hoover). While this isn’t an issue for me yet because I am still learning my first language, this could very much be an issue in the future for me as I also struggle with learning new things.

The solution section urges the reader to start to learn new things by unlearning the things he already knows. They use real life examples as well as some code examples to get their point across. I particularly enjoyed the code section because I liked how they showed the same process being done with two “radically different” (Oshineye, Hoover). languages. They did this to show that because you have a solution in one language, you should still learn a new language to broaden your horizons.

This section was a really easy read for me. The part where they talked about how the white belt had to learn the way while the black belt knows the way really hit me because that was how my internship was. I had to watch and learn everyday before I could even do anything, and it was actually nice to learn along the way because I realized there was so much more that I had to learn before starting my real job.

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Android Activities and Fragments: Getting Them Straight

AndroidX has brought a few changes to the Android framework, but the general architecture remains the same. Likewise, the few years since I’ve first learned Android has completely changed how I feel about Android. At this point, I am developing the basic architecture of my independent study app.

There are a lot of conflicting opinions about Activities and Fragments in the Android Developer community. A few years ago with my limited Android experience, I did not completely understand. I likely don’t completely understand now. However, I have better tools and more programming experience to see how they should be used, as well as to make my own decisions on how to use them.

At first, I found myself paralyzed with confusion on how Google wants its developers to use Activities and Fragments. As an example of how programming concepts translate well to other technologies, learning Angular helped me understand the difference. Activities are a single “thing” that a user does, and can be thought of as a web page. A Fragment should be used for a modular UI component, and function as Components do in Angular.

This isn’t a perfect analogy, as the frameworks are very different, but this is a good way to proceed when deciding how to structure your app. Google’s Introduction to App Architecture guide is a great explanation, and the most important thing to remember is to maintain a separation of concerns. In the end, Activities and Fragments aren’t a significant part of your app. They contain your app. They are something your app uses to work within the Android framework, and your business logic should be elsewhere because Android will pause or stop any Fragments or Activities it needs to if, for example, memory is running low. There is no guarantee they will maintain state unless you take additional steps to ensure it does so.

In researching opinions on how to use them, some people mentioned that they’ve seen developers decide on having a single Activity, and adding all features with Fragments. This is a tempting solution, but that might result in complex logic to control navigation. Furthermore, Fragments are meant to communicate through their parent Activity. In a large app, this would likely result in many implemented interfaces and complicated callbacks. Bloated Activities a big NO.

Likewise, others mentioned only using Activities and not adding complexity with Fragments. This seems a bit more reasonable, but restricts reusability of the Fragments in the UI. Only one Activity can run at a time. The beauty of Fragments is they can easily be dropped into a layout and reused. If they are designed to interact through their parent Activity, two Fragments can be shown at the same time on a larger tablet, even if they must be shown on different screens on a phone. Creating Activities only would mean either creating new Activities with repeated code for a tablet, or reusing the phone UI at the expense of user experience.

I’ll reiterate: separation of concerns. In Android, or any framework, understand the philosophy behind a class and component before deciding to try to simplify things. It’s likely that they were designed to prevent the problems you will run into.

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.

Concrete Skills

I have furthered my reading in Chapter 2 of the Apprenticeship Patterns this time about Concrete Skills. With all the romanticism of being an Apprentice and obtaining the ability to learn quickly this chapter really tells the other side of that. It does pay to bring a level of enthusiasm for learning to a team but in order to be hired on a team you need a point of persuasion. This is when concrete skills come into play. Examples described in this chapter are things like a basic knowledge of various industry popular languages, frameworks, and a well developed understanding of your native language. Having these basic, or concrete skills, allow you to show some sort of way that you can benefit a team indirectly with basic tasks before you learn how to directly help.

This chapter addresses something I often think about. Some questions that run through my head, “What are the basic skills I need for getting my first job?”, “Am I expected to know what they are developing and how to contribute, or will they teach me?”. The truth is you can’t know about a development project before you are part of it. How things are done and what the scope is, will have to be learned as you go. Then my first question of what it is I need to know beforehand becomes more clear. My concrete skills need to be further developed, I need to explore more now at this stage in my career. 

I often feel the pull to my familiar skills when presented with a project. I need to use Java because that’s what I know, I need to use this IDE, I need to use this Database. However, it’s interesting as I read this book I see my development toward these goals presented in each chapter. The reading helps solidify my exploration into the unknown. The start of this semester I thought I would only use my most used IDE and the database I was used to using. As the semester got going I began to use a new IDE that seemed to better fit my interests after I took the step to get familiar with it. I also took the chance to learn about a new database application that better fit the needs of the project rather than catering to my familiarity. My next goal is to learn a basic understanding of a few more popular languages.

Developing these concrete skills is just as important as unleashing your enthusiasm for learning. Both are beneficial for a team but concrete skills will give you a practical use upon hiring.

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

Craft Over Art: or how I learned to stop worrying and love my ugly UI

As I mentioned last week, I have a tendency to try to make products out of projects; meaning I can’t just have something to tinker with for fun, it needs to essentially be a rough draft for the actual project I have to work on. In the same vein, I have another hang-up on wanting things to be clean and pretty to start. Now, of course, one should strive for well formatted code following best practices, but specifically for those projects with a user interface I try to go straight to a finished product from the start. As a result, the Craft Over Art Pattern was illuminating, bringing into focus where my priorities should lie especially in contrast to where they are currently.

In sum, this pattern emphasizes that you have been charged with creating a functioning product, not necessarily a pretty one. The line, “the things we build for customers can be beautiful, but must be useful” says it all. I realize in constantly polishing a project before its feature complete, I end up throwing away a lot of work spent on “dolling up” features or elements of the user interface that may change or not even be used. I even caught myself making the same mistake even on a personal project using a different web application language, where I did not even attempt to make any forms or methods that communicated to the backend, instead spending time adding libraries for user interface elements that look nice and animate well. While there is certainly a place for those things, this pattern helps one understand that is when you have all of the parts of your application finalized.

I should have learned this lesson last semester with my final project. I spent so much time fiddling with the color palette and page animations, that the content on those pages was barren, or poorly formatted. It is nice, I think, that my webpage looks and animates nicely, but when pages break upon reloading then it hardly matters. If there is constantly some expectation of failure with a project, then the font you choose is hardly relevant. I think that is what this pattern helped me realize most about this weakness of mine; utility is the most important aspect of software, everything else is so much fluff.

From the blog CS@Worcester – Press Here for Worms by wurmpress 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 Patterns. This 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.

Confront Your Ignorance

This week, I’d like to discuss the next step from last week’s apprenticeship pattern. Once you’ve exposed your ignorance to others and realized it yourself, you have to own it and fix it. If others can’t help you, you’re on your own.

This pattern can be used in isolation, without showing others. This is helpful if it’s something very basic which would be embarrassing to admit to, or something you lied about knowing, which is never a good idea. The downside to learning on your own is an isolationist mindset. In a team where everyone is working on their own, this could create a culture where ignorance is frowned upon.

I generally agree with the ideas in this pattern. It is good to keep its downsides in mind, especially since I know I generally prefer to learn on my own. Sometimes, it is simply more efficient. In college, I’ve saved about 2 semesters’ worth of time (and money) by taking CLEP exams, learning the material on my own. For some subjects, it’s simply much more efficient to create my own study guide, find the gaps in my knowledge, and fill them in.

The result of doing so has been much clearer, broader, and more detailed understanding of the subject matter as a whole than I would have otherwise had taking a class. Taking a single exam held me more accountable than a class generally does, which is broken up into smaller assignments with the goal of preparing you for the final exam.

This would never be the case for learning to work on a software team, as we are in our software development capstone. Reading about Agile won’t make you an expert in Agile. Collaboration is a practice.

While not always ideal, I think this pattern can be extrapolated to professional applications. If you’re learning a technology on your own, you don’t know what someone might ask of you. The pressure is on to learn as much as you possibly can. If your goal is to appear as knowledgeable in a subject as possible, this pattern might be the way to go.

The warning against taking this pattern to the extreme is valid in cases of working with a team. It is important to use discretion when choosing between exposing ignorance to others, or confronting it on your own. I plan to lean toward exposing ignorance and asking for help in the future.

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.

Craft over Art

For this week’s pattern I have chosen “Craft over Art”. It describes of the pattern where you are given a problem and you are solving it for a customer. You can do it the simple and tested way or create a new solution that will let you express yourself as a programming artist and will look nice on the resume. It describes the conundrum of making something simple and useful right away or making something beautiful and complicated and not usable right away.

I have chosen this pattern because I have struggled with it many times before in my professional career. Many times have I been given a problem to solve for a customer and I had to decide to make it the quick and easy way that I already know will work, or should I do it some new, more complex way that can possibly save some time in the long run. The way that the “Apprenticeship Patterns” describes it should be done with a mix of both solutions, make it somewhat easy but tested way but with possible improvements. I think this is a good approach but there is a catch to it in my opinion, what is acceptable to the customer? Can they wait for a different, nicer way or quick, not totally efficient way will suffice? I think in the moments like that it is up to a Project Manager or the customer to decide and anybody working on this should act accordingly.

We as programmers and developers are in the end a service providers, unless we work for ourselves and do not have any hard deadlines, we need to stick to timelines and or project deadlines. What works and is tested very often is the right solution because time spent on implementing new solution can be something that ultimately may cause a project to fail and nobody wants that. The book also says that we as craftsmen need to provide at leas a minimal level of quality, and I think that if something is well defined and tested and works has that kind of quality. Why go for a new fancy way that might now work 100% of the time, or it requires a lot of time to be understood by somebody else. My boss likes to remind me that “if it is not broken do not fix it, because you will only cause more headaches to yourself and somebody who will work with my code later”.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Pratice makes permanent

Apprenticeship Patterns is a really interesting book to read and I actually learned a lot from it. For this week, I read about the pattern “Practice, Practice, Practice” and there are a few interesting things I found about it. The pattern starts with a quote by George Leonard saying that masters they don’t just get better by devoting in a particular skill, but they practice getting better and the it gets more enjoyable to perform basic moves over again once they are better. I can definitely agree on this as I think we all have been through a rough beginning of doing something, but when we are better, we would think back how easy it is to do those basic task and we would do those rather than more complex problems that we have to face later on during the process of mastering a skill.
Then the author went on to talk about practice is a long process and it has to be done without interruption, and in a comfortable environment of making mistake. At this part, it is interesting to learn that practice in software development can be in a stress-free and playful environment. For me, I always think that the best way to practice is to join a group project, and there would be one or another thing that would stress me out so easily like if I work in a small group or alone even on a small size project, at some point we would be overwhelm with the amount of work that we have to deal with, or too much concern about security, features, accessibility, etc. and after reading this chapter, it makes me question about my priority on different aspect of the program and maybe I should change in order to get better.
The author also brings up another interesting point is to try to do a bit different for each time we practice and choosing the right thing to practice is very important. In my opinion, I think that should be the most optimize way to discover new things and not to miss out any important things while we are still on the basic level.

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

Unleash Your Enthusiasm

Further reading into chapter 2 I find that I relate to many of the patterns in this chapter, However, in my reading tonight I felt a specific interest in UnleashYour Enthusiasm. Unleashing Your Enthusiasm is about taking your passion for the work you do and exercising that passion. Think of it like starting at a new gym. You may not know what to do or the correct ways to do things, you may feel weak, confused, and embarrassed. Even with all of these negative feelings you know that you are excited to learn and get stronger. You may need to ask trainers for help and exercise your want for learning despite the embarrassment. This pattern is primarily about understanding that your passion used correctly is itself a valuable attribute to contribute to a team or teacher.

I find that this pattern goes hand in hand with Exposing Your Ignorance and that are one in the same. In order to unleash your enthusiasm you must be willing to expose your ignorance. If you are new to a team or project you are undoubtedly going to have to learn. You have to know that other more senior members will know more than you and will have to take the time to teach you, which for them may seem counterproductive. Being alright with your ignorance is the first step toward unleashing your enthusiasm. UnleashYour Enthusiasm is more about seeing the value in your ignorance. With this drive for knowledge it can help rekindle the flames of other more senior members who have plateaued and have their fire of passion die down to a smolder.

I find I experience the fear of exposing my ignorance quite often. At this point in my education I am always learning in everything I do. It sounds silly because it’s so obvious, but everything I have learned was once something I did not know. This means I had to overcome some fear and pursue that knowledge. Working with teams of my peers there is often a wide range of knowledge based on experience and backgrounds. It is scary to put myself out there and explain that I may not know something that they are all talking about it, but I have had the courage to do so. Many times I have done this and then had a pleasant conversation with my peers about having the drive for knowledge. It doesn’t pay to be afraid of taking the chance, that chance is knowledge and it gives others the opportunity to share something with you. I find that this unleashing of enthusiasm sparks a great pep talk for any team.

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

Machine Learning Problem Framing

Last week, I gave an overview of my planned independent study project. This week, I’ll give a bit more detail on what I’ve done.

I have a habit of preparing for classes before they start. I buy the text books, get an overview of the material, and prepare to apply learning techniques throughout the semester. This helps me identify problems before the semester starts and address them in class as I go. Likewise with this project, I had hoped to get as much as I could done with machine learning before this semester started to hit the ground running with the software portion. Naturally, my ignorance led me to assume the problem was easier than it actually is. After a great conversation with a communications professor, I realized the problems I was trying to solve had to be broken down.

Counter-intuitively, the broken down problem is more difficult. To recap, my project involves machine learning and audio signal processing. Although great leaps have been made in this field and many problems have been solved, they mostly use clever tricks to achieve the results they get. Take speech recognition for example: your text-to-speech software transcribes nearly 100% correctly. Machine learning models can use huge datasets of audio, as well as commonly-spoken phrases to decide which words you’re most likely to say. The result is that mumbling, stuttering, or ambient noise is a bit more forgivable. On the contrary, transcribing each and every syllable is not nearly as easy, and in fact it’s a problem that has yet to be solved. That’s a shame, considering I was hoping to transcribe an audio sample into phones as part of my process and I somehow doubt I can do it without first getting a PhD.

This realization has led me to take a quick course on machine learning problem framing. It teaches the process of developing an hypothesis and developing a model to prove it, as well as resisting the temptation to shoehorn a problem into machine learning when a heuristic solution is as good or better. I did manage to find examples of using machine learning to solve some of the problems I wanted to (dating back 20+ years, even), but unfortunately they were each limited in scope and would be difficult to use to make a cohesive app. My goal isn’t a Frankenstein project.

In an effort to dig deeper, I’ve also done an introduction to Pandas tutorial, and started on a Tensorflow tutorial. These are surface-level in and of themselves, but help in understanding the higher-level frameworks. My hope is that understanding the basics will allow me to create a model that has an exciting application. In the meantime, I can implement the prerequisite features in software: audio recording and signal processing.

I’m going to dive into more specific problems as the semester goes on and I get more comfortable with the topics. I’ve already come up with a list of ideas and find myself wanting to write posts on small things like Android project flavors and build configuration. Posting thoughts and lessons in a public place has been great for accountability, and my goal is to know these technologies inside and out 4 months from now.

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.