Category Archives: Blog

Working as a Front end developer

Now that I have heard about people’s experiences working on the back end, I was curious about people’s experiences working on the front end. Reading personal experiences taught me a lot about working on the back end. You can learn a lot and avoid mistakes by seeing others take similar paths. Also, it can prepare you for problems that you may face in the future. Mistakes are inevitable but being able to adapt or being able to recognize it and fix it goes a long way. Working on projects especially those that have to do with coding errors is always a step away. You can try to get a step ahead on these problems by seeing other people work and implementing it on your stuff. That is why I found an article about working as a front-end developer. These articles are very engaging and always give me a new perspective.

This article is written by Selim Enes who has done freelance work in the past but is currently working as a developer. When he first started he was working on small things like CSS edits until he proved himself. One of his major projects was a blog project where he had to create the display of the UI. He was involved in all operations after 2 months. When he proved to the team that his code wouldn’t crash the project he gained access to the company’s main project. The company’s main project entailed a webinar application that used technologies like WebSocket. One thing that made him know he was going in the right direction was being able to develop features like push-to-talk by himself. There are some negatives to his work with his boss being very hasty on projects. He believes all tasks are urgent and make some work very stressful. Plus with the recent economic regression, he doesn’t believe he will be able to get a raise anytime soon. He has learned to have a full-stack blog project for himself and has an e-commerce project his about to start working on. He is working while also building his portfolio outside of work.

Reading this article was very insightful. It made sense that when you first start working for a company they won’t give you the keys to everything just yet. They ease you up into it until you have gained their trust. Working on his portfolio outside of work motivated me to do the same too. You can sometimes become complacent at your job because you have a living but you shouldn’t. You should always try to improve and hope to find better opportunities elsewhere

View at Medium.com
https://medium.com/@sellimenes/1-year-experience-as-a-junior-front-end-developer-39766fad5c34

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

Code Review

Source: https://about.gitlab.com/topics/version-control/what-is-code-review/

This article is titled “What is a code review?” As clearly stated by the title, the article explains the processes of code reviewing. “A code review is a peer review of code that helps developers ensure or improve the code quality before they merge and ship it.” Code reviews help in the identification of bugs, increase the overall quality of code, and enhance understanding of the source code. Code review, as suggested in the name, happens after a software developer has finished coding. Code needs to be checked before it is merged into an upstream branch for bugs or conflicts. A code reviewer “can be from any team or group as long as they’re a domain expert. If the lines of code cover more than one domain, two experts should review the code.” Adhering to a solid code review process allows for continuous improvement of code and aims to ensure that faulty code isn’t being implemented for customers/users to see and use. This process isn’t just important for the code itself, but also for all of the team members of a software development project. Whilst reviewing the code, meaningful knowledge of the source code is shared between team members to ensure that it is being implemented properly. The main benefits of the code review process are: the sharing of knowledge, discovering bugs earlier, maintaining compliance, enhancing security, increasing collaboration, and improving code quality. Code reviews allow for maintaining compliance because different developers have different backgrounds and thus different personal processes when they are developing. Code reviews allow these people to get together and maintain a standard coding style. Security is enhanced because “security team members can review code for vulnerabilities and alert developers to the threat. Code reviews are a great complement to automated scans and tests that detect security vulnerabilities.” There are many benefits to code review, but there are some disadvantages, including: longer time to ship, focuses being pulled from other tasks, and large reviews mean longer review times. These can be described as necessary evils due to the sheer amount of positives that code reviews offer in software development.

I chose this article because it was published by GitLab, a software that we are heavily using in class for version control, and I thought that it would be interesting to read this specific topic from the syllabus. Version control softwares such as GitLab allow code reviews to happen, so diving deeper into the topic in an article published by this popular software company was tempting. Before reading this article I understood that code reviews were important to pinpoint any bugs or difficulties before merging code into the upstream, but I never really thought about the implications of security or different development styles. I’ll definitely keep this information in mind during future code reviews on the job to remind myself that bugs aren’t the only important thing during a code review.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

