Your First Language

I always feel that if you are better at the first language, the easier it is to learn the next one.

I learned Java in my sophomore year, and then I went to learn C, which felt easy. Because the logic of computer language is interchangeable. For example, if you learn English well, you will find some similarities between French and Spanish. Although French and Spanish maybe your second language, you will learn them much faster than non-proficient English learners. I think this applies to computer language learning as well.

Each language gives you the opportunity to use different patterns to solve problems. In the process of moving beyond your first language, you should look for opportunities to learn languages that approach problems in very different ways. Apprentices who are comfortable with object-oriented languages should explore Functional’s programming language. Students of dynamic typing should delve into static typing. Apprentices comfortable with server-side programming should take a look at user interface design.

You should not be “married” to any particular technology but should have a broad enough technical background and experience base to be able to choose the right solution for a particular situation.

Many people say Java is good because it is suitable for many kinds of software programming. Some people also say that C++ is good because its language is more advanced than Java; there are also people who have learned that learning C++ to learn Java or very simple. I personally hate to talk about what language is best, every use situation has a language that works best for it. Or if you have learned your first language well, mastering it is also a good option. But there are certain situations where C really has the best solution than Java, so we write our software in C. At this point, there is no need to stubbornly think that I am good at Java and I have to use the language I am good at to solve this problem. 

The spirit of craftsmanship is that you strive for the best in what you are good at, but in certain situations, we can’t stick to the rules. Modern society is a utilitarian society, we need to maintain the spirit of artisans while learning to adapt to the society.

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

Static vs. Dynamic Testing

In this post I will be talking about what static and dynamic testing is and how they differ.

Static testing’s objective is to find and prevent any errors in the early stages of a software’s development. This sort of testing is done without execution of the code. Some methods of static testing are manual and/or automated reviews of the code, requirement documents and document design. Some examples of the documents reviewed in this stage are test cases, source code, user documents and web page content. This is primarily verification.

Dynamic testing’s objective is to check the functional behavior of software, how it conforms to the business requirements and fix any errors that have been found. Its system, its usage and its performance are tested through execution of code. This sort of testing is done at any stage of the testing life cycle and can be white or black box testing. Most of the time it is validating the outcome is what is expected.

Some key differences between the two types of testing are that in static testing you do not execute the program, you analyze and review the documents and code. In dynamic, you execute the program and analyze the behavior. The goal of static testing is to prevent defects when developing the software while the goal of dynamic testing is to fix the defects. The costs of finding defects in static testing is less than of dynamic testing and the return on investment for static is greater than of dynamic. This is because of the development stage that each are executed in. Since static testing is done in the early stage before compilation it is preventing before it happens. Since dynamic is performed at the end of the development stage, you are only fixing technical debt.

Techniques for static testing include technical reviews, inspection, code reviews, and walkthroughs. Techniques for dynamic include unit testing, integration testing and system testing. Ultimately, static testing involves some sort of checklist and process and dynamic testing includes test cases and execution.

Source: https://www.guru99.com/static-dynamic-testing.html#:~:text=Static%20testing%20is%20about%20the,testing%20is%20performed%20after%20compilation.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Be The Worst

This time the pattern that I would like to write about is Be the Worst. I always thought about which is better, to be the worst on the best team or the best on the worst team? This pattern explains that is better to find a stronger team where you are the weakest member and have room to grow. When you are in a strongest team you learn from them and makes you feel perform better. The other members of that team will often prevent you from making mistakes, and help you recover from mistakes so smoothly that you won’t realize that you may not be learning as much as you think. 

I have been part of both cases. I have practice being the best in a group and vice versa and I would choose to be the worst any day. Personally, I’d rather be the weakest player in a strong team. That makes me look like a better player, and it helps me develop the skills to become a better player. When I worked in a project with some of my teammates that had more knowledge and experience than me, I was able to improve myself and learn some tips than books or videos would show me or learn you.

When you are in a group like this it is easy to forget, and you start compare yourself with the best and sometimes you feel stupid or not doing enough. I felt that in more than one occasion, but this pattern has reminded me another thing that I have forgotten. Your goal is to measure your abilities and find ways to be better than you were yesterday. We’re all on the same journey and comparing ourselves to others is useful only when it allows us to find ways to help each other improve.

I believe every pattern has its own good and bad sides. You can’t stay for a long time being the worst in a team because the phase where you learn ends and team moves on and so do you.  Being the worst on a team of outstanding developers can’t be compensated for with environment, equipment, or money. You can’t compensate for learning next to people who have already traveled the path and know how to avoid the holes on the road ahead. Pairing with great software developers is invaluable.

