Dig Deeper

This pattern form “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye is probably the scariest thing I read in this book so far. It describes how in order to be a good “craftsman” in software development one should be able to dig deeper into the knowledge about the problems they are working on. It shows you how one must try and be able to find more information about things in order not to be just a person who puts some code together and is what the book calls “programming by coincidence”.

This is a very interesting and intriguing pattern in my opinion but at the same time makes me feel as one of the people who just happened to code but do not know what they are talking about. It might just be my own feeling at the moment but nevertheless it is there. In my professional work I have always worked on very custom project and not very often things were reused which lead, at least in my case, to constantly only gaining surface knowledge of certain subjects. It is not easy to admit that I am probably not as knowledgeable as some of my colleagues, but I think this pattern is showing me how I might be able to fix this problem.

I am very much in agreement with what this pattern is describing, and in my own opinion a living example, even though I am constantly reading some new materials about my chosen field I still feel it is not enough and I should dig deeper to be able to stand out . Knowledge about a subject is always precious but just like the pattern describes if it is not deep enough it will not be really useful, and it might become a problem later on. One thing I definitely understand from this pattern and I like to think that I’m doing right is reading of the documentation and specifications, even though it might not be enough I think that this at least is somewhat redeeming for me.

This pattern is also somewhat problematic for reasons that sometimes getting more knowledge about subject is just plain boring and monotone, I know it sounds as an excuse, but I never heard about anybody excited to read some standards and specifications. Yes, it has to be done and it should be, but it is definitely not enjoyable.

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.

Retrospective: Sprint-1

Links below for my work on Sprint 1 of the LibreFoodPantry project.
MongoDB spike:
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/issues/11
The goal of this task was to preview MongoDb and determine whether or not it will be useful for the project.

Production DB:
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/issues/8
The goal of this task was to create a working Database to match our schema and work with our Rest API.

My favorite part of the scrum framework was actually the integration of kanban. The mixture of the two frameworks really made the work environment productive, predictable, and understandable. My team members and I assigned roles respectively to the scrum framework guidelines, at least two members of the team would know how something is done so that only one member would not have sole knowledge of the task. This way it made it easy to spread the knowledge throughout the team without holding up productivity. If one team member was busy then often the other would be available, or would be in the near future. This team plan also made development quicker in a way that if you were stuck on a task, your fellow task member may have another way of figuring out the issue. Together you can overcome obstacles easier than on your own. A great example of this is when I was developing a Production Database that could be used with our Rest API. I was having trouble figuring out the java code for MongoDb queries. Setting up the connection wasn’t the main goal of the task but it was necessary to have an understanding of it to be sure that MongoDb was the database application we would use. The issue was querying dates and one team member and myself were using CalenderDate which worked, but it ended up being eight lines of code to set up. My other team member on the task figured out LocalDate can achieve the same success with only two lines of code. If I had been left to the task myself the code would be less clean and bulkier, but thanks to my team members different approach we have clean and concise code.

The only things that didn’t work so well was our activity on planning and taking notes on Gitlab. We did not plan in the best way that we could have for the sprint and were constantly editing our backlog and to do lists. We also scarcely posted notes and updates on Gitlab. We did complete our task frameworks in order to move them into the done board. However, we did not thoroughly record our progress on Gitlab. In this way it could be hard for a newcomer to understand the evolution of our issues and how we solved them. They would only see the beginning and end product which is not clear and understandable.

To improve as a team we need to break down our planning technique and make sure our issues are concise and weighted correctly. I think our only problem with this was that we planned last minute because we were unclear of what was expected. However, now that we know we should be able to plan better and make sure our to-do list is concise.

To improve as an individual I need to record my progress, mistakes and achievements on Gitlab more often. Frequent updates on Gitlab would allow a newcomer to see my process and avoid failures that I may have already attempted so that they don’t waste time on something that already is proven to not work. Perhaps they actually solve a failure that I had attempted but was not able to make functional. Without notes to address these topics then a newcomer would not be able to interact and understand our work.

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

Audio Feature Extraction

This week I’ve continued working on the application part of my Android application, but I’ve also started to “dig deeper” (apprenticeship pattern blog post coming soon) and learn a bit more about audio processing.

I started with general concepts of feature extraction a couple of months ago now. Understanding how to use Python libraries to extract features is simple enough, but actually understanding how they work and why they work is another story. This week’s research has revealed an underlying elegance to the concept of signal processing and helped me reach a higher level of understanding and excitement for this project.

The single best explanation has been a video by Youtuber 3Blue1Brown on Fourier Series. I recommend all of his channel because he has an elegant way of describing and visualizing every topic he speaks about. He helped me understand the beauty of Calculus, and in my process of digging deeper I wound up watching his video on the uncertainty principle which was surprisingly relevant to signal processing. Understanding the specifics of the math behind signals and waves, and knowing the fact that mathematical equations are a language used to describe straightforward physical phenomena is key. This knowledge makes daunting concepts easier to break down. Seeing the same concepts used in different contexts also helps solidify them in your mind. And if you’re implementing this in code, it will make it much easier to remember the necessary logical steps required to extract a feature.

