Sprint Reflection 4

Our fourth sprint started out a little better, with us fixing the issues, stories and tasks assigned on Git so that our group could be more clear on what was being done and by whom. This also helps us communicate with the other food pantry group outside of class. Narrowing down our stories and tasks helped us more clearly define our goals and what we were working towards. Once we were done fixing the stories and tasks, we discussed who would be taking on what task.

I took on the task of adding a weight counter component to the intake form. We first had to determine exactly why the weight was being kept track of and what changes needed to be logged to better implement the weight system the food pantry needed. After determining some of the needs of our clients, I started working on making the new component. However, our group quickly ran into issues as we had a lot of difficulty in maintaining our git repository. We spent a good class period trying to fix some of the issues we were having just getting the working code onto our local machines.

As it turned out, our git.ignore file was located in the wrong place, and a lot of the local files that aren’t supposed to be uploaded and committed were being placed on the group repository. NPM and NG commands were not working properly and things were pretty disorganized. It was hard to get a working version of the front end so that I could begin to make my changes to it. After a long class discussion with the Professor, we discussed better ways to make sure the repository isn’t getting dirtied with unnecessary files, and talked about how to add changes to the main branch and utilize pull requests accordingly.

Now that we finally have a working copy of the form back on the repository, I have begun work on the weight counter again. It is going to be a new component that tracks a current weight, and can add/remove to the weight depending on user choice. Other considerations are storing the time and date that changes are made to the weight, and making descriptions for weight changes. Other future things to consider are logging which Student ID takes out weight so that customers can only receive from the food pantry once a day.

This sprint was very stressful as our group fully realized some of the issues that can arise from git repositories. Although it was mind-racking to try to figure out what the problem was, it was very useful exposure and practice to some of the mechanisms of git, as it will doubtlessly be very important in the future. Although I am still wary that I can use git commands perfectly, I am definitely much more equipped to deal with repository related issues in the future, and am more aware of some potential issues that can arise from a misplaced git.ignore file. Hopefully I can avoid some of these problems in the future, as git problems can get annoying fast.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Blog: Use Your Title

Hello and welcome back to Benderson’s blog! This week we will be discussing another Apprenticeship Pattern that is important to anyone getting a job and is afraid of being ridiculed for your lack of information to work in a computer science job. This pattern is called “Use Your Title” and it discusses being promoted into a role such as “Senior/Architect” of a business and how to approach such a role in a job. You may feel like that you don’t deserve this job or you’re not right for the job but you got to believe in yourself to succeed and be the best you can be. The pattern talks about not letting the title affect you from your performance and just keep doing you and if you doing you gets the job done than that is all that matters in the end. The pattern also talks about the other side of the coin where if you have an unimpressive job title but all your buddies have a cool upper job level and are succeeding, don’t let that distract you from working hard at your job and feeling like you deserve better. You’re doing the best you can and when your time comes, you will be called up and if it doesn’t happen then just find another job that appreciates you as much as you think you deserve. The pattern suggests in the end that you write down a long and descriptive version of your job title and reflect on it and what it means to you and you will see if you’re right for the job.

This apprenticeship pattern really hits home to me as I feel like I won’t know enough to get a job at any level and hold it long enough to make myself big in the business. That could me just not having enough confidence in myself which is probably the case. This pattern is helpful for any kid in my position who is fighting themselves mentally trying to psych themselves out of a job that they could easily do. You’ve gone through four years of college education in the field of Computer Science for this job, don’t let yourself put you down and make you think you will not be able to do it. Also no matter the job title you get, it is still a job and if you work hard enough you will be able to climb the ladder and get to where you want to be. Thank you for joining me this week on this inspiring edition of Benderson’s blog!

From the blog CS@Worcester – Benderson's Blog by Benderson's Blog and used with permission of the author. All other rights reserved by the author.

Sustainable Motivations

