Monthly Archives: March 2020

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.

Practice Makes Perfect

The pattern “practice practice practice” is what the title implies and focuses on one of the most important things in any kind of career. The idea that practice makes perfect has been apart of every job/hobby/club/etc. since the beginning of time. Since programming puts you in a situation where any mistake could ruin the entire project/work, you need to avoid mistakes at all costs. Practice allows for programmers to work on different things and see what works for both them and what ever they are working on. The pattern suggest that you solve an exercise multiple times over a few weeks from scratch and see how your solutions evolve and change overtime and use those in your future projects.
This pattern is something that I thought of when reading the breakable toys pattern since they have a similar aspect of taking things from work home and expanding your knowledge on things that could be used in projects. I felt like this would be something that I would need to do for most jobs in the field of computer science. I think one thing that I found interesting was how it suggests to use exercises in different books because it wasn’t something that I would have thought of to help practice on different aspects of coding. The pattern, similar to breakable toys, suggests to have fun with it and not worry about things like deadlines, production issues and so on cause it allows you to expand on what you learned and see what works and what doesn’t. I felt like this pattern had a lot that I wish I knew about when I began computer science classes because it would have made my learning experience easier and more enjoyable.
I will use this in my professional career since it seems to be something that would benefit me and help me to be a better developer and computer scientist. The idea of using different computer science books on different topics and using the exercise in the book were a good idea that I will use in my career as well. While old books may have the fundamentals of coding, it is important to get newer books focused more on the languages that are being used since they will have a good understanding of how to use the language to the best of its ability.

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.

Analysis and Comparison of Ascending and Descending Scales

With added pressure in realizing the semester is half over, as well as an upcoming interview for a position dealing with DSP and machine learning, I came into this week with newfound motivation. The focus that comes with a little bit of pressure is paradoxically quite freeing.

I had some issues when attempting to compare features between audio files. In hindsight, it was an obvious mistake that I had already learned in theory. But of course, applying theoretical knowledge always reveals the points of weak understanding.

As I’ve written in the past, MFCC (mel-frequency cepstrum coefficients) are most common with speech processing. There are time slices taken from the audio file and by default Librosa calculates 13 coefficients commonly used for speech processing. The MFCC is an array of time slices, each represented by 13 coefficients. These are plotted below, with color representing magnitude (from dark blue to dark red), time slices on the y-axis, and coefficients on the x-axis. The waveform, MFCC Delta, and Chromagram are also plotted.

The chromagram is of particular interest, as it extracts the frequencies in the time domain, revealing that the scale on the left is ascending and the scale on the right is descending. You can even see where my finger slipped playing the descending scale.

Analysis of an ascending and descending scale

This shows the importance of scale invariance when comparing features, which will also come to play in machine learning. This is why frames of equal time-slices, which usually overlap, are taken from an audio sample.

Originally, I was extracting features without cutting the audio files to the same size. This resulted in a larger MFCC. Attempting to plot the difference between the features caused an error. Files with the same length, however, naturally resulted in two arrays of the same size. Because they were only slightly off, I wanted to be sure that my understanding was correct, so I made the ascending scale exactly half the size and ran the program again.

Indeed, cutting the first sample in half reveals that the resulting matrix has half as many MFCC time slices. Librosa extracts the first 13 mel-frequency coefficients, so each array will be length of 13 and each time slice will have one of these arrays. Trying to find the difference by subtracting one matrix from another results in this error message:

ValueError: operands could not be broadcast together with shapes (44,13) (87,13)
Analysis after cutting the ascending scale in half

Also notice the chromagram only reveals 4 major frequencies. And because a chromagram is in the time domain, but the plot still has the same x-axis, the notes end at approximately the halfway point.

Plotting the absolute difference between MFCC features may not be visually illuminating, but potentially has uses for pattern identification. The real utility comes from comparing an audio sample to existing files. Take a look at the ascending versus ascending scales:

The absolute difference in MFCC features between ascending and descending scales

There is little difference in the higher coefficients, but some strong differences in the first coefficient. There are irregular differences through the rest of the plot, both in time and within coefficients. In isolation, this doesn’t reveal much. But when instead comparing two ascending scales offset by 0.1 seconds, the differences are very small. There are regular spikes in the first coefficient however, likely due to the earlier change of note in one sample.

The absolute difference in MFCC features between ascending scales, offset by 0.1 seconds

This lack of difference is one example of how a machine learning algorithm can detect whether a audio sample fits into a group. Actually training these models will be the topic for next week.

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.

“Use the Source”

“Use the Source” is a pattern from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern focuses on the need for reading code written by other developers. Some good sources of code to examine are open source projects. By examining source code, a programmer can see what their bad habits are and adopt new, better habits. Another benefit from code reading is learning new algorithms to solve different kinds of problems. Expanding one’s collection of code solutions allows a programmer to be flexible and able to solve more problems.