YAGNI

Source: https://www.geeksforgeeks.org/what-is-yagni-principle-you-arent-gonna-need-it/

This article is titled “What is YAGNI principle (You Aren’t Gonna Need IT)?” YAGNI is “a principle in software development that suggests developers should only implement features that are necessary for the current requirements and not add any additional functionality that might be needed in the future.” The reasoning for this is that if you add features that might potentially be needed in the future, there will be risk for more bugs, increased complexity, and increased times of development, thus leading to increased cost. The YAGNI principle is similar to the KISS principle (Keep It Simple, Stupid), which also advocates for simplicity, it encourages developers to avoid complexity when it isn’t necessary. Developers should follow the YAGNI principle if they wish to keep the following costs in mind: the cost of building, delay, carry, and repair. The cost of building refers to the total cost of efforts and resources implemented in the project. Building things that aren’t needed leads to increased costs overall. Cost of delay refers to missed opportunities, if you spend time on unnecessary features, the development of more important ones will inevitably be delayed. Cost of carry refers to the difficulties of having unnecessary complex features. These complexities make it difficult to work on other parts of a software project, require more time, lead to an increased cost, and overall cause harder times moving forward. Lastly, the cost of repair, or technical debt, refers to the costs associated with bugs or mistakes that occur during the development process. YAGNI is important to ensure that the development process is focused, efficient, and cost-effective. YAGNI can be implemented into your code by prioritizing communication between team members. Ensuring that necessary requirements are met, a simple plan is made, ignoring ideas that don’t meet goals or deadlines, and keeping good records of project progress will allow your team to follow the YAGNI principle. YAGNI allows for simplicity, faster development, flexibility, reduced risk, and cost savings by complementing other development principles while prioritizing unnecessary implementations.

I chose this article because I appreciate how geeksforgeeks simplifies topics within the software development community. I don’t recall this principle being explicitly mentioned in class, but we have definitely alluded to it and I thought it’d be beneficial to read about it more, considering that it is in the syllabus. It was interesting to learn that the YAGNI principle complements other software development principles, such as the KISS principle, and compiles them into a unique principle that prioritizes simplicity over complexity and more features. It embodies the idea of “less is more.” This is a great set of guidelines I’ll be sure to follow in industry because it promotes that sometimes less work isn’t a bad thing. Instead of creating a multitude of features, ensuring that the ones that are critical, and required sooner, are being developed, will still get the job done.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Software Maintenance

Source: https://www.geeksforgeeks.org/software-engineering-software-maintenance/

This article is titled “Software Maintenance – Software Engineering.” Software maintenance “refers to the process of modifying and updating a software system after it has been delivered to the customer.” There are many different aspects involved in this including: fixing bugs, adding new features, and keeping up with new hardware and software requirements. Maintenance is very important for ensuring that software is able to last long. This process can be expensive and complex, so these factors must be taken into account during the planning of a software development project. The important tasks in regard to software maintenance are: bug fixing, enhancements, performance optimization, porting and migration, re-engineering, and documentation. Summarizing these tasks, it is important to find and fix errors quickly, add new features/improve existing ones, improve the performance of the software, adapt the software to run on different hardware, improve the design, and maintain accurate documentation of all of these processes. There are quite a few different types of software maintenance, but they can be categorized into proactive and reactive types. “Proactive maintenance involves taking preventive measures to avoid problems from occurring, while reactive maintenance involves addressing problems that have already occurred.” Maintenance can be done by stakeholders, the development team, a third-party, and they can be both planned or unplanned. Planned maintenance can be described as regular maintenance (bug fixes) while unplanned maintenance can be described as reactive maintenance that occurs when something unexpected happens. Maintenance can fall into these different categories: corrective maintenance, adaptive maintenance,  perfective maintenance, and preventive maintenance. Corrective refers to fixing bugs and enhancing performance of the system. Adaptive refers to modifications being made when a customer needs the software to run on a different system. Perfective refers to the adaption of the software when a customer has a demand. Lastly, preventive maintenance refers to modifications that focus on the prevention of future issues with the software. Software maintenance is important but there are some things to consider: the cost, complexity, possibility of new bugs, users not updating the software, compatibility, technical debt, and end-of-life (where maintenance isn’t possible anymore or cost-effective).

