Pattern 4 – A Different Road

After writing about “The Long Road” in my last post, I decided to read the referenced “A Different Road” pattern. This pattern is exactly as described in “The Long Road”. It is a pattern that basically tells you that it is ok to step away from software development and that even if you leave, you will carry what you have learned into whatever path you choose to take. This pattern also warns readers about the difficulties that may arise if they want to come back to the world of software development after taking a break of any kind.

Compared to “The Long Road”, I very much align more with this pattern. I agree that the problem solving techniques learned throughout years of software development can be useful in other career or life paths. I feel like this pattern should have given more insight into this aspect of choosing a different road. This section didn’t really discuss how one might move from a developer position to a project manager position where such technical insight would be a massive benefit to a company. Being in a position like this and having a strong understanding on the feasibility of reaching deadlines and being able to relate to the developers working under you makes you a great asset to your company. The pattern instead gives examples of teaching and full time parenthood.

I entirely agree with the aspect of this pattern that talks about how difficult it is to find a job after having a gap in employment. I follow several computer science career related forums and this is a very common point of conversation. Whether it is a young adult who takes a gap year after graduating, or a parent who takes off the first year of their child’s life to bond more, they both often have trouble finding work after their gaps. This all varies company to company and there are definitely companies out there that value work-life balance as a core principle of the the company’s mission statement. From my experience, companies that have more of an older employee base are more work-life balance heavy. They tend to have more of an understanding of the 40-45 hour work week. There are also companies in the area of defense contracting that almost “have” to have their employees work a maximum of 40 hours a week due to contracts. It is all about putting in the effort to get back into work and finding a company that will work for you. If they don’t understand a reason for taking a break, they probably aren’t a company you want to work for.

Pattern 3 – The Long Road

I thought the title of The Long Road would make for an interesting pattern to read, so I chose it for this particular post. This pattern describes the path that a craftsman will have to take to become a master throughout their career. This is specific to becoming a master of software development and not particularly for what is traditional success in a career path that we as newly graduating software engineers are “expected” to follow.

For this reason, I honestly disagree with the general idea of this pattern completely. The pattern does make it clear that this is the path specifically for people whose life goal is to become the best at software development and does not seek anything else out of a career in software development. I don’t see this as the norm, or generally good advice in any regard. I also feel that it is important to state that this is merely my opinion, but also one that I strongly believe in. From everything that I read about software developers who stick strictly to software development throughout their careers, they often burn out but also feel that it is too late in their careers to do anything else. These are engineers in their late 40’s and 50’s who have been working for the same company for well over a decade and feel that their knowledge in software development is so narrow because of a lack of exposure to other tech and other business domains. While this is not always the case, this is just what I’ve read and have been exposed to personally.

The pattern also preaches how admiral it is to stick to this strictly developer mindset and how money and promotions should not be a focus for you. While I think that this is important to not be the only focus in a career, this is just silly. Promotions and salary should not be a measure of your success but they should be something we all seek, and a goal for people to strive for throughout their careers. The way this pattern is worded, it seems to try to even nudge readers away from positions like architects where you aren’t specifically writing code on a day to day basis. It wants readers to avoid big picture positions and exclusively stick to coding. There is always more to learn in coding and we should all do something we love, but coding should not be the only aspiration for our careers. For that reason, this article has not changed how I will approach my career, but possibly reinforced the goals I previously had.

Pattern 2: Expose Your Ignorance

For this blog pattern, I chose “Expose Your Ignorance” I feel everyone should embrace and especially because of the situation that we’re all likely going to be in upon graduation. This pattern tackles the prospect that throughout our careers, we’re likely to find ourselves not entirely understanding all of the technologies that encompass the projects that we are working on. It also encourages us to resist the psychological urge to pretend that we understand everything, and to be open to admitting that we do not entirely understand the material.

I opened this post by trying to push how important this concept will be for new graduates in our first jobs and to me, that is why this is one of the most relevant patterns in the entire series. If our first jobs are anything like my internships, we will likely go into them knowing the “main” language that we’re dealing with on a day to day basis, but it is also likely that this will be the extent of our knowledge in terms of the technologies that we’re working with. Both of my internships were Java based but there was so much more than went into understanding the work and even more importantly, the business logic that were the driving factors for all of the projects. One was a microservice architecture e commerce site where you needed to know the Spring framework as well as how REST API’s work and much, much, more. The other job was for a Point Of Sale (POS) system and we needed to know an Oracle developed framework that was crucial to writing efficient code. The most difficult part of both of these jobs, was admitting that I knew next to nothing about what I needed to do and asking for help. By the end of the 12 week internships, I was by no means an expert on either topic, and I still needed to ask the experts questions, but I was able to contribute on my own.