This entire tangent (and however useful, it was an unexpected tangent) started with trying to better understand the types of feature extraction that are used in speech recognition. By the way, you know you’re digging deeper when an article with an estimated read time of 11 minutes takes you a few hours to get through with all the additional research.

And universally, as far as I can tell, the first step in signal processing and feature extraction is the Fourier transform, which is simply turning a raw audio signal into separate sine and cosine signals. I say simply, but as the 3Blue1Brown video states, this seems a bit like figuring out which colors make up a mixed up can of paint. It turns out, however, that clever math makes it quite obvious which summation of sine and cosine signals make up a complex signal. I encourage you to watch the video to understand why.

The summation of cosine and sine waves is considered the frequency domain, while the original signal is in the time domain. From the resulting frequency domain, the individual signals can be normalized by taking the log magnitude of the signals and performing an inverse Fourier transform.

This is a new concept called a cepstrum, and it is one of many possible transformations you can make on a signal to begin to analyze the data. Its usefulness comes from the ability to see changes in individual waves. Additional operations can be performed to reveal new insights into patterns in a signal. Determining which if these works best is part of the process.

These individual transformations would be very interesting to implement in code. I may not get a chance to do so for this project, but the understanding of the underlying operations will help in using existing libraries.

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.

Practice, Practice, Practice

For this weeks assignment, I decided to write about the “Practice, Practice, Practice” pattern in the book. This one looked interesting to me because I thought to myself, “Obviously, you have to practice, what could they possibly have written for this” To my surprise they actually had a method that I wasn’t expecting.

The article starts off with a context and a problem like all of the sections do and basically the problem is that a programmer doesn’t have room to make mistakes in their daily job, and they can’t learn because of that. This problem makes sense because messing up in your daily job is too stressful. You aren’t given any room to actually learn from those mistakes.

The solution part, like all the patterns, is the longest part because this is where everything is explained. This section leads off by describing the ideal world as being like a school almost. Programmers can be given random assignments and receive feedback on said assignments, and they can get more assignments as they progress. However, we don’t live in that ideal world, so programmers “must fall back on their own resources to achieve the same effect.” (Oshineye, Hoover).

The next part is what really intrigued me. They relate coding to martial arts by saying the katas are a great way to practice. Katas are basically opponent less exercises to take away the stress from the fighter so they can just learn. In programming terms, this basically means just performing exercises on your own to help you learn without the pressure of being fired. I love that someone made an actual coding dojo in Paris because it is such a good idea. It gives people the chance to code stress free, and there are other people there to review the code that is being produced, and help those who are struggling.

The action section tells the reader to find a problem in one of their books that they should struggle with and they should keep doing it and keep note of how their solutions change each time they perform the exercise. This is a great way to learn because it gives the programmer a chance to learn how to better their code and come up with better, more efficient solutions.

Overall, I really enjoyed this section. Like I mentioned before, I didn’t know how they made practice a whole pattern, but it was very interesting. The whole martial arts metaphor worked really well because coding and martial arts apparently have a lot of similarities. I plan on using this method in my future.

 

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.

Breakable Toys

For this week I’ll be covering the pattern, Breakable Toys, from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. The breakable toys pattern uses small personal projects to teach new techniques. When in a professional environment, playing and learning with the project is not an option. To keep ourselves learning new skills after college, the best thing to do is to create personal projects that allow us to make mistakes and grow as developers. These projects, or breakable toys, are chosen by us and will likely hold more interest than work projects. By working on these projects, we can learn the workings of a project without the fear of consequences of our mistakes.

This pattern is a bit obvious, but I still think it is worth reminding ourselves of. I sometimes find myself tired of working on a needed project and begin to lose some enthusiasm. A breakable toy is always a fun and educational way to lift my spirits while still progressing my skills. To me, breakable toys are more than just a consequence free environment to develop in, breakable toys renew my enthusiasm in the craft.

When I just started learning programming back in ’08, I felt like a whole new world had opened up. There was so much to see and learn, and I was psyched for what I was to learn. My first breakable toy was a text-based game. It was terrible, messy, and bugged but I learned a great deal in the process and because the project was personal, I could do whatever I pleased without concern. While I have not worked with that project in over a decade, I can still remember some of the lessons I first learned while making that game.

I would highly recommend exercising this apprenticeship pattern. This pattern combines the developer’s interests with a stress-free environment to create a project that is exciting and rewarding. I think of our coding skills like cooking, part science and part art. To grow as a programmer, it is important to remember that we need to push our boundaries and experiment is we are to learn. A breakable toy is the perfect project to practice old skills and develop new ones.

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.

