This week, I will be talking about the differences between coding and hacking, some of the confusions associated with them, and what your skill set should look like if you are learning about being a hacker. One question that will receive lots of attention is, “Do I need to learn coding to become a hacker?”

Let’s jump right into this. First, it’s important to note that coding and hacking are closely tied, but have important distinctions. Coding is the act of writing machine instructions, or code for a computer, which can be done in many different languages. Hacking, on the other hand, is the act of identifying and exploiting weaknesses in a computer system or network, usually to gain unauthorized access to personal or organizational information (to put it simply, you are breaking in). Hacking is not always a malicious activity, and there are actually several examples where hacking is used for good, like with penetration testing. Unfortunately, the term has garnered mostly negative connotations for its association with cyber-crime. It is important to remember that hacking is a tool–where it is not the tool that matters, but rather the intention of its user (what they wish to do with the tool).

Without a doubt, coding is a prominent part of hacking that has helped shape what it looks like today. If you are trying to learn about hacking, or are interested in taking part yourself, you would likely be doing yourself a disservice by having little to no prior knowledge of coding, because of how intertwined they are–but it is not absolutely necessary. In fact, there are multiple forms of hacking that require little to no coding skill. For example, social engineering is a type of hacking that focuses on the social, human aspect of security rather than the technical aspects. These attacks rely on human nature rather than code, and aim to manipulate people into compromising their personal security, or even the security of an entire network or organization they may be a part of.

In the podcast, Chuck raises an interesting question about having basic, fundamental knowledge of coding (specifically mentioning functions and classes) and asks if it’s really necessary to go much further than that if you are trying to become a hacker. John responds, “You don’t need to go much further beyond that. When people ask [that] question, I always say no, but with a disclaimer that you should learn some programming, but you don’t need to learn absolutely everything… I am not by any means a software engineer or architect, but I can script; I can write a loop that might brute-force passwords… and you don’t need to know a lot of hardcore, complex programming concepts for that. You just need to know the basics for that.”

John makes some very good points as the show continues, and focuses on how a lot of the basic, rudimentary skills in programming are often the ones that require the most practice, because of their importance, and because of how frequently they are used to build more complex pieces of code. He believes that the best way to get that practice is by immersing yourself in the world of hacking and trying to solve those problems with the skills that you have.

In conclusion, coding and hacking, despite being so closely intertwined, have some very distinct differences, and as it turns out, you may not need to know as much as you think you do about coding in order to start learning about hacking or becoming a hacker yourself. Although you may not need to know everything there is about programming, having some rudimentary knowledge is really all that it takes for you to start and branch out from what you have.

This episode can be watched in full, for free here on YouTube: https://www.youtube.com/watch?v=T7AaBcNj-mA&t=0s

From the blog CS@Worcester – Owen Santos Professional Blog by Owen Santos and used with permission of the author. All other rights reserved by the author.

This week, I have selected a blog about the concept of Software Testing as this is a topic of focus in our course. Upon reading this article it became very clear to me that – although I have used unit tests and other simple strategies – software testing has many important aspects that I am not familiar with. The post titled, “Software Testing 101: Get started with software testing types” was written by The Educative Team for their blog Dev Learning Daily which can be found here.

This blog is able to highlight the many different software testing methodologies and cycles that are used by developers throughout the development life cycle. At a high level, software testing is used to evaluate/correct program functions, ensure that the build meets the customer requirements, and confirm that integration of the software is possible/compatible with other components and other systems. Most of us are familiar with the reason we must test our software prior to production, but knowing how to test completely and comprehensively is the most vital aspect.

The post touches on Black Box vs White Box testing, Automation vs. manual testing, Functional testing methodologies, Non-functional testing methodologies, and some useful general information and best practices related to the software testing lifecycle. One topic that stuck out to me was the difference between functional and non-functional testing and the processes each follows. I think that the majority of my testing experience (if not all) has been rooted in functional testing even if I did not know it at the time. From this post, I have learned that functional testing has a cycle within itself focused on testing specific program behaviors and the process starts with unit testing to test small components of a program, then to integration testing to ensure components can work together, then system testing to ensure a full build is functioning properly, and finally acceptance testing with alpha testing being completed with internal users and beta being completed with external parties to get additional feedback without bias. There are many other types of testing mentioned that I had zero experience with, but after learning about them I am looking forward to when and how I can begin to use these new tools to help me write useful code.

Our projects can benefit on many different levels by implementing testing in their development cycle like ensuring minimal user experience conflicts and meeting customer expectations of completely functional requirements. I was able to learn about the many different kinds of testing that exist, in what circumstances they should be used, and how to implement them to get results in a real situation. The writers discussed the process for testing which I think I can summarize very simply as:

