Often, when I’m designing a website, I will sketch out a diagram of what I think the relationships between different pages will be. Here’s an example of one of my early sketches:
Even if the finished product is vastly different from the original diagram, sketching out some of the pages and their relation to one another helps me to get a better idea of the overall layout of the website. Skipping this step has, in the past, led to a jumbled mess of pages with no real organization. It is much easier to change a few pages’ organization when problems arise rather than having to redesign the entire website from scratch. The design step is also great for determining parent-child relations. In the above diagram, for example, every page is a child of the HOME page, and all of the child pages link back to HOME. The first generation of children are the WHAT IS HOSA?, CONFERENCES, CHAPTERS, as well as the three callout pages HEALTHCARE PROS, STUDENTS, and TEACHERS. Under each of these pages exist multiple other pages or sections all related under a common theme. Some of these pages link to related pages that exist elsewhere, such as the Find a Chapter link under both CHAPTERS and STUDENTS.
The overall goal here is to make the site as easy to navigate as possible. When I have a basic skeleton of the site set up, I will often ask someone unfamiliar with the organization to attempt to perform a particular task. If I have done my job, they will be able to navigate the site without knowing more information than what I have given them in the description of the task. I watch closely as they move around the site, asking questions to clarify why the user makes certain choices. Things that seem obvious to me may be completely unexpected to a first time visitor to the site. This sort of testing allows me to make improvements to the flow and organization of the site.
The one thing that just about any recent college graduate has to offer a prospective employer is enthusiasm. While enthusiasm may help with getting in the door somewhere, once starting out on a new team of experienced developers the newcomer may be less willing to express that same enthusiasm. Although it may sound juvenile, the desire to fit in applies just as much in the workplace. This desire may prevent a newcomer from sharing valuable excitement and new perspectives with the team. Overcoming this fear of and sharing your excitement and creative ideas will be far more beneficial in increasing learning and value throughout your apprenticeship. In Apprenticeship Patterns, Hoover and Oshineye cover this topic under the Unleash Your Enthusiasm pattern.
If there is one thing that I am sure about, it is my desire to make a real difference through software development. I am passionate about making a difference and excited to begin this journey. I will admit, however, that I would be a bit hesitant to express this eagerness if other members of the team seemed to be skeptical of me. It would be far easier to take the conservative approach and try to match the excitement level of the team. Taking this approach is not the most effective strategy in these situations. It would be far more valuable to both the team and to the apprentice to fully embrace that enthusiasm and use it to inspire and motivate the team. Rather than viewing your excitement as an annoyance to the team, you should view it as an asset that will help the team.
When first starting out, it may be difficult to find ways to make any meaningful contributions to the team. You will need to earn the trust of the team before taking on risky tasks that may jeopardize the integrity of the work as a whole. One way to make contributions while also gaining the respect and trust of the team is to ask questions and unleash your enthusiasm. If you’ve found the right mentor, your enthusiasm for the craft of software development will be rewarded. This mentor will guide you, and you will give him or her a renewed excitement for the craft.
After listening to Jean Ann Harrison’s discussion about how important critical thinking is in the context of software testing and quality assurance on an episode of Test Talks, I wrote a post about The Limits of Automated Testing. Although Harrison’s explanation was great, I had a few remaining questions and this week chose to look for more information on automated testing. I came across a post by Martin Jansson from March 2017 titled Implication of emphasis on automation in CI, and it seemed to provide me with the more comprehensive view of testing automation that I was looking for.
Jansson starts out on a positive note, stating that he “less frequently see[s] the argumentation that testing is not needed.” To me it is almost comical to think about someone arguing that testing is unnecessary. While I completely understand that managers and executives are enticed by the possibility of saving time and money by not testing software, this is an extremely risky and careless method of creating a product. I doubt that anyone releasing untested software lasts very long or makes any money in the industry.
So if not testing at all is not an option, what are the options? Going with the bare-minimum for testing would be running only automated tests, a method that Jansson says is actually used. I have to agree with Jansson, however, when he says that this is not testing, rather it is simply checking. Instead of exploring parts of the code that are likely to contain bugs, you will simply be checking acceptance criteria. By not exploring the code fully, you are failing to find anything that might be outside the scope of the specification or the requirements. I feel that the following graphic provides an excellent representation of how few tests are actually performed when following a testing strategy that relies solely on automation.
What constitutes the perfect blending of automated and manual testing may be impossible to know. What is certain, however, is that automated testing cannot be relied upon as the sole method for testing. Jansson puts it in layman’s terms when he says that “you rarely automate serendipity.” Just as Jean Ann Harrison points out in the Test Talks podcast mentioned earlier, automation is not and will never be a replacement for thought. It is a bit of a relief to know that the software development companies are maturing and beginning to understand the importance of having testers who use a combination of automated and manual testing. As long as there continues to be humans writing code, there will need to be humans who test that code.
We live in a world where we are constantly being bombarded with information. Not only do we consume insane amounts of data, we are also providing other people and businesses with information about ourselves. Signing up for online mailing lists, ordering magazine subscriptions, and even making dinner reservations, information about our habits and preferences is constantly being left behind, a concept that Charlie Berger refers to as data exhaust in a podcast from October 10, 2017 on Software Engineering Radio. The larger concept that he is describing is what is known as ‘datafication’, a buzz-word in the data science and big data spheres that refers to the collecting and storing information about social actions that can be used to perform predictive analyses and targeted marketing.
Specific to the computer science discipline, datafication has implications on the development of predictive applications. In the podcast episode, Berger presents the simple yet extremely effective example of an ATM machine as lacking in the predictive application sense. Berger wonders why each time that he uses the ATM he is asked which language he would like to use, and why such preferences are not somehow tracked and stored, making for a more seamless and personalized ATM experience. Berger even suggests that the ATM track more than language preferences, offering withdrawal suggestions based on previous transaction data from a similar day of the week or time of the day.
While it may not be terribly inconvenient to have to choose a language each time you use the ATM, the concept of predictive applications and the advantages associated with creating and using these types of applications becomes much more apparent when considering larger-scale operations. Retailers can use predictive applications to make important decisions about things like advertising and merchandising. Berger mentions the well-known “parable of the beer and diapers,” where an interesting and entirely unexpected correlation was found between purchases of diapers and beer. While some versions of the tale include the retailer moving the two correlated items next to one another in order to drive increases in sales, this may or may not be factual. Regardless, such examples of generating useful information based on querying data is a perfect example of the power the predictive applications have.
Berger repeatedly stresses the importance of moving the algorithm to the data, not vice-versa. By moving the algorithm to the data, we avoid all of the dangers of bypassing security and encryption. Developing applications that perform queries and compile information that is usable and useful to not only data scientists, but normal people as well, is a perfect example of how machine learning and predictive applications can make everyones jobs easier.
As a student, I took one of Berger’s closing remarks under careful consideration. Berger states that it is much easier for a programmer to learn how to make a program that interprets data than for a data scientist to translate his specific, one-off analyses into programs. With a newfound understanding of why predictive applications are so important to our data-obsessed society, I look forward to exploring how I can begin developing applications that take advantage of machine learning.