Source:
Apprenticeship Patterns by Adewale Oshineye; Dave Hoover, Be the Worst

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

The book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye covers multiple patterns important to being an apprentice. One of these patterns is called “Expose Your Ignorance” and centers around the issue of not knowing enough about a topic kind of important to the task at hand. Many people’s first instinct is to feign competence in order to avoid worrying their peers and suffer through embarrassment. The pattern instead suggests that people admit their shortcomings and ask questions. It might be hard to do but the benefits far outweigh the risks like learning important information sooner rather than later for example. Doing this has the added benefit of developing the learning ability through enforcing a “not knowing” mentality which just means to approach a situation if you were a novice. This mentality pushes an individual to broaden their horizons rather than becoming an expert on a single subject in a specific context. It also allows one to form strong relationships since this will be showing others your learning ability and flexibility.

I’ve had trouble “Exposing My Ignorance” for most of my life since again, most people’s first instinct is to feign competence. And of course, that wouldn’t work out since people would get mad at me for not knowing something and I’d end up barely learning anything. But I would still keep up this behavior until either late high school or early college mainly because there were some people in my life that would get mad at me for even asking questions. The reason why I broke out of that habit is because as I got older, I realized that there was so much I had no clue of doing. So, I started asking questions without caring what other people thought because I wanted to learn. For example, I wanted to learn to do my laundry so I just asked my mom to teach me and now I still do my own laundry. The same principle applies to software development; If you either don’t know something or aren’t confident in your knowledge on a subject, ask questions since there’s no real harm in doing so.

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

Concrete Skills

The “Concrete Skills” pattern in Apprenticeship Patterns can be understood, at a baseline level, to be the process of obtaining skills to achieve acceptance into a group of software professionals. This pattern elaborates on how the acquisition of skills has both intrinsic and extrinsic value in differentiating you as a potential candidate for the position in question.

Upon reading the Context and Problem section of this pattern, my brain immediately conjured up a preconceived notion as to what I should expect from the rest of the article to follow. In many respects that notion was correct; I was anticipating a description of the courting ritual between the gatekeeper(s) and the applicant. In the previously mentioned ritual, the applicant admits to humility but shows sufficient competence and desire to improve to the gatekeepers who either make an affirmative judgment leading to the conditional induction of the neophyte, or a rejection leading to the applicant walking away with redoubled determination to step back into the fiery crucible of honing their craft so that they may be better prepared the next time for the acceptance ritual. I embraced this struggle personally in my desire to create music; having been composed of solely aspiration and perspiration, I fell below the musical competency threshold during the audition process several times but I came back with a vengeance and was able to squeak out acceptance.

In the context of software development, Hoover and Oshineye are designating the in-group as a software development team who has a hiring manger that will be vetting your technical skills rather than several bandmates vetting your musical chops. The authors make mention of the concept they borrow from someone else called “day care”, and this is to illustrate the mentality of the gatekeeper who will ultimately be held responsible for the hiring and subsequent failings of the neophyte in an environment where time is software and software is money. I also appreciated that, aside from the intrinsic nature of possessing the technical skills, the authors made sure to mention that the need to develop these skills is also for the extrinsic value of passing human resource applicant filters and “managers who construct teams by playing buzzword bingo”.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Revision

Context

The following post will be in reference to Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye chapter 1 and the introductions to chapters 2 to 6.

This revision is to decrease word count.

Opinion

“Most people won’t have an opportunity to work in a formal apprenticeship where they are being mentored by software craftsmen. In reality, most people have to claw and scratch their apprenticeships out of less-than-ideal situations. They might be facing overbearing and/or incompetent managers, de-motivated coworkers, impossible deadlines, and work environments that treat novice developers like workhorses, storing them in small, rectangular stalls with a PC and a crippled Internet connection. (Apprenticeship Patterns)”

I have many options for what to discuss, so I’ll be discussing the current state of the job environment. Due to numerous factors, students are graduating college and finding that, in order to get an entry level job, they need experience. In order to get experience, they need an entry level job. It’s a catch-22.

Every issue is infinitely complex. There are numerous variables that have caused this situation to exist and it would be impossible to adequately address all of them. So, I will focus on a few such as the abundance of college degrees. Just as every issue is complex, every good thing has bad aspects and every bad thing has good aspects. Most people can agree that a population with college educations is a positive. Education provides opportunities. However, this is bound to also have unforeseen consequences.

