White Belt

The pattern “The White Belt” is all about becoming a student once again and not letting your knowledge or expertise in a certain subject get in the way of learning new things. The pattern also talks about how you should put aside past experience and unlearn things so that you can understand what you were struggling to learn. The pattern also wants you to use a new language or style to solve a problem so that you don’t fall into the same hole that you have been when it comes to learning. I often find myself in a similar problem when it comes to programming because I often use similar code in future projects or rely heavily on what I know works versus trying new things that may work better. This pattern is similar to other patterns but focuses on relearning or learning new things and setting aside past experience. I felt that this pattern is important to remember for my professional career cause I could see myself facing a similar problem to the one described in the pattern.
I think that an extremely important part of the pattern is that you should try to learn from other people. This part of the pattern is discussed and is the key focus of the pattern “Be the Worst”. I do not like the fact that they continue to blend patterns together since it makes it harder to distinguish between the different patterns. I think focusing on learning new things without allowing old knowledge to corrupt the new knowledge is an important part of learning anything and especially coding. With the way people can easily connect on common interests and topics on platforms like Discord, Twitter, FaceBook, and more, I can see myself joining different coding communities and interacting with other people that may have more knowledge on a topic than me, in order to learn more in different areas of coding. This pattern has given me a new way to avoid getting stuck in a rut that is common in the computer science field. Using different languages is important to better understand the inner works of what a function does and how it can be implemented in different ways.

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.

Kindred Spirits

The pattern “Kindred Spirits” in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, by Dave Hoover and Adewale Oshineye, addresses the need for social connections to other software developers. Fostering relationships with kindred spirits will create an environment that promotes curiosity and avoids stagnation. Groups share knowledge which allows members to learn from each other. The pattern warns of groups that will resist change and shun those who present change. Groupthink is also warned of in this pattern.  Conforming to some standards is necessary when participating in a group but that conformity should not discourage growth.

I have never been very good with making new connections. Most, if not all, of my computer science connections have been through school and, with graduation nearing, I will need to find new kindred spirits. “Kindred Spirits” suggests finding groups that meet in person, making this currently unadvisable (Social Distancing) but good to remember for down the road. While maybe not as effective as in person meetings, there are plenty of online groups to check out. The open-source communities seem like a good potential place to start. Also, many in person groups will have ways of communicating remotely so it still may be worth looking into.

“This pattern is simple in principle, and for some people (our extroverted cohorts) it is simple in practice. For others, however, it can be difficult.”

This line makes it clear that the difficulty I find with this pattern is common. My innate aversion to large groups and strangers has caused me to avoid attending events in the past, but it is becoming increasingly apparent that I will need to change that behavior.

While I find groups stressful, I agree with the pattern about the benefits of being part of one. Software development communities are great sources of knowledge and inspiration.

The pattern, “Kindred Spirits,” is one I will need to practice. Since I still have a great deal to learn, I think it will be imperative to find a group that will teach and inspire me. Other software developers will always have new things for me to learn if I seek them out.

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.

Find Mentors

Whether a beginner starts out with a training course or isself-taught, the first step on the path to softwarecraftsmanship is finding a craftsman to apprenticehimself to.Pete McBreen, Software Craftsmanship, p. 96 So far I like this pattern a lot, and I feel it’s close to what I’m trying to do during my studying, my previous … Continue reading Find Mentors →

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

Rubbing Elbows

“I enjoy being given a certain amount of freedom in order to interpret or to come up with stuff, but I do enjoy collaboration. I seek and thrive on projects where I am going to learn from the people I’m working with.”

William Kempe

I agree strongly with the author.

Yes, being a software developer is about collaboration. This is how ideas and creation comes in. Even if you know everything about on how to implement the data or any complex function you still need to collaborate with other developers. Who knows that they know an easier way to code the program. Collaboration is a huge part.

It is a learning strategies. The word the author gave is “Pair programing”. It is complex because you are compare and working on same thing but each with different or similar strategy. It will bring motivation and curiosity in learning new techniques.

