Having just finished our final web application project presentations this past week, I believe this article was extremely necessary. In this final project, we were able to explore the methods to make a (mostly) functional web application, from the back-end to the front-end. We learned how hard both ends can be, but I found that the two are completely different from each other in importance. The back-end is how information from the web application will be stored to the local server. Meanwhile, the front-end is how the web application looks and is seen by it’s users. As Ronald Mendez describes in his blog post, “Owning the Role of the Front-End Developer”, it can be a very difficult time when you control the development of the front-end.

The front-end is important to all developers of a product. It is important to the sales team, the marketing team and the entire web development team. However, the front-end work is usually done at the very end of the development period. This can leave many front-end developers to feel left out of the development process and practically useless to their teammates during most of the development. Mendez found himself feeling this way many times in his career of working as a front-end developer until he learned how to speak up and keep his team motivated as they worked on different web application projects.

It’s fair to say that the modern developer can’t simply hide behind a keyboard and expect the rest of the team to handle all of the important decisions that define our workflow. Our role requires us to go beyond code, share our ideas, and fight hard to improve the processes we’re involved in.

— Ronald Mendez

I found this article to be incredibly applicable considering all of the work we had just finished on our own projects. We did both the back and front-end developments ourselves, but I can see how the front-end development can become tossed to the side when the core of the work is in the back-end and making sure the website actually functions the way it is supposed to. All in all, I believe Ronald’s advice is important to those seeking roles as web developers specifically.

From the blog CS@Worcester – Fall 2018 Software Discoveries by softwarediscoveries and used with permission of the author. All other rights reserved by the author.

As we end the semester, I thought it would be interesting to see what other software developers have been able to take away from their experiences in the field. The advice I found came from the blog post “The One Thing Every Software Engineer Should Know“, written by software developer Jeff Atwood.

In this blog post, Atwood shares advice from his personal experiences in the software engineering field and sheds light for those of us just getting started in the world of technology. He specifically highlights the advice of a former software engineer for both Google and Amazon, Steve Yegge, who says:

If there was one thing I could teach every engineer, it would be how to market.

This is something that some of us may have never thought of before, but it’s becoming more and more important as we continue to advance in technology. It is also the reason that many Computer Science majors insist on receiving an MBA (Master’s in Business) following undergrad. We may be the best software developer or engineer, but what does that mean to people who are not in the tech world? Sure, they know that we are able to program and fix almost anything, but how does that help them? How does the code we produce help them?

To answer this question, we as the new technological work force must add marketing to our skill set. Having the ability to market your own personal skill that has helped you to create and develop a product is amazing. With this skill, we are then able to show more companies that we are valuable as both software and sales engineers and capable of understanding what our software actually means beyond the coding aspect.

I found this article incredibly interesting considering how it attempts to bridge the gap between technical and non technical fields. Most buyers who are looking to buy software for their companies don’t know what certain specifications of the products mean. Being able to market your product to them in a way that they will understand makes you a better software engineer and sales engineer.

From the blog CS@Worcester – Fall 2018 Software Discoveries by softwarediscoveries and used with permission of the author. All other rights reserved by the author.

As computer science students, we find ourselves becoming more and more immersed into new ways of thinking and working with technology each and every semester. The further we go, the more our brains are tested into thinking in new patterns and methods. This makes some classes easier than others, but it depends solely upon how we think already. This interested me, as someone who has taken almost as many psychology courses as math courses.

The way in which the human brain interacts with things like interface design can make the difference between which operating systems you may choose to use on your devices. I decided for this blog post I would explore the psychological side of design and see what truly makes a difference for users. My research for this particular topic was made incredibly easy through the use of the blog post, The Psychology of Design, written by an interaction designer named Jon Yablonski.

As Yablonski explains, psychology can be used to modify systems and interfaces to interact more clearly with human users. By doing this, the experience people have with the system can feel more flawless and uninterrupted since it thinks similarly to the way they do. If this went much further, it could turn into a more artificial intelligence based interface since the interaction would be so similar to a humans. However, this can easily turn into an ethical conflict. In the same way that psychology can be used to enhance the experience a user has with a particular system, it can also be used to possibly manipulate a user into agreeing to something detrimental. To this point, Yablonski commented,