1. Determine what needs to be tested
2. Create a test case
3. Check result – Success? Move on! vs. Error? Solve it!

We can acknowledge that testing can become much more advanced than these steps, but the value gained makes it worthwhile.

From the blog CS@Worcester by cameronbaron and used with permission of the author. All other rights reserved by the author.

In the world of Scrum, navigating uncertainty and complexity is a key challenge. One practice that helps teams manage this is the use of “spikes”—a technique for addressing uncertainty by dedicating time to research, exploration, or experimentation. A blog post titled “Navigating Uncertainty: Crafting Effective Spikes in Scrum” provides a detailed examination of how to create and manage spikes effectively in Scrum. The post breaks down the concept of spikes, offering clarity on when and how to implement them in a way that maximizes value while minimizing disruption to the team’s flow.

A spike is essentially a time-boxed period where a team focuses on gathering information, resolving technical debt, or experimenting with a new technology, rather than delivering functional product increments. This is essential for reducing risk and uncertainty, particularly when the team faces unknowns that could impact the project’s success.

I selected this blog post because it directly relates to Scrum’s emphasis on adaptability and continuous learning. Understanding how to manage spikes effectively is crucial to achieving that adaptability. It complements key elements of the Scrum framework covered in our class, especially the Sprint Cycle and the role of the Product Owner in prioritizing work. In a Scrum environment, having a strategy for managing uncertainty aligns with the framework’s focus on iterative progress, continuous improvement, and adaptability.

Reading the blog post helped me better understand how spikes function within Scrum. One important takeaway is that spikes are not a sign of poor planning but rather a proactive strategy for tackling uncertainty. In previous projects, I often found myself overwhelmed when faced with unknowns.

The concept of spikes is a useful technique within Scrum for managing uncertainty. Reducing risk, improving decision-making, and maintaining focus on delivering valuable increments of work; ensuring that the Sprint Cycle remains productive and focused on achieving the Sprint Goal.

For more information, you can read the original blog post here.

From the blog SoftwareDiary by Oanh Nguyen and used with permission of the author. All other rights reserved by the author.

This week, I found a Reddit post from just about a year ago on clean code. The post is asking people basically how they feel about “clean code”, so I thought it’d be interesting to hear some people’s takes on clean code and what they may like or dislike about it. The post links an article, “Goodbye, Clean Code” and while I will really just be getting the Redditor’s thoughts/opinions on the article and their overall takes on clean code, I will still post this article at the end of the blog as well.

The top comment on the Reddit post tries to sum up the article by saying it’s more or less about not passing judgment on someone’s written code without knowing the tradeoffs first. Doing a quick read through of this article confirms this, which I believe is a great point to make. Code may not ALWAYS be the cleanest, but before you go ripping into the structure of it, you may want to try to understand it first. A reply to this comment, which was the most liked reply so probably the most agreed upon point, was that coders should write comments when a line or lines of code are dirty due to a tradeoff. This, I completely agree with. If the code is recognizably dirty and it’s due to something really out of your control, I find it perfectly acceptable to write a comment explaining this so there is no confusion.

Another comment I found, which was within a thread of comments, was talking about “Clean Code” written by Uncle Bob. We learned a lot about Bob’s ideas on clean code during class, which was very beneficial. I will note though, he came across as very strict and stubborn on the rules. A comment in this thread clarifies this though by explaining how Uncle Bob, very early on in chapter one, states that people may “violently disagree” with him and that’s completely okay. So while he may be stern under his own volition, he understands where some people may draw a line.

Reading through all of these comments, I came to realize that while yes, clean code certainly is important, it’s only important to a degree. There are going to be projects where you may not be able to keep the code super clean, and you should then shift focus to keeping it as clean as POSSIBLE, and perhaps commenting on areas where it just wasn’t possible. It also is not the end of the world as some people may make it out to be, if you are unable to keep it extremely clean.

https://www.reddit.com/r/programming/comments/180evou/what_is_your_take_on_clean_code/

https://overreacted.io/goodbye-clean-code/

From the blog CS@Worcester – RBradleyBlog by Ryan Bradley and used with permission of the author. All other rights reserved by the author.

Hello, this is my second blog post. Today I wanted to talk about something I learnt about in my Software Process Management class. The topic of this blog is two methodologies in software development; the waterfall method, and the Agile method.