The pattern furthers this concept by illustrating what you look like to your employer based on how you handle this situation. If you refuse to further your knowledge and stay narrow minded on what concepts and technologies you know, your opportunities are limited to just that, what you already knew coming into the job. If you want more broad opportunities, the first step is to admit your ignorance and be known for being a great learner.

Sprint Retrospective 1

This first sprint was a difficult one and not really because of the work that needed to be done during the first sprint. The reason why it was difficult was because of a lack of understanding amongst our team as to what exactly we were supposed to be doing. Throughout these couple of weeks, we’ve gotten a better understanding of what our project is on a higher level, as well as have made some progress, however little, in moving forward in a technical manner.

For me, the first week was almost entirely trying to figure out what software developers would need for this project. This was not limited to what software we need currently, but taking into account what possible softwares might be needed for future developers who may want to work on this project. I decided that it would be a good idea to add this information to our README file for now. Eventually it would probably be best to have something similar to a confluent page like one would do in the Atlassian suite of software, but a README is sufficient for now.

I also did some additional reading on how to use JSON within Java and was not surprised that it looks relatively easy. I assumed that that there would be an easily importable Java library that handled JSON as it is a very popular form of data handling and even becoming more popular as a means of database management for NOSQL databases like MongoDB. Renz started work on a simple class that will allow us to query our dataset and it is very easy to follow.

As a group, we didn’t really follow what I’d consider pure Agile/scrum tactics as our planning was limited going into the sprint and we came up with things as we went so we weren’t twiddling our thumbs until this upcoming sprint.

Upon our retrospective, we all agreed that this sprint was a little clunky. We agreed that we need to work on using a particular format when adding to our Trello board and that we should be assigning particular tasks to people. We’ve cleared up the stories that we made for the first sprint that seemed to be a little broad, and have have made the deliverables much more clear.

One of our biggest successes of this sprint was clear, honest communication as a team. While there is definitely still room to improve in our communication, no one was judging others for not getting much done on particular days, and we all used this sprint as a bit of a research spike. We’re working to improve this communication by posting more frequently to the slack, as well as making our cards on our Trello board more clear. Along with clearer cards, we’re making it clear who is assigned to a particular task on the title of the card, if applicable.

Like I said earlier in this post, our biggest failure of this sprint was a lack of clarity of what to do from the get-go. At this point, even if we’re not sure what sort of technical deliverables we have for the five of us to be working on currently, there is work to be done by everyone. If people have not been assigned individual tasks, there are research tasks that everyone in the group can contribute to, as well as other opportunities for those in this situation to put in the extra effort if they deem necessary.


Links to our Trello board & GitLab page:

Pattern 1: Your First Language

I decided to dive in with one of the first patterns of the selection, “Your First Language”. I chose this one because I was curious about the tips that the author would give individuals trying to decide on a first language, as well as to see if any of the tips translated for someone like myself, who is trying to branch out into learning more and more languages. This pattern breaks down the steps to choosing a first language and gives several factors for why you should potentially choose a language but makes sure that it is clear that these are tips and not the only reasons for selecting a first language. After picking the first language, the pattern lays out some tips for how to actually learn the new language. The pattern also lays out a simple means of learning more languages down the line and why someone should pick a particular different language.

I’m glad that I chose this pattern because I’m currently in a position where I am forced to learn a new language for a job I will be starting after graduation. The language that my new position almost entirely uses is C++ and I have absolutely no experience in it. The procrastination is killing me as my “native tongue” as the pattern describes it, is Java. Java is what I always try to use to solve problems even if I’m being asked to write in a language like javascript, python, etc. I always revert back to the concepts I’ve learned throughout college almost exclusively using Java. Learning C++ is going to be something that I must do and will attack throughout the next few months before starting my job. The opening to the article was also very helpful in relieving the stress slightly as it talks about how when you start your first job, you’re not expected to be an expert in ANYTHING. I’ve learned that through my last two internships where even though they were both Java based, they used entirely different frameworks and almost everything that isn’t core Java syntax, required an entirely different skill set and understanding.

