Category Archives: Week 9

The Long Road

This week’s blog is gonna be about “The Long Road” pattern. This pattern is all about traveling the long road. No matter how much you try to master anything, it will always be ahead of you. Mastery is a lifetime journey. You got to love whatever it is you are mastering. That is why they said, “Choose a job that you love and you’ll never work a day in your life.”

The book suggests valuing long term growth opportunities over salary and some sort of leadership or managerial role.  This long journey to become a master will bring you a rich set of skills. You will become skilled at learning, problem-solving, and developing a good relationship with your customers. You will learn to wield these abilities and technologies. If you go through this long road, you will realize and appreciate what being a software developer really is.

This journey would not be short. It will be a long winding road. You should have a goal. Being on this long road, you will be a software developer even when you’re old. This pattern is not gonna make you filthy rich like the other positions, but it will be rewarding. This pattern is not for everybody, there are more people who will take a higher position without blinking an eye. Everyone wants to achieve something big and probably make more money.

I don’t really agree with this pattern. I think that taking the promotion would be a better path. It is not every day that a promotion would happen or a better position would be available. So why not grab the opportunity. It will also teach you more skills since it would it is a different role, it will also have different responsibilities. You will also learn how everything is run in the company and not get stuck at just creating software. They do talk about in the solution, that this long road does not only apply to being a software developer but for any position.

This pattern is good if you see yourself doing the same thing 10 years from now. Although, in my opinion, that is not a good thing to do. I think we need a bit of variety so that we do not get tired of it.

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

Pattern 5 – The White Belt

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.

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.

Apprenticeship Patterns – Use the Source

Use the Source is about the importance of reading other people’s code. Reading code is important because it is the only way to truly understand a system. Without studying and emulating examples of good code, you may never realize the bad habits that you have. A good practice is to read the code of the applications and tools that you use every day. By doing this you will learn good programming practices and start to understand the systems that surround you. It is also important to have other people read your code. Taking feedback from others will help you become a better programmer. Thanks to the large amount of open source projects available, it’s possible to read or contribute to a wide variety of projects built by the global community of software developers.

I enjoyed reading this pattern and found it to be extremely relevant. It is true that the only way to really understand code is to read it. I found it interesting how the author said that working programmers spend far more time reading code than writing it. If your only experience coding is what you’ve done in school, that might be hard to believe. But it makes sense for a number of reasons. Professional developers work on projects much larger than those that students work on, and all of that code must be read in order to understand it. Developers also don’t want to reinvent the wheel for every project, so a lot of time is probably spent reading implementations that others have created. Being able to quickly understand what a piece of code does by reading it is an important skill that isn’t taught in school. To become a great developer, you have to spend a lot of time reading other people’s code. This will introduce you to new ideas and better coding practices.

I thought that this pattern was very useful. When I have wanted to improve my coding skills in the past I have always tried writing new programs. I never realized that reading code is just as important. This is a great pattern that I will definitely try to implement in my life.

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

Apprenticeship Patterns – Rubbing Elbows

The Rubbing Elbows pattern is a solution to the problem of productivity reaching a plateau. If you always develop software by yourself, you may eventually get the feeling that there are superior techniques that you don’t know about. In order to fix this, you must rub elbows with another software developer. This means you must work on a hands-on task, side-by-side. This is necessary because there are some things that can only be learned when you are sitting with another software developer working to accomplish something.  There are many little techniques that can only be picked up when collaborating closely with somebody. The author uses pair programming as an example of this pattern. Apprentices should always look for opportunities to work on teams that use the technique of pair programming. However, pair programming isn’t the only application of this pattern. You can collaborate on a number of things such as a presentation, academic paper, or an open source project’s sprint. The goal of this pattern is to find ways to expose yourself to the working habits of other skilled people so that you can pick up on those habits and refine your skills.

I think that this pattern makes a lot of sense. If you are programming by yourself all the time, you will almost certainly reach a plateau because you aren’t being exposed to new ideas and techniques. Reading this pattern made me realize how important it is to work side-by-side with other people. It is true that by doing this you will pick up on the small techniques that the other person uses, and will learn things that can’t be taught in a book or classroom. I really liked the Richard Sennett quote about the ideal craft workshop. It captures the idea that gaining knowledge isn’t just about listening to words, but absorbing the thousands of little techniques that make up a skill. After reading this pattern I have a greater appreciation for pair programming, as I now realize the benefits of working on a task right next to somebody. Overall I found this pattern very useful and it has inspired me to rub elbows with fellow software developers.

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

Practice Practice Practice