For those who do not know, the waterfall method is a very “set-in-stone” methodology, where each part of the software development process is pre-determined with deadlines and time constraints. Something I dislike about this methodology is the lack of communication between the company and the people creating software for them. I think it is very important to have a strong connection during the whole process, not just the start and the end. The Agile method is more flexible. There are pre-determined steps, just like in the waterfall method, however, they are conducted in much shorter time intervals and repeated several times. This allows more communication between customers and developers.

In my opinion, both methodologies have their own uses, which is something we talked about during a class discussion. We were asked to speak about which methodology would be better in different situations. I think that for a large-scale community/government project (such as building a bridge), the waterfall method could be useful since a lot of communication is not needed with a certain customer. For projects where the developers are creating an app/product for a company, I think Agile outshines the waterfall methodology by far, due to the reasons listen in the above paragraph.

I also used this website to learn a bit more about both methodologies: Agile vs. waterfall project management | Atlassian

This website reinforced my ideas and outlook on both methodologies. It highlighted that in the waterfall method, you are unable to move forward without completely fulfilling the first “phase.” It also went into detail on how in the Agile methodology is more flexible than the waterfall methodology. The waterfall methodology is much less able to be changed in any way, and it is a very linear methodology. There are also some helpful images on this website which I would recommend checking out to visualize both methods!

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

This article by
Jeff Gothelf asks the question “Is Agile finally over?” after 20+ years of
implementation to tech field. He argues that even though Agile’s widespread
adaptation hasn’t got the result that Agile was intended for. Many companies
claimed to be “Agile” as they copy each other, but the implementation of it was
shallow or almost non-existent to make changes according to it. Therefore, he
says that agile does not seems working as companies try to make employee follow
set of rules instead of working in following the basic principles of Agile. He
concluded that organizations need to focus on true organizational agility
rather than rigid framework adoption.

This article
caught my attention while searching through the internet as it criticizes Agile’s
current status in the business world as ideal of agile does not really fit in
reality in organization experience. The vague promises and core ideas are often
overlooked to the ‘wants’ of either customer or the organization. The output is
never about efficient program but a program that works made in short amount
time. In the end, it feels like the organization’s internal culture and goals
must align with the methods it adopts to fully be efficient which does not seem
to work for a lot of groups that ‘follows’ agile. Learning that to me, teamwork
following agile principle is hard from top-down management as they try to
follow rules made by the organization to follow the given framework, that is
why agile is not working for many in my opinion.

This got me to
reflect that to practice agile in the future, that I need to try to make sure
that if the company says they do ‘agile’ format for development, I need to check
with others so that if they want ‘agile’ following company standard or the real
agile that I learned in class. I feel like this way even more because when I work
at a part time job, company wanted to follow xyz because and it was annoying
and required lot of process which contradicted for the speed of work they
wanted us to work on. Therefore, no one really followed by the book or the procedures
were implemented shallow, so it was not effective at all, I think this was the same
case for agile in the long run. It feels like agile manifesto was built for
small teams or companies where they could discuss things multiple times in
small groups not to be used by large companies as it will be always shallow or
just another term to company’s rules to schedule how work is done. Therefore, I
feel like widespread use of agile is dying down unlike what the author says
because no one tries to keep that rule in big companies. 

https://jeffgothelf.com/blog/is-agile-over/

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

This article by
Jeff Gothelf asks the question “Is Agile finally over?” after 20+ years of
implementation to tech field. He argues that even though Agile’s widespread
adaptation hasn’t got the result that Agile was intended for. Many companies
claimed to be “Agile” as they copy each other, but the implementation of it was
shallow or almost non-existent to make changes according to it. Therefore, he
says that agile does not seems working as companies try to make employee follow
set of rules instead of working in following the basic principles of Agile. He
concluded that organizations need to focus on true organizational agility
rather than rigid framework adoption.

This article
caught my attention while searching through the internet as it criticizes Agile’s
current status in the business world as ideal of agile does not really fit in
reality in organization experience. The vague promises and core ideas are often
overlooked to the ‘wants’ of either customer or the organization. The output is
never about efficient program but a program that works made in short amount
time. In the end, it feels like the organization’s internal culture and goals
must align with the methods it adopts to fully be efficient which does not seem
to work for a lot of groups that ‘follows’ agile. Learning that to me, teamwork
following agile principle is hard from top-down management as they try to
follow rules made by the organization to follow the given framework, that is
why agile is not working for many in my opinion.

