Hello everyone, this is my introductory blog post for CS-343.
I decided to read “Sweep The Floor” for this week’s post. This pattern discusses the idea that even if you feel overwhelmed and unable to contribute to your team, there are still ways that you can contribute. This means that even if you can’t tackle the complicated tasks and project straight out of the gate when you start a position, it is still important to be involved and demonstrate that you can deliver quality work in some way, shape, or form.
This is great advice especially for us newly graduating apprentices. When I was at both of my internships, I did plenty of “floor sweeping”. This was anything from writing up documentation, drawing out flow patterns, taking notes during meetings, and writing unit tests. One of the biggest benefits to sweeping the floor when you start a new job, is that you are learning the business logic first, then tackling the complex coding challenges that come with the job as well. For example, this way if your company is working on software that has five different user types and dozens of permissions that require different user types for access, you can learn how this works through writing the documentation and use this knowledge in future tasks for the software. You might even find yourself leading a discussion on the business logic even though you might not have contributed notably on a technical level. From my experience, it made me feel like I was one of the team. I could contribute to conversations, and offer ideas for possible solutions even though I wasn’t entirely comfortable with how to write the code for the particular task.
I also don’t think that this is limited to newly graduating professionals, or even in the world of software development. This line of thinking can be applied to all facets of business, as there are always menial tasks that no one wants to do but offer a learning avenue with a lower risk. When I worked in a hardware store/rental center, I had to learn the software we used as well as how all of our equipment worked. I cleaned the equipment and wrote up requests for customers as a way to learn more about diagnosing machines and giving customers better feedback when they called. Sweeping the floor is good advice both literally and figuratively.
This sprint seems to be the last of nearly entirely research sprints. Now we have the tools we need to get down to business and make some meaningful changes to the code. We have access to the replica of the current, existing system, we’ve gained insight into whether or not we can use AccuTrack, and we learned how we will have to integrate OneCard Scanning. We’ve also organized our story boards to a reasonable state but there is always room for improvement and there are definitely pieces that we are forgetting to add that we’ll come up with on the go. Now it’s time to build stuff.
The first thing we did the sprint was something that actually happened at the very tail end of the last sprint, we gained access to a working replica of the existing system with help from Michelle, Beaulieu, the graduate assistant for the food pantry project. This let us see what flaws there are in the existing system as well as an idea of the complexity that the food pantry workers are familiar with. From obtaining access to this system, we learned about several new stories/epics that we’ll need to add to the growing list of things to do. This included additional fields/questions for the intake form as well as an entirely non-existent report system that we thought was somewhat integrated already. There are other small examples of things that we caught but those are the highlights.
I also met with Bridget Joiner from the student affairs office and discussed theproject. She was the liaison between Joanne and Laura Caswell, the person in IT who was setting up the system within AccuTrack for the food pantry. From this meeting, I learned that it was unlikely that we would be able to integrate with AccuTrack at all but that it was also a good idea to meet with Laura Catwell to get confirmation and possibly hands-on experience with the AccuTrack system. Following this meeting I met with Laura and confirmed that it was not possible to use the AccuTrack system and I also learned that the food pantry workers never bothered to learn the AccuTrack system so the lack of utilization won’t make a difference. I also learned that the level of communication between all parties was poor to say the least but this was a lesson to develop better communication in the future with all parties involved. Laura also confirmed that we could use a scanner and how to access the ID numbers on the card.
Next was the big move from Trello to GitHub issues. While everything has been moved from Trello to GitHub this is an ongoing process and we’re continuing to improve our system as we go along. We’ve decided that anything more than a task belongs on the LibreFoodPantry repository and all tasks should be on the one specific to our sections. We’re continuing to make organizational decisions regarding specific wording, tagging, and branches.
We’ve also obtained the scanner and confirmed the pattern that occurs when scanning OneCards for future integration of the device.
I also spent some time trying to correct some version mismatch problems with my local system and the current code that was on GitHub as of yesterday. There seems to be a new push from the other group that will hopefully resolve these issues, as the old version they had pushed used older versions of software.
This sprint was productive but not in ways that we expected. We expected to have more done regarding the actual software but instead we learned much more about the future and the long term goals of this project. We would have needed to have these conversations at some point so getting them out of the way now is not a bad thing. Hopefully by the end of the next sprint we’ll have some more developed, working software to discuss.
GitHub links to both repositories mentioned:
For this post, I was looking for an eye catching pattern name and “Be the Worst” definitely caught my eye. After a second a of thought, it was pretty obvious what this pattern would be about. This pattern breaks down why it is important to not be the big fish in the little pond. It encourages apprentices to not rush into leadership roles and to not strive to become the best on your team and stagnate with your position. Instead, if you find yourself at the top and lacking learning opportunities, it may be time to move on and find the bigger pond, to surround yourself with higher tier developers when you leave.
I almost entirely agree with this pattern. I remember growing up in a relatively small town, where we had a couple athletes who were notably better than anyone else in the town at their respective sport and position. None, yes none, of them tried to get into bigger school districts where they may be challenged more and had more of an opportunity to get scholarships and even potentially make it professionally. Instead they all enjoyed their high school careers at a school with roughly 500 students in a division 3 conference. They didn’t aspire to leave the little pond and they never made it anywhere in terms of athletics. There are definitely parallels to this even in the college world and looking for positions directly out of school. There are always going to be people who are happy to just cruise by and not learn everything that they can at each step of their careers. I honestly feel like these are the people who are most likely to never even get a job in respective majors and then somehow blame the university for not finding them a job with a 2.0 GPA. No one owes you anything and you can’t expect anything to be handed to you, knowledge especially. There is always more to learn and never enough time to get everything into a four year curriculum. Never settle for being the best you know. All that means is that you need to meet more people.
The only part of this pattern I disagree with is how the authors try to sway readers from promotions. Promotions and new responsibilities even outside of coding are definitely important to becoming the best within a company. If the goal is to rise through the ranks of a company, isn’t this an obvious side effect? That being said, I will definitely consider this pattern as I move along in my career.
For this post, I decided to read the pattern “The White Belt”. This pattern talks about the ability of a software developer, and craftsman, to unlearn something and use an entirely different approach to solve a problem in order to maintain the ability to learn. The pattern talks about the idea of getting stuck at what seems to be your peak potential but that this is merely because you aren’t trying something completely new that would force you to try to solve the problem with a new approach.
I agree with the overall premise of this pattern. Personally, I’ve found it incredibly difficult to try to learn new languages without internally trying to write Java in language X. This summer I had an internship where one of my projects was to make a prototype program for a chat bot using Microsoft’s existing AI technology. This meant that I had to veer away from my good friend Java and attempt to use a new language, C#. I honestly don’t remember that much about C# other than that it looks like a lot like Java and I was able to manipulate the code so that it worked. I spent the entirety of the project focused on how it was similar to Java and how to write Java in C# and never even remotely became a master of the language. Granted, it was a short term project (roughly 4-6 weeks and 20-30 hours a week), so mastery was never feasible. The problem is that if I have to work on another C# project at some point in my career, I will have to start over. I never unlearned my Java knowledge to write in C#.
This coming summer, I’ll be starting a position where I will almost exclusively be writing in C++, a language I have never written a line of code in. Before I start the job, I’m giving myself time to learn the basics, but I know that I’ll need guidance along the way from the subject matter experts at this new company. There will most certainly be moments where I am completely dumbfounded about how to solve a particular problem, or what is wrong with my solution. I’ve learned that over the last couple of years of interning, and at those companies I was using a language I thought I was pretty comfortable in (Java).
Being able to put on the white belt and learn from the masters is one of the things you hear about from everyone in almost every field of technical work. I plan to put on my white belt as soon as I walk in the door at my new company.
In all honesty, this sprint was definitely the one where we’ve made the most progress. During this sprint we were finally able to get access to the input form and sample output from Joanne and her graduate assistant, Michelle. It took several weeks of continuous emails and a face to face meeting to finally get access to the documents. This has been the story of this project for this semester at this point. From my experience during my internships, the length of time to get a response from someone can vary and maybe it is different because of the many different projects and classes that everyone involved is responsible for, but this seems a little outside what is reasonable.
Our biggest problem to this point in the semester has been a lack of communication between our customers and the other necessary parties that can get us moving with the key details of our project. We were warned at the beginning of the semester that our customers likely didn’t know what they wanted and this couldn’t be more accurate. They have the best of intentions but lack the technical foresight to think about how to organize their project to make it any bit future-proof. We’re doing our best to find a happy medium between a complete rework that makes it more scalable and continuing to follow the flows that they are just becoming familiar with.
The other group working on the food pantry project is doing more of the heavy lifting at this point as they’ve already started working on the interface for what will hopefully one day be the new food pantry software system. It is difficult to communicate with them as we’re basically on opposite schedules and everything is on a two day delay for the most part but we are making the most of what we can do.
My role for the last two weeks has been more of a product owner compared to a developer and it has for the most of this semester. I’m not upset about this as it has been a different experience than what I am used to. I’ve been our point of communication with Joanne and the food pantry workers as well as often the one organizing our Trello board and conducting the planning meetings. There is definitely some overlap between product owner and scrum master responsibilities but I haven’t done almost any code writing this semester. I honestly think what we’re doing better as a group as the semester continues to roll on, is rolling with the punches. We’re getting better at reacting faster to the curveballs that are being thrown our way. We’ve been told that everything that needs to be on the current intake form is already there, but after mere minutes of review, we’ve noted several questions that are missing based on the reports we are being asked to output for the final project.
We’re also getting better at splitting up the work between our group. The roles have yet to see much change as the semester progresses but again, I’m not upset about this and it doesn’t seem like anyone in my particular group is. We’re assigning stories/tasks better so everyone has something to work on throughout the sprint and we’re documenting who is working on what in our Trello board. Hopefully we’ll be able to utilize the issues system on Github as soon as our repository situation is resolved but we’re making the most of what we can do with the tools we are given. We’re noting down which particular project each issue/task/story belongs to by noting “[project name]” at the start of the blip on Trello. Overall, organization has improved and hopefully we’re developing a standard that can be utilized well after we are handing off this project at the end of the semester.
I would provide links to the projects we’ve worked on but they are exclusively private. This includes our private group Trello, Slack, and the access link to our newly acquired mock form/output.
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.
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.
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.
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:
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.
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!