Basically, It is a way to expose yourself to work along with skilled people and observe how gradually skills are grown for both developers. If you find someone who is as eager as you are in working on the project than make sure to have a good understanding an have talked though about the projects.

From the blog CS@Worcester – Tech a Talk -Arisha Khan by ajahan22 and used with permission of the author. All other rights reserved by the author.

A Machine Learning Model That Recognizes Spoken Digits (Introduction)

This week, I managed to prove (to myself, at least) the power of MFCCs in speech recognition. I was quite skeptical that I could get anything to actually recognize speech, despite many sources saying how vital they are to DSP and speech recognition.

A tutorial on Tensorflow I found a couple of months ago sparked the idea: if 2-dimensional images can be represented as a 1-dimensional array and used to train the model, perhaps the same could be done with features extracted from an audio file. After all, the extracted features are nothing but an array of coefficients. So this week, armed with weeks of knowledge of basic Tensorflow and signal processing, I finally tried to get it to work. And of course, many problems arose.

After hours of struggling with mismatches in the shape of the data, waiting for the huge dataset to reload when I made a mistake, and getting no results, I finally put together the last piece of code that made it run correctly, and immediately second-guessed the accuracy of the model (“0.99 out of 100, right???”).

Of course, when training a model, a result this good could be a case of overfitting. And indeed it is, because it is only 95% accurate when using separate test data. And even this percentage isn’t the whole story. The test data comes from the same dataset, which has a lot of recordings of each digit, but using only 4 voices. It’s quite possible that there are patterns found in the voices that would not exist in other voices. This would make it great using a random sample from the original dataset, but possibly useless for someone else. There’s also the problem of noise, which MFCC is strongly affected by. So naturally, I recorded my own voice speaking digits and ran it with the model. Unfortunately, I could only manage approximately 50% accuracy, although it is consistently accurate with digits 0, 1, 2, 4 and 6. Much better than chance, at least!

This is a very simple model, which allows you to extract only MFCCs from an audio recording of a spoken digit (0 through 9) and plug it into the model to get an answer. But MFCCs may not tell the whole story, so the next step will be to use additional extracted features to get this model to perform better. There is also much more tweaking I can do with the model to see if I can obtain better results.

I’d like to step through the actual code next week and describe the steps taken to achieve this result. In the meantime, I have a lot more tweaking and refactoring to do.

I would like to mention a very important concept that I studied this week in the context of DSP: convolution. With the help of Allen Downey’s ThinkDSP and related lecture, I learned a bit more detail on filtering of signals. Convolution is essentially sweeping one signal over another to get a new signal. In DSP, this is used for things such as low-pass filters and adding echo to audio.

Think of an impulse as an instantaneous tone consisting of many (or all) frequencies. If you record this noise in a room, you will get a recording of the “impulse response”. That is, how all of the frequencies are affected by the room over time. The discrete Fourier transform of this response is essentially a filter, because it gives the amplitude of each frequency in the impulse response, including all echos and any muffling. Multiplying these amplitudes by the DFT of an entirely different audio signal will modify each frequency in the exact same way. And thus, to the human hear, this different audio signal will sound like it does in the same room. If this concept is interesting, I encourage you to watch the lecture and work through the examples in the book.

I think these topics may come in handy if I need to pre-process recordings, in the event that noise is in fact causing errors in the above model.

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.

Learn How You Fail

All the big CEO’s and entrepreneurs will give you trite advice on their LinkedIn pages: you need to fail a lot in order to succeed a lot.

I can’t be too hard on anyone who wants to get this message out, because I had to hear it at some point too. Failure meant incompetence to me, not part of the path to success. But what if failures don’t stop? The “Learn How You Fail” apprenticeship pattern attempts to solve the problem of lingering failures despite increased success.

This is likely due to something you are repeatedly doing that causes the failures. Hone in on these behaviors, because changing them is the only way to stop failing. Furthermore, you may simply not be good at some things, and finding these things can prevent wasted time and effort.

A potential problem with this pattern is that a lot of failure is likely due to blind spots in our perception of ourselves, so it’s likely not easy to solve the problem of uncovering the cause of our failures. But as software developers, our skills in pattern recognition should be top notch. Carefully documenting your failures and how they connect should reveal the patterns.