The only part of the pattern that you could argue I disagree with, is the complete focus on your choice being driven by potential physical mentors. With the internet and communities within the internet, it is relatively easy to find mentors online who are more than happy to answer any of your questions in understanding a new concept or a language for that matter. Overall, I found this pattern VERY useful!

Re: “Why Doctors Hate Their Computers”

After reading the article on “Why Doctors Hate Their Computers” I found the use of scribes for doctors to be rather interesting. The patients and doctors were both missing out on valuable face to face time because of the tediousness of the software and the constraints of the system. I was shocked to find out that the scribes were making minimum wage in most cases as well as the turnover rate to be as ridiculous as most of them only lasted mere months. I feel that if the pay was increased, the position would be drastically beneficial for both parties involved. The doctors would be relieved of their note-taking duties for the most part, while the scribes, who were often med-school students, or those seeking medical schooling, got some hands on experience in a doctor’s office. This goes without saying that the additional patients per doctor that was happening to the example in the article, defeats the whole purpose. The whole struggle to finding a happy medium between functionality and feasibility for clients is not limited to the world of medical software but a struggle that exists in almost every avenue of software, even the consumer market.

One of the biggest tensions for the doctors is the concept of getting to the next patient as quickly as possible, while maintaining a personal relationship with patients, all at the same time maintaining the monotonous documentation system that the software has become. The doctors have taken on additional tasks without additional personnel being hired to lighten the overall man-hours required to perform all of the tasks for individual patients. The scribes help with the doctor’s desire for more face to face time with their patients but again, defeat the original purpose of the software, to be more efficient than a paper system. Those without scribes were often taking on hours of work to do at home as they simply did not have time to complete their note-taking during regular office hours. While the system was meant to make lives easier for doctors, it often wasn’t.

Despite the results, the customer for the system is still the doctors. They’re the ones who are directly using the software as well as giving input to the developers for changes. Some may argue that it is the patients as the whole service of medical care is for them, but like Quickbooks is for accountants, Epic is for doctors.

The lessons from the implementation of this system apply to almost every industry. The man at the end of the article is a perfect example of this, as he was experiencing similar problems at his job as a construction supervisor. Many individuals are losing their direct interaction time aspects of their jobs to devote the time to using software in one way or another.

I’ve always thought of this battle between ease of use and complete functionality as a struggle that directly works in the world of security. People are always afraid of being hacked, or their information stolen but if the system is complicated, and has extra steps for users to ensure security, users want an easy way out. Whether it be simple passwords, or a lack of use of two-factor authentication, users often want the easiest means of use over the most secure means.
Link to the article here:

Apprentice Patterns: Ch1 + 2-6 Overview

After reading the first chapter of Apprentice Patterns, as well as the introductions to chapters 2-6, I have a lot of comments. The first chapter does a great job of setting up the reader with the understanding that this book is for the “little guy” on the ladder of software development. The different pieces that give definitions and explanations for the different roles of apprentice, journeyman, and master, give readers a means to compare the roles in the specific context of software development.

I do have to note that I disagree with some of the points that the first chapter makes. The first chapter talks about the horror stories of first jobs, or early career positions in general for the software developer. I feel that these claims are simply outdated. Because there are so many positions that need to be filled for mid-level developers, companies are doing all that they can to fight for early career, or fresh-out-of-college employees. There are incentives like a guaranteed mentor and open-concept work environments where collaboration is not only encouraged, by a key part of what might be considered the mission statement of the software development department of the company. These open-concept environments lack traditional cubicles that the book refers to as “ small, rectangular stalls with a PC and a crippled Internet connection”. While many, and most likely most companies still have cubicles, the other points have all been existent in every company I interviewed with both for internships and for full time positions before making a decision. One of the reasons why I decided to accept the offer I did was because of the guarantee that I will have a mentor for my first year of employment, as well as the open concept, extremely team focused work environment. While I do think it is important to note that some people might not be so fortunate, it is also just as important to recognize that there are companies that strive for the mentorship situations the book seems to think don’t exist.