I found this pattern particularly interesting. Since programmers are constantly required to work with other’s code, it is imperative that they learn to read code efficiently with practice. I do not have much experience with this myself and this pattern has made clear how important reviewing other’s code is. Regardless of what career I pursue after graduation, it will be important to read code effectively. I will need to start looking into some open source projects so I can improve my skills. Now I just need to find some projects that I contribute to and am interested in.

“Use the Source” suggests contributing to open source projects for software you already use. This is very helpful advice to me; I use a lot open source software.

  • Atom: text editor
  • Eclipse: IDE
  • Insomnia: REST client
  • GIMP: image editor
  • Several different game system emulators

I briefly examined some of GIMP’s source code. GIMP has a label on issues for newcomers, allowing for quick access to simpler issues.  After reading through some of the code, I realized that it would take a great deal of time to get an idea of the project architecture.

I looked at this issue, (https://gitlab.gnome.org/GNOME/gimp/issues/4128), and thought it seemed simple enough problem to start with. While the problem seemed simple, I could not navigate the repository and locate where the problem may be. GIMP is significantly more complex than any project I have worked on before. Ultimately, I was not able to make any headway on the issue. I was, however, able to read through portions of the code and begin to see some of the structure behind the it. Though I did not find what I was looking for, I did get a basic feel of the code’s flow.

As stated in Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin, developers read far more code than they write. With that being the case, “Use the Source” is an excellent way to grow your code reading skills.

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.

Digging In

The Dig Deeper pattern is all about knowledge and gaining more of it. More specifically, this pattern is about taking something new that you have learned or are currently learning and teaching yourself about that subject’s roots. It’s not enough to know how to use the subject matter to solve your specific issue, you need to know that subjects use as a whole to gain knowledge of its context. This pattern is about understanding how a system works as a whole and not just the part you are working on. This deeper knowledge allows you to understand your work more concisely based on the context of it as a whole, which will help you understand your specific issue even more.

When I first started reading on this pattern it felt like a very blunt lecture. It felt as though I was being told to learn everything to its fullest and if I do not then I will be a less desirable individual for hire. However, as I read on I realized it was not about having total knowledge of EVERYTHING, that would be overwhelming and nearly impossible. I began to understand that it was about delving your knowledge into specific things, subjects that you are currently working on. If you are working on a specific issue and find the solution, it’s not about knowing every way to solve the problem, but to know in detail the workings of your solution.

This pattern further enforced my idea that you can do anything, learn anything if you put your mind to it. If there’s something I really want to excel at, deepening my knowledge can only help me achieve my goal. Being able to fully express my knowledge on the specific things I have worked on, though maybe few, is far greater than a larger quantity of surface knowledge. It reminds me of using MongoDb for the first time in our libre food pantry project. It’s all good and well to set up a database and query and get the results you want. However, it’s much more important to understand how the database functions beyond my own entries and data types I’m working with. In furthering my knowledge I was able to communicate my understanding into the other areas of the project including tying the database to a Java REST API. I fully agree with the ideologies of this apprenticeship pattern, dig deeper into your knowledge and it can only benefit you.

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

Use Your Title

I’m promoting you from Senior Engineer to Lead Engineer. The pay is the same but people will disrespect you less.

—Dilbert’s Pointy-Haired Boss

“Use your Title” is a very effective pattern for those who feel like the title they have is everything in life. We all have our own goals in life, and we approach differently to achieve them. For some, a software engineer position is all they have wanted to achieve in life, and there are others who would not feel accomplished until they become seniors or leaders in the industry. On the other hand, it happens to have an unimpressive title, even though you have given more authority in your position than your title or job description says. In this case, people get discouraged and lose hopes that one day they would get what they deserve.

In my opinion, we should “Use our Title” in a way that benefits us professionally. Titles are only made to feed our egos. What is more important is that we should never stop learning or stop searching for better opportunities that would complete us professionally. Let’s think of it as climbing mountains. The second highest mountain in the world is K2. If a person’s goal a year ago was to climb that mountain, he/she would feel accomplished when he/she gets there, but then he/she would feel the need of having another goal to achieve and would end up climbing Mount Everest. This tells us that even when we get to have the title we always dreamed of in the industry, there’s more we can achieve.

In this pattern, I found interesting the part that suggests writing down a long and descriptive version of our job title. I think this would help us reflect on what we do at our workplace, if the title matches with the authority we have given, and maybe find the need to update the title with superiors’ permission. I, myself am going to try and see what I find out when it comes time to update it.
As a conclusion, make sure your skill level matches your job description and title, and no matter how far you go with titles, remind yourself that your apprenticeship is not over.

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