I chose this article because I found it in the syllabus and thought the topic to be interesting. We are always learning about the development of software, but the idea of maintaining it over the long term isn’t as heavily considered. A large part of the work of a software development team is to obviously develop software but it is also important to learn about how it can maintain a sense of longevity free from error and customer complaints. I will keep the information I learned from this article in mind in future projects and when I’m working with a team to ensure that I’m developing software all the while keeping maintenance in mind. If it is considered during the development process, the maintenance process will be much easier.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Introduction to Pattern Designing

Source: https://www.geeksforgeeks.org/introduction-to-pattern-designing/

This article is titled “Introduction to Pattern Designing.” In regards to software development, “pattern designing refers to the application of design patterns, which are reusable and proven solutions to common problems encountered during the design and implementation of software systems.” These reusable design patterns showcase relationships that occur between classes or objects. They are language dependent, so they can be described as an idea that makes code flexible and overall speeds up the process of development. Their purpose is to solve common problems. There are three main kinds of design patterns, creational, structural, and behavioral. “Creational design patterns abstract the instantiation process.” Creational design patterns offer a sense of flexibility in regards to “what gets created, who creates it, how it gets created, and, when.” Knowledge about which concrete class is being used is encapsulated and the way instances of classes are created is hidden. “Structural design patterns are concerned with how classes and objects are composed to form larger structures.” Inheritance is used to create interfaces/implementations. Structural design patterns are good for when you want to make independent class libraries collaborate effectively with one another and offer flexibility regarding object composition. “Behavioral design patterns are concerned with algorithms and the assignment of responsibilities between objects.” Patterns of communication are being described here. Inheritance is used to divide behaviors between classes, object composition is used for behavioral object patterns, and the object patterns encapsulate behaviors in objects. Overall, the benefits of pattern designing are reusable solutions, scalability, and abstraction/communication. The downfall of it however is that there is a learning curve while you try to understand the patterns, there may be concerns with when you should apply the patterns in your code, and if patterns aren’t implemented consistently and in correlation with the advancement of the system, maintenance issues may occur. But regardless, they are a great way to solve common problems during the development process.

I chose this topic because the idea of design patterns was in the syllabus and it interested me. We learned about design patterns such as Factory, Strategy, and Singleton, but reading about the larger terms of creational, structural, and behavioral patterns offered deep insight into the topic. The supposed benefits of common methodologies in software development are always presented but it is also good to know about the downfalls, which I am glad this article showed about the design patterns. When I am working on a team or in the workforce, I will definitely reference these design patterns to improve the maintenance capability and scalability of my code, and do so in a way which I am able to avoid the downfalls of implementing them incorrectly. 

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Version Control

Source: https://www.spiceworks.com/tech/devops/articles/what-is-version-control/

This article is titled “What Is Version Control? Meaning, Tools, and Advantages.” The main purpose of version control is to “track the progress of code across development and iterations and also aids in managing changes during the life cycle.” Records are kept of all changes with names, timestamps, and other important information. So, the process by which software code is monitored and the way in which changes are made is called version control. A huge benefit of version control is being able to look at the revision history and determine where problems originated from, and who caused them to happen. This allows for increased efficiency regarding workflow considering that the time required to locate problems is greatly reduced. Another benefit of version control is branching. “Branching is a distinct approach to version control where development programs are duplicated for parallel versions of development while keeping the original and working on the branch or making separate modifications to each.” This allows for enhanced collaboration where development is increased, issues are resolved, and code remains organized. A couple very popular version control tools are Git and GitHub. The creator of Linux, Linus Torvalds, created Git. The memory footprint of Git isn’t vast and is able to follow changes in any files. It is a very simple version control system and as a result is used by top companies such as Google. GitHub is a service that enables development teams to collaborate and keep track of all their code changes in a cloud environment. GitHub is secure and reliable, and as a result is also widely used. Through the use of a version control system the following can be achieved: “streamline merging and branching, examination/experimentation with code, the ability to operate offline, creation of regular/automated backups, communication through open channels.” Overall version control aids in the maintenance of reliable code bases and enforces accountability for effective collaborative development. 