Employers want to hire people that will be the best for the position. This is essential for the survival of the business and the economy at large. Not everyone is fit to be mathematician, for example. So, employers must discriminate between candidates in order to determine those who are best fit for the position. One large determining factor is a college degree. Having a degree in a subject implies familiarity and some level of expertise in said subject. However, it doesn’t end at employers. Those applying for positions realize the advantage of a degree and so an entire generation of parents have been pushing their kids to get a degree, with the goal being a decent job.

This drive for degrees creates a huge supply of degrees and with the demand remaining roughly the same, the value of a degree decreases. If everyone has a degree, an employer can’t use it as a discriminating factor. So, they move onto others such as prior experience. The problem arises from the lack of supply of jobs and the huge competition for those jobs. We find that thousands of students are going to college now to get a degree they might not even use and end up in massive debt.

This is by no means a simple issue. There are a handful of helpful practices that can improve the situation. Pushing trade schools as well as colleges can lead kids down a successful path and decrease the supply of degrees, making them worth more. Government can decrease regulation to allow more small businesses to compete for workers. However, there will be no magical single solution to this problem and what it really requires is a societal discussion about college degrees.

Work Cited

“Apprenticeship Patterns.” Accessed February 22, 2021. https://learning.oreilly.com/library/view/apprenticeship-patterns/9780596806842/#toc-start.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Ch 1 and Ch 2-6 Introductions (Revised)

The book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye begins with its first chapter which centers on the concept and nature of apprenticeship. In it, the authors compare and contrast the apprenticeships of medieval Europe with the software apprenticeships of today. The following five chapters, of which I have read the introductions of each so far, focuses on individual concepts and attributes important to software apprenticeships. Chapter two focuses on “emptying the cup” or how an apprentice should set aside their existing knowledge in order to fully open themselves up to the different approaches of their colleagues and teachers. Chapter three reminds to not be too discouraged of the achievements of your peers as they’re still learning like the rest of us. Chapter four also reminds to not become too complacent or conceited and instead find ways to improve your weaknesses. Chapter five follows that up by advising that an apprentice should learn how to learn since software development is composed of two primary activities: learning and communication. Chapter six finishes off with the point that even though we live in an age where anyone can access limitless information through the internet, books still have some knowledge you can’t find online.

I mostly agree with the points made in the book save for the one in chapter six and even then, it’s mostly with the wording. The way the authors described their point made it seem that physical books have value outside of the internet in the information they have. This is despite the fairly likely chance that many of these books, such as Apprenticeship Patterns, already exist online in some form or another. I’m assuming that the authors only had sources exclusive to the internet like blogposts and websites in mind when comparing them to books. Taking that point of view in mind, I can see where they’re coming from especially with how easy it is to find inaccurate or outright wrong information. I’d go even farther than the authors though and suggest that people check the validity of their sources since physical sources can lie like online sources, the only difference is that it’s easier to lie with the latter.

Outside of the point in chapter six, many of the topics and attitudes covered I feel are not only important for software apprenticeship but also for any skill that an individual decides to devote themselves to. Optimizing one’s learning skills, constantly learning, constantly improving one’s weaknesses, not getting discouraged by the accomplishments of one’s peers, and opening oneself to other viewpoints are all extremely important to cultivating a craft. That’s because these skills all contribute to developing oneself into a well-rounded person, which in turn allows for an individual to learn and improve more quickly.

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

Concrete Skills

Concrete skills are something I feel as though I have an abundance, and simultaneously, a lack of. I guess this depends on what kind of skills are being referenced. If data structures, algorithms, or Leetcode is in question, I have some confidence. Not only are these topics I enjoy, but I also have solid knowledge in these areas. When it comes to automating tasks, or something more applicable to my current capstone situation, such as getting a strong grip on Docker and how each part of the project can be integrated with it, I feel… less qualified. 

