Author Archives: howbrash

LibreFoodPantry

As I’ve been engaged with the internet for most of my life, I’m not entirely surprised, but I’m little unsettled by the Code of Conduct/Our Standards of the site. I didn’t realize with such a helpful type of engagement that standards such as these are as important as they seem to be. I suppose I wish this this type of medium was not as aggressive, as it would encourage a better attitude towards the people involved, but I’m familiar with the type of rhetoric people use on the web, and I am disappointed as it is needed to specify a certain type of behavior. I hope it is a failsafe rather than a direct shutdown of awful things that people say, but I understand the logic in case some awful people feel the need to post on the thread.

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Changing your Approach to Testing

I’ve always avoided familiarizing myself with the practice of testing, as the models and math required to really understand it seems to be quite daunting. On an episode of Coding and Cocktails by the name of Changing your Approach to Testing, Alan Richardson outlines a shift in how we should think about testing. The thing that immediately struck me was his outline of how testing in the industry is a tad lackluster – for the reasons that I avoided it in the first place. Apparently, people haven’t read up on past research and existing models to optimize their techniques of testing. Richardson references the difficulty of testing for beginners, and a disconnect between those that specialize in it versus those who are not as versed in the practice. I could sense a tinge of frustration from Richardson as he outlined a general lack of familiarity with the field, noting a soft disregard of math techniques like set theory, graph theory, probability theory, etc. He stressed the technical knowledge and deep analysis needed to effectively do the job, as well as the interpersonal communication techniques needed to address problems with colleagues. 

I found it particularly intriguing when Richardson referenced the need to effectively communicate with team members with the right language for that individual, especially in the case they don’t want your feedback. He noted that this could be seen as “people skills,” but further explained he actually studied psychology to better understand his interactions and optimize the team’s communicative efficiency. Quickly after however, Richardson pumps the brakes a bit to say one need not possess every good quality for being a tester – after all, what are teams for? As long as aspects like technical know-how, tenacity to finish and the ability to challenge people are represented in the team, members can work off others’ strengths while being valuable for their own. I must say this relieved a bit of my anxiety because of the huge pool of knowledge that must be drawn from, be it interpersonal or technical. 

Furthermore, he stressed the application of the tests, and how to go about asking the right questions when designing them. The example Richardson brings up is a basic question that should always be asked before any work is done – what is the goal of testing this specific product, and how should tests be implemented based on that goal? I believe he stressed this point because he asserted that a majority of the industry is relatively inflexible when adapting to different testing environments. As mentioned prior, this is most likely due to an unfamiliarity with the literature and research. 

As much as I enjoyed the perspective, and will definitely remember this episode for future reference and tips, it has only made me more terrified of testing. At least I know what I should be doing though, right?

Link – https://soundcloud.com/codingovercocktails/changing-your-approach-to-testing-with-alan-richardson

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Exploring Fintech Innovations

For this post, I tuned in to the Code and Cocktails episode by the name Exploring Fintech Innovations. Amancio Bouza, API thought leader and chief product officer at Contovista AG, represents an area in tech known as fintech, or financial technology. This field describes how technology can improve and optimize delivery and use of financial services. The episode delves into the intricacies of modern banking, and describes how woefully behind banking is in the modern era. Some institutions are so large they disregard the need for things like API implementation entirely, thinking that they have a few years before it becomes essential. To combat this, consultants like Bouza educate banks on the future necessity of the technology. 

For example, upgrading certain models of data analysis could provide statistics on customer preferences and expectations. Thus, this information coupled with machine learning has the potential to tailor specific financial advice to a user at an individual level. This could theoretically be massively beneficial to a bank’s constituents, by educating them on specific pitfalls and nuances of their financial situation, hopefully pushing them to accrue more wealth once they understand the data. Once the understanding of some patterns and validity of different models are smoothed out with machine learning, it also greatly helps with risk management for both the individual and the bank itself. 

In addition, Bouza notes that in the next decade or so society will shift to a more decentralized payment model, with debit and credit cards being phased out for account-based financial transfers. This is an infrastructure many larger banks need to adapt to, as Bouza notes the autonomy granted by such a shift will be an inevitable draw for modern day consumers. He references a “lack of urgency” in these large institutions, whereas startups who are on the razor’s edge of success or failure will scramble to be ahead of the curve of general tech implementation to keep up with the market. In the classic capitalistic train of thought, they consider themselves too big to fail.       

I think it’s also important to mention that people like Bouza are far from wanting to totally restructure the system. He’s working to educate existing entities and give them the tools to prosper in the coming future – tools that will benefit both the institution and the consumers. By incorporating even a small portion of Bouza’s suggestions, people can take advantage of the autonomy given to them to invest in hyper personalized interests. Autonomous finances have the ability to make each consumer the most wealthy and frugal that they have the potential to be, which is a net win for everyone involved.