For this weeks Blog Post I will discussing the pattern known as “Sustainable Motivations”. The Sustainable Motivation pattern is almost what it sounds like, where you require motivation to keep going. Anyone who knows programming knows that if a programmer is given the chance to do it there way, that is there biggest motivation. The context behind this is that you must develop your technical skills because of this you will find yourself working in a messy reality of specified projects for customers with different demands. The problem that arises is that when working in the real world trenches of projects you will find rigorous, tedious, exhausting, frustrating and constraining effects. The solution to this is that you need to ensure your motivations for craftsmanship will be able to adapt and survive through the Long Road ‘s (pattern) trials. For the most part there will be days and more that you love your job, getting paid to develop software and such. Where the work will just come natural to you without much effort. These days wont be ordinary days, because most programming jobs you will face tedious, vague definitions, and overly complex problems. You could even face some spotty leadership problems, difficult coworker personalities and other troubles. Because of this you may begin to question your commitment to the craft. When faced with these problems its almost imperative that you are aligned with the Long Road. Some examples could include you hating your programming job and are only motivated by the money. Where you value climbing the corporate ladder over honing the skills of your craft. But also are motivated by your reputation as a technologist, allowing you to survive and endure to the sun shines once more in your job. Another example could be you are motivated by your enjoyment of actual programming, where you then come up on a length of time where you cant find the love. But you are motivated by the money, and that programming is financially the best option right now, causing you to be motivated. All of these are good examples of how to be motivated but the best way to figure out yourself is to write down some motivations for you. Keeping this list somewhere safe where you can come upon it when times get tough. This pattern is something 96% of people can relate to, in almost any motivational situation and one I will see myself using down the road.

From the blog CS@Worcester – Matt's Blog by mattyd99 and used with permission of the author. All other rights reserved by the author.

“Concrete Skills” Apprenticeship Pattern

I am writing this blog post about the “Concrete Skills” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about dealing with concerns about seeking a role on a team but not having any practical experience. I chose to write about this pattern in particular because I find it relevant to myself at the moment. I am searching through job descriptions and they all seem to prefer certain areas of experience that I do not have. This is also evident in our capstone project. The “solution” section of this chapter in the book says to gain some concrete skills. I do have concrete skills; my aptitude is for mathematics, data structures and algorithms – computer science in general. It refers specifically to “tools” and “technologies”, though, and I know nothing about that. It becomes apparent when I work on the capstone project that my expertise has no application here. This sort of computer programming has nothing to do with computer “science.” There is no logical problem to solve, there are only tools and frameworks to learn how to utilize in order to accomplish some basic tasks. My past experiences have not seemed to have prepared me to be any better than anyone else at approaching these problems. It seems, then, that the “concrete skills” that I need are of a different sort. The chapter recommends looking at the CVs of others and finding a common set of discrete skills that seem important to become familiar with. This seems like a good idea. In order to gain some level of confidence about being able to perform on a team, it would be helpful to become familiar with the skills and common knowledge among the demographic. Rather than continuing to study computer science, there seems to be an additional field of knowledge that I am unaware of a name for, which is comprised of tools and technologies that are required for certain software development tasks. It seems like it will be important for me to gain some “concrete skills” in whatever field it is this might be.

From the blog CS@Worcester – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Sharing what I learned

 

 

 

 

 

 

 

 

 

 

 

 

 

Link to the blog: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s07.html

 

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

Reflecting on “Apprenticeship Patterns” – Expand Your Bandwidth

I have some very exciting news to share: I have recently accepted a software engineer position to start after graduation! I can’t wait to get started with this company, and I’m counting down the days until my first day there! My final interview involved talking with different members of the engineering team, and there was time allotted throughout the discussions for me to ask my own questions. There was one question that I asked everyone: “What is some advice that you would give a new graduate from a computer science program who is just getting started in the field?” There was one answer that came up the most, which was to not stop being eager to learn new things. This brings me to the apprenticeship pattern for this week, “Expand Your Bandwidth.”

This pattern exactly reflects the advice that I was given during my interview. Expand Your Bandwidth provides context with a possible problem of software developers’ knowledge potentially being focused to the type of work that they take part in on a daily basis. The solution is to simply begin absorbing more new knowledge at a faster, deeper rate. While the developer may find this process to be overwhelming, it is crucial that they can improve their ability to increase the level of learning new concepts and applying them to their own work. This process of expanding bandwidth includes actively seeking out knowledge, possibly through blogs, podcasts, courses, and contact with others who are as passionate about the topic as the apprentice is.

I couldn’t agree more with the suggestions and solutions that this pattern provides. I already have a list of several projects and practice exercises that I hope to complete throughout my career. I am so fortunate that the company that I will be working for seems to be ever-changing with the type of engineering work that is being done. I am confident that I will not run into the problem of work becoming stale or too routine. Nonetheless, I will be sure to continue to keep on taking in new information and building my field knowledge.

Thanks for reading!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Expand Your Bandwidth

In their chapter dedicated to Perceptual Learning, the authors offer some good advice under the apprenticeship pattern “Expand Your Bandwidth”. This pattern stood out to me because the main focus is on improving the learning process itself, not just skill building exercises.