Hello again! For this week’s blog I have chosen to write about the chapter from our textbook entitled “Practice, Practice, Practice”! The reason I chose this is because I saw it in the table of contents and it looked like something relateable and interesting to read. So without further ado, let’s jump on in to the chapter “Practice, Practice, Practice”.  The problem set up by this chapter is that you are always switched “ON” which never gives you a chance to learn from your daily programming mistakes. The book says its almost as if you’re always on stage. I feel that this can happen easily especially in a fast paced work environment like software development. Things in this field are always growing and changing and twisting and turning. Monday you might get assigned a project with requirements ABC and by Wednesday those requirements have changed form ABC to XYZ and the project now no longer holds any resemblence to the original project. In this case it is quite easy to get lost because you don’t have time to learn from your daily mistakes if you’re always trying to play catch up. The solution set forth by the book is interesting, however quite elementary and almost common sense. The main objective of the solution is to practice coding in an environment with zero pressure and in a place that you are comfortable and it is okay to break things. In other words, make a personal project at home or someplace other than work where the end objective does not matter, there is no customer or end user on the other side, and you can be free to break things and learn why they broke, then fix them at your own pace, allowing you to learn more so than if you were to be pressured and rushed to fix breakages in the field. There are many different ways to practice without interruption at your own pace where the actual environment does not matter. I think that it is one of the strongest ways to learn. Not only because you are teaching yourself (because you know how you learn best!) but because the environment in which you’re learning is truly stress free and problem free. Did it break while you were working? Who cares! It isn’t effecting anyone other than you. So take your time, work through the breakage, and fix it at your own pace and learn why it broke and how it was fixed!

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Craft over Art

While forms of craft and art may seem similar to one another, sometimes it is important to note the distinction. This is the exact distinction that Craft over Art outlines in Chapter 3. The point is that crafts have utility, and works of art are made for beauty and reflection. It’s important that, if you’re crafting something, that you treat it that as it is meant to be treated — because it is something that may be used in the future by someone else. Sure, there is room for artistic expression in your craft, but they shouldn’t be anything more than decorative or stylistic touches. As they point out in the book, craftsmanship is built on relationships. It’s about delivering value to a customer and using that to earn your living. Art is usually something that comes from a very personal, self-reflective place that others may connect with. “After all, there’s no such thing as a starving craftsman.”

I like this pattern because it encourages the reader to focus on doing something useful as opposed to something beautiful, as stated in the action paragraph. I feel as though this is important because as of late, I’ve been focusing on this a lot myself in anticipation for upcoming coding interviews. Although I may not be working on things I find myself feeling extremely passionate about, I do feel happy working on what is expanding my skill set. Practicing the language fundamentals of both Java and C, doing interview-style questions, and my independent study have been a blessing in terms of knowledge and learning. They’re all things that will allow me to push the boundaries of my skillset for my future projects.

I will disagree partially with one thing about this pattern, though. I feel as though with the degree that web development, specifically front end, revolves around design choices, that programmers with an artist’s mindset have become extremely valuable. With the amount of emphasis placed on good website and app design, there is absolutely a place for those programmers who seek to make beauty with code where there may have been less of a place for them in the past. Granted, these are UI/UX designers who are partaking in a craft themselves — their art has utility and is meant to be used by others.

Regardless, I found this pattern fairly interesting as a reflection of what programming is and what it is meant to be. Placing yourself in the mindset of a craftsman makes a world of a difference (at least, to my geeky brain) in terms of how you should conduct yourself in the work environment.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “Nurture Your Passion”

In this week’s post, I will be discussing the apprenticeship pattern “Nurture Your Passion,” as presented by Adewale Oshineye and Dave Hoover.
I chose this chapter because I think I have felt like I’ve been just getting by for a while now. The  problem it identifies as, “You work in an environment that stifles your passion for the craft.” I don’t think that’s quite fair to my school or professors. I think that in any discipline, if someone is only studying for the tests or working on the assigned projects and calling it a day when they have passed them in, they are not truly adopting the apprenticeship mindset.
Without a constant push forward, I will stagnate. I may get an “A” on the exam or project, but if I forget the material the next day, there is no point. The pattern suggests finding something that sparks interest and pouring myself into it. I have been wanting to do this for a while, but I have made excuse after excuse of not having enough time. The next sentence in the book says “consider putting in extra some time.” It often feels that is easier said than done.
I am reminded of the quote in the beginning of one of the chapters from this book by CS Lewis.  There should be no excuse for starting work. “Favourable conditions never come.” I got very little done over winter and spring break, and I won’t start the next break if I don’t start now.
The pattern goes through some other patterns and notes their relevance. I have blogged here about a few (e.g. “Kindred Spirits”), and a few others piqued my interest, so I read a few of them as well. “Breakable Toys” seemed particularly interesting. I may write here about it in the near future if another pattern doesn’t catch my eye.
I really liked the action. It was while commuting to work, think of three positive ideas to talk about, and when feeling down, shift the energy to one of the exciting ideas. They say this is to avoid getting dragged down. Furthermore, on the way home, they say to reflect on how successful the day was, and think how to improve my environment.
I like how this is a very achievable action. It doesn’t require me to spend any extra time on it. I commute to and from school everyday, and it will likely be the same when I start in the workforce. More often than not, I am already thinking about this sort of thing already, but in a different context. This will be a very natural thing to shift my way of thinking. I could see myself implementing this from here on out.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

This past sprint was a good one, even if we didn’t manage to get a tremendous amount of actual development work done. We divvied work up amongst our different groups and had a lot of discussion regarding how to start our project and what approaches to take while doing so.