Link – https://soundcloud.com/codingovercocktails/exploring-fintech-innovations-and-trends-with-amancio-bouza

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

The State of APIs in 2021

I recently discovered a podcast by the name of Coding over Cocktails, and they’ve done some excellent interviews with professionals in the field that specialize in API design. Evidently, the infrastructure of APIs are poorly maintenanced in many cases, as the importance of the practice has not yet hit the general understanding of how important they will come to be in future design strata. Matthew Reinbold, the interviewee on the episode titled The State of the API in 2021, asserted that there are a few key ways to see the “articulated vision” for how APIs interact and benefit future implementations of software. 

Reinbold outlined the need to be able to articulate how technological modularity is a strategic boon to the industry. While at the moment API design is proverbially left on the cutting room floor, he stressed the growing importance of integrating the practice as a cornerstone of future project endeavors. Referencing the pandemic, he cites a slew of examples pertaining to the cultural shift in society and the changing needs of consumers. For example, if an API was properly implemented for a given company, they ended up being months ahead of other organizations who failed to recognize the importance of the practice. These cultural shifts like curbside pickup are now a staple in modern business practices, and are here to stay for good.

API implementation promotes independence for consumers and resiliency to change for businesses, but at the moment are a “it would be cool if we had that” type of implementation in most projects.

Reinbold goes on to say that work culture norms are the primary thing that has to change before executives see the potential gain from incorporating such software. Changes to management would undoubtedly be the primary driver, but Reinbold also stresses the agency that lower tier employees don’t think they have in the industry. He uses the comical and stereotypical image of a computer geek living in a basement, where all one has to do is “throw pizza and sugary drinks down the stairs and code comes out.” In reality however, Reinbold argues that younger workers or “new power” feel helpless in the face of their superiors, or “old power.” But the mantle of leading change, Reinbold states, is simply finding the correct skills and techniques to do things better, and to try and get one’s colleagues intrigued with the implementation. The dynamic between new and old power is irrelevant if genuinely good ideas and leadership are explored at all levels. 

Either way, it was fascinating to hear about something we studied in class as the next step in tangibly improving our technology and quality of life. 

Link – https://soundcloud.com/codingovercocktails/the-state-of-the-api-in-2021-with-matthew-reinbold

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Teamwork in the Industry

So I know I’m quite late to the topic, but way back in week 1 or 2 we went over the POGIL roles, responsibilities and basic structure. This for me has always been about learning to work in a team, regardless of the assigned jobs on the card – and I have to admit I’ve always had a hands off approach. I wouldn’t say I’m a bad team member, just an absent one. I wasn’t always engaged, and just wanted to meet some arbitrary requisite for a good enough grade. I’ve obviously adapted as projects and activities got harder, but this podcast episode seems to have broken me out of that passive mindset into something much more productive.

There is a bit of a disconnect here from myself to the podcasters, as they are experienced developers with years of managing experience, but nonetheless I think it helped me glance into a world that I knew absolutely nothing about. Kind of like a peek behind the curtain of what I should be expecting. My greatest takeaway is always defer to someone who has even a tad more expertise with a certain context. There’s simply too much to keep up with, and in order to do your job effectively, one must make a choice to lean into a specific type of architecture. Just be good at what you’re supposed to be good is my takeaway, I guess. Other peoples’ expertise will help whatever the team is working on, and your personal experience will almost always prove to be invaluable at some point in the project.

In addition, I think I’ve picked up a habit of deferring to other peoples’ techniques when solving a problem. I of course will point out if I think I see an error or bug, but it gives me a sense of wonder seeing how many different solutions people can come up with to a singular problem. There is so much ingenuity inherent to coders that it’s never a good idea to say “this is the way things should be done.” My father is an architect who advises some up and comers, and when I ask him, he is regularly annoyed with staff for not doing things “the right way.” I love the guy, don’t get me wrong, but after listening to the episode I have to say that this technique is too suffocating. Just like in architecture, writing code is an expression of will or intent through creation. To limit that in either capacity is unhealthy for the people who would pour their heart into the work.

I suppose that’s a bit philosophical, but nonetheless it’s a lesson I’m glad that I’ve been exposed to. Other nuggets in the episode are tips on efficiency and cohesion, but these two concepts are what really stuck with me.

Link to Episode – https://content.blubrry.com/completedeveloperpodcast/CDP-Episode0319_Your_Code_Sucks.mp3

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Introductory Post

Hello hello, testing to see if I finally got this thing working. Looks like this should serve as another archive for my dumb words. Hopefully I check in from time to time after this course and read up on what I was struggling with. Or maybe somebody will stumble across a problem that I’ve solved and posted about – who knows?

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.