During this sprint we actually accomplished more than any of the previous sprints. Together as a group we added in different pieces to the intake form and submitted a pull request with our completed tasks. I personally added the primary household income field as well as worked with Tic to make adjustments to my previous task, household size. Everyone else more or less completed their tasks as well. This sprint showed that given the foundational pieces that took us most of the semester to acquire, we could complete some notable work in a sprint.
In terms of how we divided the work, we simply each took a task on a volunteer basis until everyone had one task. After this point there was still one remaining task that was purdenant to what we expected to get done in this sprint I took on the household size task at the end of the last sprint and then took on the primary income source task as an additional piece of work. This worked out nicely as there was no forced level of responsibility but allowed everyone to work on tasks that varied in difficulty for everyone’s individual level of understanding of the tools being used. If there was anything I would change with this way of working is that I think in a perfect world our tasks wouldn’t all be making changes to the same two files. In a perfect world, we would have had a couple people working on those tasks while we had other people developing another aspect of the final product. Unfortunately, there simply wasn’t enough work established for everyone to have something to do if we wanted to have a clear understanding of what we were developing.
For my personal work, I had to relearn how to do ng-if’s and the basics of angular. I remembered most of the html syntax but there were little things that I forgot but almost all of angular seemed to leave my brain since CS-343. The most difficult part of searching for information on Angular is that while incredibly outdated, many of the top results when searching are for AngularJS instead of Angular 2+. If not properly inspecting the tutorial, it could be relatively easy to miss this important detail. When completing my task regarding the household size, I had to come up with a way to make sure that if a person was a commuter, they were properly entering “1” as the value. I had trouble making this persist upon submission and originally decided on a hard overwrite that would default to 1 regardless of what a person entered for that field. The problem with this method is that a person could still consistently enter non-1 values and never learn that this is not expected. Tic came up with a great idea when developing his task to create a very much visible warning message near the box for the field that needs correction. I “stole” this idea and adjusted it to my field accordingly. When developing my other task for primary income source, it was much easier than the other task as there was no real logic to work into the html other than making sure the data was passed on submission to the model. The only other real logic was that a person could only have one primary income source, but that was fairly simple.
Overall I feel that we are in a good space heading into our final presentation. We had struggles early on and throughout most of the semester, but we finished strong. We finished with by far, our best sprint of the semester and I’m happy with what we got done during this final sprint.
For my last pattern for this blog, I wanted to do one that I’ve been waiting to do until the end. This being potentially the last formal software engineering class I will take, I wanted to read “Draw Your Own Map”. This pattern talks about the importance of working in an environment that will help you reach your personal goals. It also makes it very clear that the person who has sole responsibility for taking the first step in each of the small goals that lead to the high level goals that make up every “goals” list, is the reader. We need to take responsibility and not blame any company, or position that could potentially be holding up back from reaching our goals.
I’ve always been a goal oriented person, whether it be in terms of finances, academics, career, or personal. So far I’ve done a relatively good job at achieving my goals and hope to continue this trend throughout my life. In relation to career goals, since I started my college career I knew that I wanted to be involved in software development in one way or another. Through my internships, I’ve learned what I look for in a company and the position that I will be starting upon graduation. I consider it drastically important when interviewing with companies to ask the employees what their goals are. If they’ve been with the company for years and their goals are similar to yours, it should mean that the company is a good fit. For me, I looked for companies that value mentorship, are current with today’s team-based practices, and allow for good work-life balance. On top of all of these, the ability to “be water” and move around within the company if my goals change is also important to me.
Everyone’s map is going to be different but it is important to stay fluid in your mindset of what is important. Do not allow yourself to be pigeonholed to a position that you may one day hate and also makes it difficult for you to find work if you decide to move on. Find a position where the company values your work ethic and desire to learn over the specific skills you have coming into the position, while they are important, they aren’t what will make your relationship with the company last for the long term.
This week I decided to learn about how to “Find Mentors” by reading the pattern. This pattern gives advice about why and how apprentices should seek out to find mentors to continue down the path to becoming a journeyman. They give tips about attending conferences, joining online forums, and taking your potential mentors out to lunch if you have the opportunity.
I do agree that finding mentors is greatly important in the development process to become a successful software developer, but I think this pattern idolizes a certain type of developer and therefore limits the opportunities for mentorship for those who try to strictly follow what the pattern is advising. This pattern seems to focus on those who are directly working on the development of a particular language, framework, tool, or some variant of open-source software. They even pretty much open with the idea that it is very likely that your mentors are not local and that you will likely never meet them. I think that this is where the pattern is failing.
From my experience, there is almost always someone, or a group of people within a company that those with technical positions turn to for mentorship and advice. At my most recent internship, it was a man named Kurt who has worked on the proprietary software (Oracle) before signing onto the company that we both worked for over the summer (TJX). He initially was a contractor from Oracle, but TJX found that his expertise regarding the frameworks that made up our software made him too valuable to let go of and they hired him full time. He immediately became the go-to guy whenever anyone had a question about our software. He had been working on it for over 15 years and had gone through over 10 iterations of the software. A key thing to note is that while everyone asked him for help, they weren’t asking for mentorship. This is something that came with my internship as he was selected to be my “buddy”, which was just a fancy word for mentor. We spoke several times throughout the summer about both career goals, and different ways to solve problems. We spoke about how to solve certain problems that were specific, yet more general than our specific code base. To get this kind of mentorship, I didn’t need to lurk on an internet forum, and the same went for everyone I worked with that wanted to learn from him. All I had to do was ask. There will likely be a Curt everywhere, any of us end up working, and I plan on utilizing their mentorships.
I decided to read “Record What You Learn” for this week’s post. This one is pretty self explanatory, record what you learn. The pattern says to do just this, and explains that this is a way to review key learnings throughout your journey of software development craftsmanship. The pattern also notes that it is important to not let your writings become a graveyard for what you have learned. By this, they mean that you should consistently go back and review what you’ve written in the past to possibly amend the posts, or to find links to other notes you have written.
I agree that this is a very valuable “study” technique and it works for all facets of learning. The most difficult part of this, is that this is a very time intensive way to remember everything. As you learn more, the bigger the library of written lessons gets. This mean that every time you learn something, that review session gets longer. I think that this means that it is important to acknowledge that you simply will have to relearn things from time to time, but documenting what you’ve learned for higher level topics, is a great way to save time in the future.
While I do see how this could be difficult for an individual who is learning vastly different and often irrelevant topics when compared to each other, this is definitely something that can be used as part of a company project wiki. Large companies are constantly hiring new personnel who have to play catch-up to learn a code base as well as the coding styles of their peers. Having some sort of blog or wiki for the project could help these new-hires get acquainted with how the company functions and how to solve problems that are specific to the particular stack and business logic that the company is utilizing.
I do not know if I see myself personally following this advice, because this is not really my learning style. I tend to learn something by repetition instead of documenting what I’m doing. However, I do recommend that anyone who learns well via methods like flash cards, studying notes, etc, give this method of learning a try. It could be quite useful to someone who succeeds` when applying these learning methods.
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.
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.
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.
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!