Capstone Sprint 1 Retrospective

With our first sprint under our belts, our team is excited to dive into more advanced features. A majority of this sprint was spent learning some new technology, getting our heads around the project’s documentation and workflow, as well as learning to work as a team. However, we also made some strides in implementing our final product.

My contributions

Discussion about whether an issue was a duplicate or if it was a typo, and subsequent editing of the issue.

Commenting with documentation for date format for future reference, which occurred during an in-person discussion.

Request to take care of an issue that was already assigned, in an attempt to complete the tasks at the top of the board first.

Opening an issue that was discovered while committing with a new .gitignore file.

Reviewing and marking an issue to find approved colors and logos as done after completion.

Implementing a stub and merging after approval.

Discussing issues during approval of another feature and merging manually.

Retrospective

As a team and individuals, we are all excited about this project. We all bring our own interests, skills and knowledge, which come with our own quirks and blind spots. This occurs on any team, but it is nice to acknowledge this in ourselves and in our teammates so that we can become more willing to spot them in each other. This allows us to delegate work that we need, ask for help when we need it, and call each other out when we are going down a rabbit hole that is a dead end. I may be the worst offender in this, because I would sometimes slow myself down getting caught up in unnecessary details. I wouldn’t resent my team for telling me I’m worrying too much. I personally feel I could also be better at describing what I’m worrying about.

This experience during this sprint opened up a possibility for improvement for our next sprint planning: more detailed descriptions of “done”. Being new to the format, we tried to shoehorn our issues into a standard template that we were provided. Using only the “given, when, then” Gherkin format, we didn’t get a chance to fully express what we wanted done. Elaborating more in the initial issue will help our focus and prevent worrying about adjacent, unrelated issues, solely due to thinking about each problem in more detail. For example, our stubs didn’t include any testing as part of the definition of done, but luckily we felt that this was reasonable and included them, rather than creating a new issue. I am of the opinion that for software to be complete, some testing should be associated with it. We will create a nightmare down the line if we aren’t careful with this, and should be more clear when defining our issues.

Much of our work was also done as a team, together in the same room. This forced us to remember to document our discussions and decisions in GitLab after the fact. We could have been more diligent in this regard. Although many of the solutions seemed obvious to us, documentation on our reasoning could be important for future developers. I enjoy working in person with a team because it facilitates quick discussion, but I feel we should either discuss more over GitLab or hold each other accountable for documentation after a decision is made as a team.

We are all feeling pressure to finish something we are proud of by the end of the semester. I think this contributed to some of the worrying and long discussions we had on features.

Making matters worse, was that other teams were likely having the same issues we were in adjusting to the new project. I think we handled this rather well and had some good back-and-forth about API design and the features we were planning on finishing. Again, this could have been better documented on GitLab for future reference. Some of this occurred in Discord, and will be lost in a sea of other messages. The less-obvious decisions were luckily documented in GitLab, such as the design of the ApproveGuest Module API. I would have liked to see more back-and-forth between our two groups in the discussion, instead of an abrupt approval of the feature.

This was a short sprint with an emphasis on learning, so thankfully we will be able to improve on these issues and focus on our strengths in the next longer sprint, which should get us close to a working product.

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.

Draw Your Own Map

This week, I’ve been thinking about an apprenticeship pattern that brought up something I had never considered. It opens with a quote suggesting people might say programming might not be sustainable in the long-term. News to me!

The crux of this pattern is that you won’t always be provided with the career path that you want. To be successful, you have to fight the urge to follow the path an employer gives you and take steps toward the path that you want. This is your map, and it can be redrawn at will. The goal is not to narrow your experience just because of a comfortable salary and your attachment to a fancier title.

This pattern seems to stem from the loss of many great developers to the world of management. The author seems a bit biased in wanting to prevent this. Unfortunately, many people might find their salaries necessary to maintain a lifestyle, or support a family. Furthermore specialization, or “narrowing” as they describe it, can be a good thing.

Of course, if narrowing is part of your map, I suppose it still fits with the pattern. But the book also suggests looking at the possibilities, which I agree with. After all, a map doesn’t have one path; it has many from which to choose. Listing many potential paths and following the one that looks best for you is likely a good tactic to get where you’d like to be in your career.

I’ve always felt a pressure to choose a single path and stick with it. Being able to change my mind is a nice idea. Luckily as far as I know now, I’ve mostly figured out my career path, but I will also follow the suggestion of the book to plan many alternatives. Experience in multiple different positions has given me insight into the aspects of each job I like. With this knowledge, I’m only interviewing at positions that I trust I can stay with long term, and I’ll only accept a position if I still believe that’s the case. Nevertheless, the rest of my career is a long time, and companies change.