A coworker asked me years ago what my chosen superpower would be. I answered that I would want to know everything. Omniscience. Besides briefly earning me the nickname “know-it-all”, this reflects my own desire to fix my unfixable flaws. Now, I do think significant effort should be put into things that you are especially bad at. But this pattern is a good reminder to let go of the things that you’ve tried to do and simply haven’t worked out.

Success is many cases is figuring out what you are good at, not about fixing all of your weaknesses. This is the reasons the US President has a cabinet, Congress has subcommittees, companies have divisions, and software team members have roles. We can’t all do everything.

My biggest issue with this pattern going forward will be striking a balance. There will always be a desire to learn as much as possible. Gaining more skill and broadening horizons may be tempting, but knowing when to give up in a specific area is the challenge. The CEOs who credit their success to past failures knew what to give up on within their chosen field. Almost always, this doesn’t mean choosing a brand new career; it means finding what you’re doing wrong in the current one.

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.

Share What You Learn: Sharing is caring

While applying this pattern to my experience feels a little presumptuous, considering people do not “look to [me] as a source of knowledge”, I have tried to share what little knowledge I have as I gain in hopes of helping my classmates with any troubles they may have. Like Kindred Spirits before, I have had good luck attacking a new topic in our individual ways first then comparing notes and filling in the gaps in our knowledge others have covered. As well, this topic reminds me of Breakable Toys as well and my misunderstanding of it, where I concluded that writing a wiki may be a helpful personal learning tool but through the lens of this pattern, sharing it could provide a collective learning tool. While I have yet to go as far as creating that wiki, I have been willing to share any knowledge I have with my classmates.

I also got a great opportunity to brush up on our major’s most difficult subject and then test my knowledge of it by being a peer assisted learning mentor for Data Structures. I realized how much I missed the first time I took the class, and when explaining it I had to shed to convenient mental tools I used for more thorough methods that I could then share with the students. I remember specifically trying to explain how to rank program running times, without taking the derivative of the function that represented the run time; as many of the students had not, and likely would not, take calculus. By the end I did feel as though I was better acquainted with the material but felt sometimes like I needed to go deeper as I had difficulties explaining some concepts well.

Another time, I remember having to give a mock lecture to another student who missed a lecture. It really pushed my understanding of the material to the limit because I could recite what I had copied into my notebook but if he needed to ask a question I could have fallen apart had I not been confident in the material, or had a good understanding of it. The book says that you may feel that “someone more experienced [should] put themselves forward”. However, many people can feel intimidated by professionals and may not be willing to ask vital questions for fear of looking foolish; as opposed to the camaraderie of peers. I think that pushing ourselves to interrogate our own knowledge of material in the presences of peers offers an excellent opportunity for growth.

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.

The Long Road

To become truly good at programming is a life’s work, anongoing enterprise of learning and practicing.Ron Jeffries et al., Extreme Programming Installed This pattern from chapter three caught my attention, the quotes they used in the beginning of this pattern were nice and  sometimes we need something to remind us that the 1000 mile journey … Continue reading The Long Road →

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern Review 8: Find Mentors

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

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

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

 

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

Read Constantly

Reading consistently give you ability to happen our mind.

And when reading connately about good programming, it will build you knowledge and would open more understanding of programming.

“If you read even one good programming book every two months, roughly 35 pages a week, you’ll soon have a firm grasp on the industry and distinguish yourself from nearly everyone around you.”

Books are the key component for growing. Not even book, just the articles or some options on a certain programing tasks you are doing. 

I like how this section cover the need of reading the words. looking at the word and understanding it. We as a software developer should not only be doing readings on the language tat we are familiar with but also on other languages that is some how connected it the pervious one.

The similarity will connect the broad perfection of a different but yet similar languor. For example,  HTML and CSS are quite similar, java and javascript function and calls are similar but are implemented differently. 

From the blog CS@Worcester – Tech a Talk -Arisha Khan by ajahan22 and used with permission of the author. All other rights reserved by the author.