The situation which the authors describe for us is an analogy which says that we as apprentices spend gain our knowledge by “drinking steadily through a straw”, and the fact that “there are seasons in an apprenticeship when one must drink from the fire hose of information”. This spoke to me because the fire hose metaphor is definitely how I feel. While it is important to take your time and learn the necessary development skills to their fullest extent, there are times in which we as apprentices need to open the flood gates of information and learn new skills and technologies as fast as humanly possible.

The reason why this pattern is called “Expand Your Bandwidth” is because that is the solution the authors provide for applying this pattern. They recommend a number of platforms such as a Google blog aggregator, following organizations on Twitter, as well as joining a technical conference whenever possible. I appreciate this advice, because it definitely makes sense to me to utilize the internet as much as possible as a vehicle for exposing us to as much information as possible, allowing us to accelerate our learning.

One important distinction or warning that the authors provide us budding apprentices is to not only know how to improve our volume and velocity of learning but to also know when to turn that off, and begin drinking from the proverbial straw again. While it is integral to be able to learn a vast amount of information efficiently, it is equally important to know when to slow down and focus more deeply on a smaller volume of data, allowing necessary skill development to accelerate as opposed to a broader learning approach.

This pattern definitely made an impression on me, and I will have to start applying that by taking up the authors advice to join a community or forum. Personally, I think I will begin by learning about contemporary industry related statistics provided by popular software development sites like stack overflow, etc.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

Pattern 7 – Sweep The Floor

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.

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

Craft Over Art

This blog is about another pattern from the Apprenticeship Patterns book. This pattern is about Craft Over Art. Choosing whether to add that extra feature that you think will impress your colleagues rather than focusing on what the customer specifies or want. This problem would occur to you more than you would think. We are not just programmers we are also artists. Creating beautiful, unique and creative applications are all within us, but if you are working for someone else, you might have to forgo of your creativity.

The book suggests focussing on delivering value to the customer rather than advancing your own self-interest. As a craftsman you are primarily building things in terms of the specification, working under someone and not indulging in your creative self. As craftsmen, we work for the customer. You need to do your best work in ways that place the interests of your customers over your desire to display your own skills or pad your resume. The book even says “If your desire to do beautiful work forces you out of professional software development and away from building useful things for real people, then you have left the craft.”  They said that the things we build for customers can be beautiful but it must be useful. That part of the process of maturation is developing the ability to sacrifice beauty in favor of utility when it becomes necessary.

I am split on this pattern. I kind of agree that we should do what the customer has asked us and enhance its quality, making it a software that can do almost everything that they needed. But, I also think that you can still practice art even if you are working for a company. You can inquire on your customer and see if they like what you are trying to do, but then again I see how this can conflict with the other software developers. Since you are not the only person that would be working on a project when you become an apprentice, there are things that others would think is not necessary to the software, so there definitely going to be things that gonna have to be agreed upon.

 

From the blog CS@Worcester – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

Journey into “Nurture Your Passion” (An Individual Apprenticeship Pattern)

On this Software Development Capstone journey part of my assignment is to choose 10 Individual Apprenticeship Patterns out of 35 patterns among Chapters 2-6 from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsmanby Dave Hoover and Adewale Oshineye. For my eighth individual Apprenticeship pattern I decided to blog about “Nurture Your Passion” pattern.

Summary

When you feel as if you have been hired into a software developer job that is asphyxiating your passion. Sometimes the best solution is to work on some side projects that you find interesting in your work place. If you can not find something interesting at work, then you can dedicate some time on the side building some “Breakable Toys”. Another approach is to ensure that you keep reading great literature in our field that will essentially help carry you through difficult times, such as ones that threatens your passion for the craft. You should also make sure that when joining an organization, that you are joining one with a career path that is related or will lead to your passion. This pattern also suggest us to make sure we “set clear boundaries that define the sort of environment you are willing to work in”. Understand that sometimes you run the risk that the boundaries you set might cause you to “get passed over for pay raises, promotions, kudos, or popularity. But these boundaries are necessary if you are going to break free of hostile conditions and keep your passion strong”.

My Reaction

This pattern helps you understand the importance of doing something you are passionate about. I agree with this idea because it make sense, we need to insure that we are nurturing our passion in order for us to remain happy and passionate about what we do. I found this pattern to be interesting but also useful and thought-provoking. This pattern has definitely changed the way I think about my profession and the way I think, the reason being is that it has made me realize that whatever I do, I should make sure it is something I am passionate about and I am always trying to find ways to keep that passion for the craft alive.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.