The quote at the beginning of the chapter is meant to say that if people tell you to stick to one thing — to move to the safe, normal career path — you don’t have to. If a company prevents your own professional growth, it’s time to jump ship.

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

Ingenuity is often misunderstood. It is not a matter of superior intelligence but of character. It demands more than anything a willingness to recognize failure, to not paper over the cracks, and to change. It arises from deliberate, even obsessive, reflection on failure and constant searching for new solutions.

-Atul Gawande, Better

Learn how you fail is the first step towards learning how to win. The objective is to gain self-awareness of the reasons which lead to failure, and then make better decisions by reducing the inclination towards idealism. Being conscious that you cannot know everything, is the only way to become aware of how you fail. Knowing your own limitations, allows you to deliberately identify obstacles and concentrate on the goals you can reach.

Yes, you will fail! What’s more important is that you will win, once you know why you failed. The way to get the best out of it is to create a system to prevent the failure from happening again after you have figured out what went wrong. Creating a checklist or a type of protocol to prevent it from happening again when you find the weak point is another option to not go through failure again.

In this pattern what got my attention is the last sentence, which says “if you’re brave enough, get a friend to review your code, and see what else she can discover”. This is very accurate because everyone who writes code knows that there will be errors and it will take time to fix them. Even though you fix the errors you get, someone will find something else for you to fix, especially when you work in groups. This can be very tough because you feel like you are falling down. The reason why this happens is that we feed our brains to always win, and never lose. We reach the goal because we know how to do everything, and there are times when we do not reach the goal because there is something, we had no clue about. Is it time to step back? No! We should go through the failure, learn why you fail, and try again if you think you’re capable to fix it. As a conclusion, it can be very painful to learn how you fail, but in the end, you will have the skill to accept whatever life throws your way.

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.

The Deep End: Taking off my floaters

The definition of many of the apprenticeship patterns in the book are all in their title, being fairly obvious or sharing language used in idioms or other expressions. However, despite this, our authors usually find a way to expand on them for at least a page or two – most often by sharing a relevant story. Which is why I was shocked at how brief this particular pattern was, just a handful of paragraphs and another for our story. The brevity of pattern however did not lessen its impact on me, and I have come away with a renewed confidence. As someone who needs structure in order to work effectively, I imagine the deep end would involve a great deal of work and specifically responsibility – which I respond to quite well also.

I had already determined to seek out an internship or entry level position outside of my home state. Further, I wanted to join a company where I, of course, could be actually hired but one that would truly test the limits of my skills. Ideally, I would want it to be an internship though, cause as much as I want to make this change in scenery, I’m still hesitant to get stuck someplace I’m miserable. I think the true test will not just be getting a position away from home but finding a place for myself in that new place and maybe even gaining the confidence to stay and accept a job at the company – in the case of an internship.

I did find one internship that states that they will make no “intern-work” and one should be expected to work as a peer with the rest of their fellow employees; and on a massively used and well-known mobile application no less. I jumped at the chance to apply for this position, and I am incredibly hopeful I get it, as it is the perfect storm of conditions I am hoping for. Enrique’s story is still a little too dramatic for me to imagine emulating, but I hope if the opportunity to work in another country even presents itself, I will have the confidence to take it.

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 4: Retreat into Competence

When a software developer gets overwhelmed by the complexity of their current project or the fact that there is so much they don’t know, it is okay to “retreat into competence”. In the face of a challenge that seems insurmountable, taking a step back to see how for you’ve come and what you have accomplished is okay. While retreating into competence can be the right prescription for times like these, it is important to use the traction gained while retreating to propel yourself beyond where you first had stopped.

The title of this pattern almost seems contradictory to the whole concept of becoming a software craftsman. A software craftsman should always seek to move forward in their knowledge and career, why would the authors be telling us to retreat? While being able to continuously march forward indefinitely, steadily increasing project complexity and your responsibilities would be ideal, it almost never works like this in the real world. I find this pattern to be quite important, because without it, it seems that one would be going directly against the principles of a software craftsman to step back from a problem and retreat into competence.

One thing to note is I feel like it is especially easy to fall back on this pattern too much. If you consistently find yourself pressing the “eject” button whenever you reach a problem you might not know how to solve yet how will you ever go forward. It is important to set constraints on how long you can retreat in order to protect yourself from truly going against the principles of software craftsmanship and living a career filled with mediocrity. This is a powerful pattern, use it responsibly.

I feel like this pattern can be used in many situations in order to get over hurdles in one’s career that seem too great. Allowing yourself to create things you feel comfortable developing can help you regain faith in yourself and software development as a career. This is a pattern I have used myself and have seen great success with. When I find myself lost or over my head with a given problem, I like to solve small programming challenges, sometimes referred to as kata, in order to instill confidence in myself and remind myself how much I have improved over my career.

 

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.