This week I read Record What You Learn in Chapter 5, Perpetual Learning. I read this partly because I found irony in recording what I’ve learned about recording what you learn, but also largely because I’ve heard it given as advice in the past, and it is something I’d really like to put in place for myself. The pattern itself reflects on the situation where you learn something for whatever reason, be it for work, school, or personal development. However, without dedicating time towards fully understanding the concept, it doesn’t solidify and you fail to retain the information. The proposed solution is to write. Write as much as you possibly can about each and every part of your journey. Make time for it, because by simply putting concepts into your own words and jotting them down on paper (or on a blog, like this), you etch that knowledge into your head far easier than you would simply trying to absorb the information.

I’m sure we’ve all been in the position where we’ve learned something and then completely forgotten it some time later when we’re meant to recall it. Perhaps on tests, for work, or in conversation. We know that we’re familiar with it, but we seem to fail to remember it fully unless we seek to make it our own, and really feel it out. Take mathematics for example. In order to solidify a concept, you need to learn it and practice its implementation in several ways to really grasp the meaning behind it. Simply trying to absorb the information in one lecture or introduction won’t work for nearly anyone. So why, then, would it work for a theoretical concept in any field, or even something like a life lesson? You need to practice thinking it through in different ways. Writing about things does exactly that.

Part of the motivation behind starting this blog during my Software Development concentration was to have a portfolio to point to that shows what we’ve worked on during our classes. Not only that, but it was a means for connecting with the greater software development community. However I’m finding (through being more consistent with my blogging) that perhaps the most important thing isn’t any of these, and that the majority of the benefit has come through the act of journaling about what I’m learning. Everything I have learned and written about, I feel like know well. Coming from someone who felt extremely awkward about blogging when I started, this was an interesting change of heart — and a welcome one at that.

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

          The “Expose Your Ignorance” pattern is described as a way to come to terms with the fact that you won’t know everything in your field. Everything starts as a learning process when you enter a new team. It becomes easier as time goes on and creates a better environment when your team sees you making sufficient progress and growth. The pattern explains that creating a strong relationship with clients and colleagues causes them to grow more interested in your growth as a developer because of the increased efficiency you gain which in turn helps push development even further. Telling people the truth that you’re in the process of learning new skills may make them see you as an amateur but it is certainly better than giving them false promises of creating a finished product on time when you can’t quite deliver on it. This also brings up the point of asking questions, since questions can also show your ignorance but that shouldn’t matter as much since it all is a learning experience. You must ask questions if you plan on putting your pride aside and showing your team that you truly want to learn without taking any shortcuts.

          I found the importance of being honest with your team very useful to expose your skill set to them. The idea of letting your team exactly what you can and can’t do will help them better gauge what tasks they should start you off with to make the learning process easier. I enjoyed the fact that the book doesn’t tell you to shy away from asking questions. Questions can make you seem much more ignorant but the reason why you ask questions is to learn in the first place. This pattern expresses the importance of learning through honesty with your teammates which I will incorporate into my own experiences. The honesty aspect also will help with trust within the team as it shows that I’m not willing to hide anything from them. I overall enjoyed this pattern and agree with it completely. It repeated some very important aspects of teamwork and honesty that I will make sure to never forget.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

This is another important chapter in software development, chapter four “Accurate Self-Assessment”, they are talking about how we assessment ourselves. “The talented and hard-working apprentice must not become self-satisfied with his success.” We know there is never ending road of learning in this business. We must fight mentality by seeking out and learning about other teams, organizations, journeymen, and master craftsmen. We always to leave room to recognize ourselves if we are going easy way and room to improve.

Again, when we are walking on “The Long Road”, you find yourself stranded without mentors and in an atmosphere that seems at odds with your aspirations. The road is not mean to walk alone, we need camaraderie. It is can be difficult for some people, including myself. The people we meet along the way could make huge impact on us. There are always someone who on the same road, or ahead of us, someone we have career connection with. We can feel free to show each other what you’re learning and have no obligation to follow the other’s lead. We also should be someone who benefit to our community. This is how our industry get to next level with welcome open arms.

The pattern “Kindred Spirits” also suggest that trying to join all the communities you could join based on what you are interesting. Also join new group with fresh open mind. Inside your group, feel free open discussion and become “regular”. I do like this suggestion; I think this is one of the best way to meet new people and learn naturally. This is what I will try to do more, not just get out of comfort zone but surround myself with people with same interest. Be kind to one another is the best way to be a community.

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

This week I read about the Share What You Learn pattern. The pattern is all about sharing the knowledge you gain with your peers. After all, what good is all that knowledge if you don’t share it with the rest of the world? Making good use of the pattern ensures that you and everyone around you will be up to date with all need-to-know information, and gives you a good opportunity to both brush up on your teaching and communication skills and also discover what your peers know that you don’t. Everybody benefits when you share your knowledge, as it allows your peers to focus their efforts on other endeavors that haven’t been solved yet.