The problem is, I think I can get to the technical knowledge I have, but only via the technical knowledge I am lacking. These barriers become apparent when working on a large project like the capstone. I look at the backend components, and I feel solid, even with little JavaScript experience. But picking up Vue.js makes me feel like I’m swimming in circles. There’s no point in making a backend without a frontend to support it, and I know this, but I’m not happy to confront it as it means abandoning my comfort zone for some crazy new frontend world.

          The learning pattern on concrete skills puts some much-needed pressure on me. It points out that I can have all the knowledge of theory and all the ability to learn quickly in the world, but if I can’t put real technical skills on a resume, I’ll never make it past the first round of hiring interviews. Rather than trying to find ways around the difficulties I face in everyday software development life, I should highlight my weaknesses and mark them down as learning opportunities.

          There has been a plethora of times in my CS career at which I confront a problem I have been avoiding and the knowledge I gain suddenly seems to apply everywhere. For example, last semester I learned the state design pattern, and because it came with some confusion, I dropped it quickly enough. Now, as I tried to make a Markov chain simulation in Java for my Math Modeling independent study, I realized a state pattern was a perfect fit. It took a couple hours, but I got it down and it feels great not only to have learned and used something new, but to know I have the knowledge to use whenever I need it going forward.

          I think my first focus should be some more surface level skills. As the chapter points out, the question, “If we hire you today, what can you do on Monday morning that will benefit us?” is one of the most important questions of the interview. If my best answer is, “Try really hard to get up to speed,” I’ll be job hunting for a long, long time. My new goal is to collect the skills I don’t know or feel uncomfortable with that are more common and focus my spare time on them. It will make daily life as a developer easier and take me further in my career faster.

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

RefinementCodeReview: A Review

Go check out the original article here! It’s great!

In Martin Fowler’s blog post titled, “RefinementCodeReview” he emphasizes the need to rethink the frequency with which developers review code. He points out that pre-integration reviews and pull requests, while important, should not be vital to the development process in the literal sense of the word. Fowler highlights the etymological reason we have collectively acknowledged that software is accurately named; it is soft, and like all malleable mediums, should be worked through from end to end. Fowler seems to suggest that a shift in lexicon from architectural comparison to Erik Dörnenburg’s town planning one would pay dividends in inspiring more frequent refactoring of older code. While this seems obvious, it’s a powerful distinction; if we approach old code like a large stone monolith carved with divine intentionality rather than a living, revisable set of rules used to build and expand, then we are certainly adding unnecessary apprehension around the development process.

“As soon as I have an understanding about the code that wasn’t immediately apparent from reading it, I have the responsibility to (as Ward Cunningham so wonderfully said) take that understanding out of my head and put it into the code. That way the next reader won’t have to work so hard.”

Martin Fowler, 1/28/2021 @ https://martinfowler.com/bliki/RefinementCodeReview.html

I found this quote personally compelling but also particularly salient when Mr. Fowler addresses the dreaded, yet somehow inevitable, scenario where a high-threat vulnerability in the code is exploited. He calls these rare-high-impact concerns and yields that truly no amount of testing will ever eliminate their existence but the process of running continuous and vigorous testing can make accepting a certain amount of risk from older or inherited code much more palatable. While the author doesn’t mention this pattern by name, he implies that these good practitioners of efficacious refactoring, who are more knowledgeable of a code base, who are better still at creating self-testing code, who are better even yet at continuous integration would create a virtuous cycle of software development.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

Breaking Out the White Belt (Disambiguation)

As someone who has been a caddy, industrial mechanic, butcher’s assistant, retail manager, letter carrier, web development intern, substitute teacher, and referee over the course of my life, it’s safe to say that I’m no stranger to breaking out the white belt. The chapter sets up the scenario wherein you’re a competent programmer with a narrower-than-desired field of knowledge and although your competency allows you to feel confident in your day-to-day operations, this coziness with your language or technology stack has limited your ability to wrestle with the novel in a meaningful way. The suggested solution is to embrace the unknown and throw away your preconceived notions about what it means to program or write software, actively avoiding the temptation to relate your previous world to the task at hand. The authors call this mindful approach to limiting context “maintaining a not knowing stance”, an ethos that I would argue is truly the heart of science and fundamental for discovering something new. The case here is that we (the readers) are software developers and the personal discovery is the new world of idioms, approaches, and paradigms that we will hopefully be able to synthesize and, upon achieving contextual competence, apply.

The pattern certainly confirms to me what I already know; being humble is an evergreen approach to learning, however the authors chart territory that I do not know in the chapter and that is the premise given at the outset where one hits a level of competence and plateaus there. I’ve not really been able to wrestle with any technology stack or programming language long enough where I feel competent or fluent to meaningfully contribute, let alone act as a guiding beacon for peers. While I may not be ready now to apply what I’ve learned in the pattern, if I imagined myself a competent C++ developer accustomed to the object-oriented programming paradigm, I would then make an attempt to learn a declarative paradigm, perhaps functional programming. Ultimately one’s next foray in software development will tend towards whatever is productive for their endeavors, occupational or personal and should likely reflect the adage of “picking the right tool for the job”.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.