As designers, our responsibility is to create products and experiences that support and align with the goals and well-being of users. In other words, we should build technology for augmenting the human experience, not replacing it with virtual interaction and rewards. The first step in making ethical design decisions is to acknowledge how the human mind can be exploited.

– Jon Yablonski

This was easily one of my favorite blog posts I have read so far simply because of the ways in which it applies psychology to system design and interface structure. The ways in which a system interacts with its user can decide whether it can be considered to be successful design or not.

From the blog CS@Worcester – Fall 2018 Software Discoveries by softwarediscoveries and used with permission of the author. All other rights reserved by the author.

Through learning how to code alongside a diverse group of people who learn best using a variety of methods, I myself have learned a very fundamental principle: different people with different skills and knowledge learn differently. This is similar with learning across all subjects and skills. While some people are visual learners, others are more attune to a more hands-on learning experience. It’s important that all designs for public use embrace the diversity of its users to change the design of their display to be more effective, since some designs will work better than others. When dealing with the internet and any public source, most things must be easily interpreted by the most number of people.

With that, we turn to the code writers and program design groups who study what makes the user interface easier to use. How do we develop and design websites and applications for those with cognitive differences? Not all effectively written code is considered “effective” by those with inattention, anxiety or depression disorders. Knowing that, how can we make our code better for those in the general population who are affected?

To research further, I used the blog post “Designing for Cognitive Differences” by Brandon Gregory, a software application designer and developer, as reference. He explains the common symptoms of common mental disorders such as inattention, anxiety, and depression. He then goes on to explain that the primary solution to such disorders is creating inclusive designs. This means that the user interface is improved to make sure that users who suffer from certain mental disorders are not swayed from using their application through simple things like changing a “submit” button to say “send payment information” or “change sound settings”. These are small improvements, but they make all the difference. Brandon Gregory then concludes his post, by explaining that,

“…  disability takes many forms, and accessibility and inclusive design need to take just as many. In our industry, compassionate discussion around physical disabilities has been a huge benefit, and cognitive differences need to be part of the conversation too. Removing unnecessary distractions, reassuring users that they’re doing the right thing, and keeping things easy for users who are struggling are things we can do to accommodate these users and make them feel like you actually want them to use our sites and apps. As one of these users myself, I can say we would really appreciate your efforts. ” -Brandon Gregory

As someone who knows many people with the listed disabilities, I enjoyed this article. It clearly identifies what people struggle with and how to improve every day websites in little ways to be better used by the general public. Being aware of these disabilities will make the internet more safe and easy to use overall.

From the blog CS@Worcester – Fall 2018 Software Discoveries by softwarediscoveries and used with permission of the author. All other rights reserved by the author.

Having taken multiple team-based software development classes, I’ve always wondered how software development teams measure and record their productivity levels over the course of an entire project. Are there certain metrics to use in order to measure such productivity over time? Is this metric universal to all software development projects, or does it vary depending on the purpose of the software?

To research the answer a bit further,  I read “Measuring Developer Productivity” by experienced developer, Max Kanat-Alexander. In this blog post, he begins at the root of what productivity is; essentially, it is the making of a certain product, a process which can be deemed effective when it takes the least amount of time and materials to complete. He continues by explaining that,

The key to understanding what productivity is is realizing that it has to do with products. A person who is productive is a person who regularly and efficiently produces products. – Max Kanat-Alexander

This clarifies the definition of what productivity is and thus allows us to understand that productivity must be measured over an increment of time. A productive team is one that produces developed software that fits all of the necessary criteria in a time efficient manner. Now, do we count developer productivity in keyboard clicks? Lines of code? Neither. Kanat-Alexander outlines his point as he explains that,

The point here is that “computer programmer,” like “carpenter,” is a skill, not a job. You don’t measure the practice of a skill if you want to know how much a person is producing. You measure something about the product that that skill produces. – Max Kanat-Alexander