It is not always easy to share what you learn. Sometimes you are engrossed in your own work and don’t want to take the time away to help someone else. Maybe you think what you know is obvious and not worth explaining. Either way, it is always worth the time to help out your coworkers or fellow students. First of all, when you need help, it will be good to be able to rely on others. Second, everyone being at the same level opens up more opportunities for learning and growth.

My biggest obstacle with sharing what I know is how to communicate effectively. I am a poor communicator, and often lose myself over which words to say. It can be hard for me to effectively teach something to someone, especially with no time for preparation, as my train of thought tends to go all over the place. Knowing this, I need to work on methods of communicating information and think more carefully about how I am saying something and how it is being understood.

In conclusion, Share What You Know is a useful pattern, and one I aim to improve at. Sharing knowledge across a team is better for all the individuals involved. The more you know, the more time you can dedicate to your work and the more diverse kinds of problems you can solve.

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.

This week I am reviewing another pattern from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. For this week’s pattern I decided to go with the chapter “Your First Language”.  The context of this chapter is you have a shallow understanding of one or two different programming languages. This chapter grabbed my attention because while I have been in school for four years learning software development, I still feel that I only have a shallow understanding of a few different languages (in this case Java, C, and python, but Java is definitely my strong-suit). I feel that from the perspective of the classroom we know a decent amount about our languages, but from a real-world point of view, we only know the proverbial “tip of the iceberg” meaning that we still have much  more to learn about our languages. The problem presented by the book is that we feel that we need to be masters at our first programming language in order to be a good programmer and a purposeful part of your team at work. While the book says that you should not stress over the fact that you only know one programming language, they also point out that most jobs require that you know at least one programming language inside and out to get the job. This is a “catch 22” because jobs expect you to be masters in a language and be extremely proficient but at the same time they understand that you likely have little to no experience with your language because all you have had experience with is programming assignments in school. This kind of puts us at the disadvantage because we are expected to be masters at our trade to get an entry level position at a company we  may not be at forever. The solution proposed by the book is to improve your learning of your first language. How does the book propose this? By having actual problems to solve with your programming language skills and knowledge. I think this is important because using your skills to learn how to solve actual problems helps you retain your programming language skills and makes you a better programmer.

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.

As you may know, for our end of semester senior project we worked in groups of two in charge of developing a web application that had some sort of functionality. When we were first introduced to this we didn’t know whether to feel scared, nervous, excited or all of the above. What is HTML, CSS, angular, boostrap, etc.? So many things were thrown at us but in the end we made it. We learned all of it and no the question is.. are we full-stack devs? Maybe Eric An can answer that question in his article, ‘What is a full-stack web developer?’

The article begins with a big red T shaped image. The T-shaped model is a concept that describes the abilities/characteristics of an individual where a person has many generalized skills with a specialization in few. The full-stack web developer supposedly knows many technologies but specializes in few which is front-end development and back-end development.

Front-End web development is the presentation of the website which includes HTML and CSS and sometimes JavaScript; pretty much everything that the user sees when clicking a link. The goal is for users to provide a platform for users to interact with. Some other skills may be UE/UI design. For our project we learned the basics of HTML and CSS and I also learned how to use bootstrap to make things much simpler. Front-end development was a success!

Onto the back-end web development.. The creation of data collection processes haunts us to this day. We redefined the definition of struggle when it came to the back-end part of this project. Back-end development is associated with the front-end where as a server is being created to communicate with that the user is trying to do on the front end.

The definition of a Full-stack web developer is an individual who is in charge of performing both front-end and back-end so that all of the technologies put together makes up a website. After reading this article, although we are not experts in front-end/back-end development we could be considered full-stack developers!

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

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

Towards the end of the semester we were working more intensively in group settings and even increased the number of individuals in our group which required greater collaboration among peers. I recently came across a post ‘Code Review: The Unit of Work should be a Single Commit’ by Paul Hammant. In this blog Hammant talks about the benefits of Code Review and how the end result is significant change in the way the program was written.

Some of the benefits he listed was:

– Two pairs of eyes catch more bugs (which saves hours of debugging if fixed early)
– Enforce coding standards, style guides (keeps overall readability & code quality high)
– Mentoring of new developers (learning from mistakes without breaking stuff)
– Establish trust relationships
– A good alternative to pair programming.

Our last few classes we as a group came across all of these aspects and more. We worked collectively as a team code reviewing some program and found that we listed many similar mistakes. Another important point he makes is that there is only so many times something is modified in review before it is considered ‘done’.

Although Hammant talks about reviewing code over Git and we did ours as a group in person the idea remains the same. Some steps he talked about were to lock a commit for the duration of each review and also how to move forward with which review change when two individuals have different points of view. I found that this article was relatable to our experience.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

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