I selected this article because we are actively learning about version control in class right now so I figured it’d be the perfect time to read up on it more. Reading the GitKit chapters has exposed me to different git commands and GitHub usage. It was interesting to read in this article about all of the in-depth benefits that version control offers and clearly showcases why even top companies such as Google use it to optimize their workflow. In future practice, whether it be at a job or while working on an individual project, I will use version control to improve collaboration and the ease of maintenance of my code.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Anti-Patterns

Source: https://www.freecodecamp.org/news/antipatterns-to-avoid-in-code/

This article is titled “Anti-patterns You Should Avoid in Your Code.” It specifically mentions six of them, being: Spaghetti Code, Golden Hammer, Boat Anchor, Dead Code, Proliferation of Code, and the God Object. An anti-pattern, in regards to software development, is an example of how not to solve a problem in a codebase. They are not a positive thing, they are examples of practices to avoid in the development process. Anti-patterns lead to technical debt, code that you have to eventually come back to and properly fix later. Spaghetti Code is the most common, it is code that doesn’t have much structure. It is called Spaghetti Code because everything is difficult to follow, files are located in random places, and when visualized in a diagram, it appears to be a jumbled mess, much like spaghetti. Golden Hammer references a scenario where you follow a certain process that doesn’t necessarily align perfectly with the project but still works well enough. This may not seem like a large issue, but is obviously not the best practice to follow because it’ll cause performance issues in the long run. You should always use a process that is the best fit for your project, even if you need to teach yourself or learn something new. Boat Anchor is when developers leave code in the codebase that isn’t actively being used in the hopes of it being needed later and thus not requiring much effort to implement when it is eventually needed. The main problem with this is when it comes to maintaining the code. It leads to the question of what code in the codebase is unused and what is being actively used. Trying to fix a bug in the system on code that isn’t even being used is a time waster. Dead code is code that doesn’t look like it’s really doing anything, but it is being called from many different places. This leads to problems when trying to modify the code because no one is unsure what is actually dead. Proliferation of Code is about objects that have the purpose of invoking a more important object, meaning it doesn’t really do anything on its own. The action of invoking the more important object should be set to the calling object. Lastly, the God Object is an example of an object that does too much. Objects should only be responsible for doing one thing, referencing the Single Responsibility principle in SOLID. 

I chose this particular source because I appreciated the way examples were clearly given along with the 6 examples of anti-patterns, and upon reviewing the syllabus the topic “anti-patterns” seemed interesting. When you’re learning computer science a lot of the time you’re learning about things that you should do and not about things that you shouldn’t do. I really enjoyed reading about these 6 examples of common mistakes that developers make in industry. It’s important to both recognize good and bad practices to ensure that your projects are properly optimized. I can definitely see myself referencing anti-patterns when designing code in the future so my code can easily be maintained. 

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Project Management

Source: https://monday.com/blog/project-management/guide-to-project-management/