I found this point in particular to be incredibly interesting to consider. Instead of being measured by a very small and insignificant portion of the job, the metric necessary is project/job dependent. How many tasks of your job can you complete in a single day? In a single hour? If you are able to complete many small tasks, then you are very productive. Even if you are able to complete one very large task, then that is also considered productive. The way productivity should be measured is by the weight and size of the task and how many you are able to finish to an effective working level each day of development. With this metric, it is easier for managers to grasp how productive their software developers really are.

From the blog CS@Worcester – Fall 2018 Software Discoveries by softwarediscoveries and used with permission of the author. All other rights reserved by the author.

Since CS-343 is meant to teach us about how to craft and design better code, I figured it would be important to first identify the key components of reviewing code, whether it be your own or someone else’s. To do this, I used the article “Yet Another Code Review Best Practices” by Pawel Ochman as my main reference.

He begins by describing some of the reasons for reviewing the code, leading into a few tips and things to look for, ending into a note about how to maintain the code after your review. With all of this information, a few key things stuck out to me:

• Prior to reviewing the code, you must create a goal. There can be a single or multiple goals, but no matter what all code reviewers must have common goal(s). Some examples of these goals include:
  • Eliminating bugs at an early stage
  • Improving code quality
  • Increasing knowledge about the project
  • Learning from each other
• The most important principles to follow when reviewing code are quality and motivation. In this context, quality is the principle of making sure that every time you review code, you review it to the best of your ability. Similarly, motivation is the principle that plays as a constant reminder of the values of code review to keep the team/yourself feeling positive about the review/editing.
• Positive feedback after reviewing the code is important for whoever’s code it is. The values of code review outweighs allowing it to continue to be inefficient or ineffective in functioning/solving the problem (whatever that may be).
• The most important point is that you don’t have to be an expert:

It’s a great chance to learn something new. If you are not sure whether solution is correct, you can start a valuable discussion. As a team member you should be able to work on any area of the project. Don’t allow any person to be the only expert in specific part of an application. You should be able to replace anyone in case of his absence.

All in all, this was a great article to learn from as it allows you to see the benefits of  code review through each stage. With small pieces of advice, it transforms what may be a painful process into a more positive one.

From the blog CS@Worcester – Fall 2018 Software Discoveries by softwarediscoveries and used with permission of the author. All other rights reserved by the author.

Before shifting into the details and techniques of how we, as developers, can design and improve software for the future, I felt as though it would be better to start off with a more general post about where software is taking us.

As people in this particular technological age, we depend on software to be effective every minute of every day of our lives. In this way, we are spoiled. With new advances in technology being released rapidly, we have almost become accustomed to having so much technical capability right in our back pockets. With this, we have begun to catalog and store everything about ourselves, since the amount of data storage we have is at a relatively infinite capacity. With such capabilities at the touch of our fingers, is it our jobs, as future software developers, to protect the general public against the possible repercussions? Are there evils afoot that come with such good?

To find out more information (and a few answers to these daunting questions), you may turn to non-other than Jeff Atwood, a software developer, who created the blog post “To Serve Man, with Software” on his blog, Coding Horror. He begins by describing the role of programmers today, beginning all the way from the early decades of coding, in the sense that programmers have always been the ones ruling the world. This, at first, seemed like a good thing. Programmers and software developers could change the world and do all sorts of good with their powers! However, is it always good?

What do you do when you wake up one day and software has kind of eaten the world, and it is no longer clear if software is in fact an unambiguously good thing, like we thought, like everyone told us … like we wanted it to be?

This should be a reminder to each of us how powerful software is, especially in our world today. Ensuring that all of the software that is being developed has a morally and ethically right purpose and that it is so specified that it cannot be used for anything other than it’s original intent is gravely important. As software developers, this is a critical concept to keep in mind.

From the blog CS@Worcester – Fall 2018 Software Discoveries by softwarediscoveries and used with permission of the author. All other rights reserved by the author.

Welcome to my software blog! Here is where I will explore all advances in software design and architecture. Stay tuned for continuous updates and information!

Thanks!

Erika

From the blog CS@Worcester – Fall 2018 Software Discoveries by softwarediscoveries and used with permission of the author. All other rights reserved by the author.