This got me to
reflect that to practice agile in the future, that I need to try to make sure
that if the company says they do ‘agile’ format for development, I need to check
with others so that if they want ‘agile’ following company standard or the real
agile that I learned in class. I feel like this way even more because when I work
at a part time job, company wanted to follow xyz because and it was annoying
and required lot of process which contradicted for the speed of work they
wanted us to work on. Therefore, no one really followed by the book or the procedures
were implemented shallow, so it was not effective at all, I think this was the same
case for agile in the long run. It feels like agile manifesto was built for
small teams or companies where they could discuss things multiple times in
small groups not to be used by large companies as it will be always shallow or
just another term to company’s rules to schedule how work is done. Therefore, I
feel like widespread use of agile is dying down unlike what the author says
because no one tries to keep that rule in big companies. 

https://jeffgothelf.com/blog/is-agile-over/

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

This article by
Jeff Gothelf asks the question “Is Agile finally over?” after 20+ years of
implementation to tech field. He argues that even though Agile’s widespread
adaptation hasn’t got the result that Agile was intended for. Many companies
claimed to be “Agile” as they copy each other, but the implementation of it was
shallow or almost non-existent to make changes according to it. Therefore, he
says that agile does not seems working as companies try to make employee follow
set of rules instead of working in following the basic principles of Agile. He
concluded that organizations need to focus on true organizational agility
rather than rigid framework adoption.

This article
caught my attention while searching through the internet as it criticizes Agile’s
current status in the business world as ideal of agile does not really fit in
reality in organization experience. The vague promises and core ideas are often
overlooked to the ‘wants’ of either customer or the organization. The output is
never about efficient program but a program that works made in short amount
time. In the end, it feels like the organization’s internal culture and goals
must align with the methods it adopts to fully be efficient which does not seem
to work for a lot of groups that ‘follows’ agile. Learning that to me, teamwork
following agile principle is hard from top-down management as they try to
follow rules made by the organization to follow the given framework, that is
why agile is not working for many in my opinion.

This got me to
reflect that to practice agile in the future, that I need to try to make sure
that if the company says they do ‘agile’ format for development, I need to check
with others so that if they want ‘agile’ following company standard or the real
agile that I learned in class. I feel like this way even more because when I work
at a part time job, company wanted to follow xyz because and it was annoying
and required lot of process which contradicted for the speed of work they
wanted us to work on. Therefore, no one really followed by the book or the procedures
were implemented shallow, so it was not effective at all, I think this was the same
case for agile in the long run. It feels like agile manifesto was built for
small teams or companies where they could discuss things multiple times in
small groups not to be used by large companies as it will be always shallow or
just another term to company’s rules to schedule how work is done. Therefore, I
feel like widespread use of agile is dying down unlike what the author says
because no one tries to keep that rule in big companies. 

https://jeffgothelf.com/blog/is-agile-over/

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

This article by
Jeff Gothelf asks the question “Is Agile finally over?” after 20+ years of
implementation to tech field. He argues that even though Agile’s widespread
adaptation hasn’t got the result that Agile was intended for. Many companies
claimed to be “Agile” as they copy each other, but the implementation of it was
shallow or almost non-existent to make changes according to it. Therefore, he
says that agile does not seems working as companies try to make employee follow
set of rules instead of working in following the basic principles of Agile. He
concluded that organizations need to focus on true organizational agility
rather than rigid framework adoption.

This article
caught my attention while searching through the internet as it criticizes Agile’s
current status in the business world as ideal of agile does not really fit in
reality in organization experience. The vague promises and core ideas are often
overlooked to the ‘wants’ of either customer or the organization. The output is
never about efficient program but a program that works made in short amount
time. In the end, it feels like the organization’s internal culture and goals
must align with the methods it adopts to fully be efficient which does not seem
to work for a lot of groups that ‘follows’ agile. Learning that to me, teamwork
following agile principle is hard from top-down management as they try to
follow rules made by the organization to follow the given framework, that is
why agile is not working for many in my opinion.

This got me to
reflect that to practice agile in the future, that I need to try to make sure
that if the company says they do ‘agile’ format for development, I need to check
with others so that if they want ‘agile’ following company standard or the real
agile that I learned in class. I feel like this way even more because when I work
at a part time job, company wanted to follow xyz because and it was annoying
and required lot of process which contradicted for the speed of work they
wanted us to work on. Therefore, no one really followed by the book or the procedures
were implemented shallow, so it was not effective at all, I think this was the same
case for agile in the long run. It feels like agile manifesto was built for
small teams or companies where they could discuss things multiple times in
small groups not to be used by large companies as it will be always shallow or
just another term to company’s rules to schedule how work is done. Therefore, I
feel like widespread use of agile is dying down unlike what the author says
because no one tries to keep that rule in big companies. 

https://jeffgothelf.com/blog/is-agile-over/

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.