The title of this blog is “What is Project Management? The Complete Guide [2024].” As seen from the title, this blog obviously describes the ins-and-outs of project management. The idea of project management is to manage projects by ensuring that they are delivered on time, within a set budget, and satisfy the needs of the stakeholders. Project management involves setting goals, scheduling, managing, monitoring, and collaboration. This is accomplished through various methodologies such as Agile, Kanban, or Scrum. This is an important field, and topic, because teams of individuals are the ones who provide the greatest projects and products to the market, and without effective leadership and problem solving, they would never come into fruition. Many different organizations employ project managers, ranging from small businesses to Fortune 500 companies. Project management is not exclusive to software engineering though, it can be seen in other sectors such as construction or marketing. “The Project Management Body of Knowledge (PMBOK Guide) defines ten key project management knowledge areas” them being: scope management, schedule management, procurement management, stakeholder management, risk management, communications management, resource management, quality management, cost management, and integration management. These are all self-explanatory from their names but are very important for being an efficient and effective project manager. There are many different tools used in this field, such as Gantt charts (used for scheduling and tracking tasks in a visual timeline), tasks lists, Kanban boards, calendars, budget trackers, mobile apps, and many others. One might ask if a project is completed and another one is about to be started, is everything created from scratch? The answer is no. Project managers use templates to fill in instructions from prior work to save time when initiating a new project. There are quite a few roles in project management, one being the project manager themself, the project sponsor, the team members, the stakeholders, the customer, the office, and the steering committee (who provides oversight). All of these individuals make the creation of projects operate smoothly.

I chose this particular post about project management because it appeared to be all-encompassing of the topic, and I was correct. After learning about Agile and Scrum methodologies in class, I was interested in learning about the importance of having a project manager in various sized companies. I can appreciate the fact that they have to communicate with stakeholders, engineers, and management in order to ensure smooth operation. Overall this material was very interesting to me because I’ve had an interest in this field for my future career. If I end up pursuing project management, this information would definitely be beneficial for performing my job appropriately. If I don’t, knowing the role of a project manager would be beneficial regardless because I’m bound to work with one regardless. Having an understanding of your coworkers’ roles at your company is important for collaboration. 

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

GRASP

Source: https://www.youtube.com/watch?v=GcqTrlL_Htw

This video from YouTube is titled “Design Patterns GRASP // Object Oriented Analysis and Design (ICS).” As stated in the title, it goes over the design patterns of GRASP, or General Responsibility Assignment Software Patterns. GRASP is a set of 9 principles that relate to object-oriented design that help developers/engineers assign certain responsibilities to certain variables, classes, objects, etc. in software. The overall purpose of GRASP isn’t to create “fancy” code, but rather to create maintainable and reusable code/software. The 9 principles are information expert, creator, controller, low coupling, high cohesion, polymorphism, pure fabrication, indirection, and protected variations. “Information expert” places responsibility on classes that have the required information to complete it, wanted behaviors and data are put together. “Creator” places responsibility for the creation of instances of classes to classes that would use it. “Controller” places responsibility for handling system events to a class that describes the event, known as the controller. “Low coupling” states that classes should be as independent as they can be from other classes. “High cohesion” states that classes should have clear purposes with responsibilities that relate to it. “Polymorphism” is implemented so new behaviors can be added without changing preexisting code. “Pure fabrication” states that new classes should be created if there isn’t an already existing one that fulfills a desired requirement. “Indirection” states that dependencies among classes should be minimized so changes can be made without having an impact on other parts of the system. Lastly, “protected variations” encourages developers to design the system in a way that variations in behaviors are negated through encapsulation. 

I chose this particular source because we haven’t covered this topic in class yet and it seemed interesting, I found the topic from the syllabus. This video had a low amount of views and I wanted to give it a chance. After watching the video, I appreciated the fact that the information was presented in a straightforward manner and offered visual examples for each of the 9 principles of GRASP. After learning about Agile methodologies, it was interesting to learn about GRASP, because in my opinion it seems as though instead of being a set of principles of workplace improvement, GRASP seems to be a set of principles for actual work improvement. Overall, the material impacted me in a positive way because I appreciate the idea of everything in a system/software having a certain responsibility, and can definitely see how this will benefit me in the future when I work on more projects related to software development. I will certainly keep GRASP in mind for these future projects. 

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

CS-348

This is my first post for CS-348 Software Process Management.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.