We got in contact with Gregory Schmidt, a development lead with the official AMPATH team. Mr. Schmidt provided us with a fantastically detailed outline for the rest of our project. It included an interactive wireframe built using zeplin.io as well as a series of videos describing the project plan and the objectives behind the wireframes. Originally we had intended to clone and develop components as branches on our forks from the original ng2-amrs project. However, once we realized we were essentially making our own small to supplement AMPATH’s, we restarted by making our own repository for a GitHub organization for the whole class. The organization is split up into the different development teams we’ve organized ourselves into as well. Inside of this organization is the repository we’re using now, which contains a small blank angular project, and we intend to use it in the upcoming sprint to build off of.

Not only did we figure out how to host the project we’re working on, but there was a lot of initial discussion regarding how to manage the progression of components during development. For example, we had originally intended to use Trello as a scrum-like “task board”. Although it was later decided that, since we can introduce issues into GitHub’s issue tracking board, we would use that. By using Github’s issue tracker, we can set up an issue for each component, and even have several issues per component for teams to adopt and develop. On top of this, we can more easily display to the class which teams are developing what components, and who is within each team. Having all of this data reside in one place streamlines the development process and makes it significantly easier to determine what has been finished and what needs to be worked on in the future.

Our professor has been doing a lot of work in trying to figure out what the development process will actually look like. The class was trying to discuss how we wanted to handle branching — I proposed the idea that we would have one branch per component being developed that would get merged into the final project once that component was completed. Come tomorrow in class, the professor will tell us exactly how we’re going to start the development, however he has already said that instead of one branch per component, we’re likely going to do one branch per user story. Then, of course, we can branch off of those into sub-branches if need be. I believe there was talk of also using GitHub’s Milestones functionality as “Epics”, which if I’m not mistaken are essentially larger, more broad issues to be completed. For example, if we need a page of our application that has both a menu and a search bar, there might be more than one component that goes into that. This page might be considered an “Epic”, because it would involve many stories being implemented at once. Having Epics would be really helpful to guide the overall development process, so implementing them as Milestones could potentially be very useful.

We’ll have more information regarding what we’re doing in the next sprint come tomorrow, and we’ll be starting some legitimate development this next sprint, which will be great. I’m excited to get started!

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Practice, Practice, Practice.

We all want to get better at something but we often don’t really know what to do to get better. Sometimes, we can find ourselves repeating the same mundane tasks in hopes that something will just magically change or snap and we will be better at whatever it is we are doing. However, this couldn’t be further from the truth. When trying to get better at programming, you often have to practice things that you are not comfortable with. That’s just how learning works. In order to learn something new or get better at something that you need to improve on, you need to step out of your comfort zone in an environment that you feel safe doing so. Although practice may not make perfect, it does make permanent. Even if you are trying something new and you don’t quite get it right away, all that practice beforehand and grinding will not be of waste. You will just be reinforcing your skills, enhancing you previous knowledge. This pattern is great because it tells you to just keep working at whatever task you want to get better at. It also points out that just because you are repeating the same thing, that doesn’t mean you are not getting better at it. Choosing the right thing to practice every day is just as much as a skill as repeating something a lot. They are both important in that you are learning and reinforcing at the same time. Some of the books that the article pointed out that are good ways to ensure you have interesting exercises are Programming Pearls, More Programming Pearls, and Etudes for Programmers. The authors of these books understand that getting fundamentals deeply ingrained does not stop being useful. Practicing anything, as long as you understand what you need to do, you will always get better at something. That is just how practice works. Even if you think you are not getting better, you are still simply reinforcing already known ideas. This pattern is a great example that you can still try something without the fear of failing, because you just get better at it regardless of the outcome.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

Toying Around

Breakable Toys was an interesting pattern to read about. The premise is that in order to develop your skills, you should spend some time single-handedly developing small software projects. The example the text gave was maintaining a Wiki, which over time develops many skills in different areas. Ideally you will be able to find enjoyment in your toy so you can continue to grow from it. This toy is also something you can take with you, and something you can continue to learn from.

The idea of Breakable Toys was one I’d never really thought of before, but after reading it I can say that I’ve probably used the pattern to some extent. I can recall a time where I was learning HTML and CSS just to customize a web-page on an online game. At first, I had no idea what I was doing, but after some research and a lot of experimentation and trial and error, I began to have a much better concept on designing a web page. Meanwhile, I was enjoying the learning experience and the progress towards building something of my own. The ability to find enjoyment in what you learn is what eventually lead me to where I am in the first place.

After having read the chapter on Breakable Toys, I think I will try to be more intentional with my use of interesting and fun things that simultaneously develop my programming skills. One idea would be to develop a game in a new language, that way I can learn a new programming language and do something I enjoy.  Eventually, I can also develop the same game for any new programming language I wish to learn, as an interesting way to see some of the differences and similarities between them.

Something I’m learning about a lot of these patterns is that they are all sort of things that people just tend to do naturally to try and aid their own development. I guess that’s the whole point of the patterns, but it is really insightful to have some of these ideas put into words.

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.