One of the chapters that appeals to me the most is chapter 2. The story of the philosopher and the Zen master. I feel that many people feel that they need to learn everything in school and have an overwhelming fear that they don’t know everything that they need to know for their first job out of college. I felt this way before my first internship. After two internships, I’ve learned that you simply cannot be completely prepared for everything that a job is going to throw at you. The best you can do is try to master what you’ve learned and be open to new techniques, technologies, business logic, and entirely different work patterns. Like the journeymen described, who travel from master to master, learning the optimal means of their craft, we will work with different “masters” throughout our careers, and to be successful, we have to be able to identify the “best” techniques and it is our duty to share our knowledge.
Another chapter that I feel furthers many of these points is chapter 4. This chapter talks about the idea of not becoming comfortable with your knowledge and accepting it as your limits. The idea is not to measure yourself on comparing yourself to other developers in an attempt to become better than average. Instead we are always trying to become a better version of ourselves compared to the day before.

I’m overall excited to read through this book, and to relate myself to the patterns in the book. 

Mocking & Mockito

For the final blog entry for this class, I decided to cover a topic that I’ve had personal experience with but wanted to review for further review and understanding, mocking and specifically, mockito. I found an article on by Ivan Pavlov about mockito that is a guide for everyday use of the tool, exactly what I was looking for! The article has sections that includes some in depth analysis that could likely be used as a more in depth documentation for several aspects of mockito. The article also includes some insight into what mocks and spies are in the context of testing, unit testing specifically as well as some examples of the mockito tool in action.

For unit tests, we are testing the smallest unit of code possible for validity. The article states that the dependencies are not actually needed because we can create empty implementations of an interface for specific scenarios known as stubs. A stub is another kind of test double, along with mocks and spies, which are the two test doubles relevant to mockito. According to the article “mocking for unit testing is when you create an object that implements the behavior of areal subsystem in controlled ways.” They basically serve as a replacement for a dependency in a unit test. Mockito is used to create mocks, where you can tell mockito what you want to do when a method is called on a mocked object.

A spy for unit testing is another test double used by mockito. A spy, unlike a mock, requires a non-mocked instance to “spy on”. The spy “delegates all method calls to the real object and records what method was called and with what parameters”. It works as you would expect a spy to, it spies on the instance.  In general, mocks are more useful than the spy as they require no real implementation of the dependency as the spy does. The spy is also an indicator that a class is doing too much, “thus violating the single responsibility principle” of clean code.

Mocking with mockito can be used in a situation where you want to test that an object is being assigned a specific value when a method is called on it and certain parameters are met. A mock does not require the implementation of the methods to be written yet as you can assign values when a method is called by the power of mockito. This is why mockito is such a popular testing tool and mocking is such a popular testing strategy, and why I’ll continue to utilize it whenever relevant.

Link to original article:


Boundary Value Testing

For this week’s blog post, I wanted to cover a topic that we covered earlier this semester, boundary value testing. I found an article on seemingly my go to site for articles for this blog, guru99. The article has several sections including a brief definition on what boundary testing is, as well as a definition of what equivalent class partitioning is and the relationship between the two. There are also a couple of examples and an analysis section that explains why we should use equivalence and boundary testing.

The article describes boundary testing as “the process of testing between extreme ends of boundaries between partitions of the input values.” These extreme values include the lower and upper bounds, or the minimum and maximum acceptable values for a given variable. For boundary testing, you need more than just the minimum and maximum values though. For the actual testing, you need a value that is just above the minimum, a nominal value that lies somewhere in the middle of the range, and a value that is just below the maximum value.

Equivalent class partitioning is explained by the article as “a black box technique (code is not visible to tester) which can be applied to all levels of testing.” It also states that when using equivalent class partitioning, “you divide the set of test condition into a partition that can be considered the same”.  This may sound a bit confusing but it is actually pretty simple. The article uses an example of a ticket system where values 1-10 are the only acceptable values and values 11-99 are invalid. You could break up this set of numbers into two different equivalent class partitions and then returning back to our boundary testing concept, we would test values like 0, 1, 5, 9, and 10.

The best part about boundary testing is that because it is a form of black box testing, you do not need to see how the actual code works. You only need to know the specifications for the valid and invalid numbers. Another reason to use boundary testing is that it eliminates the need for testing every value and thus, minimizes the tests needed. I have and will continue to utilize this testing strategy throughout my software engineering career.

Link to original article: