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.

This week I decided to read a blog post for my blog entry. The blog post I read is titles “These tools will help you write clean code” by Adeel Imran. Before finding this blog post, I’ve had a general and basic idea about coding and how it should be written, but I haven’t understood in great detail how to properly write clean code. The reason I chose this blog is to learn and be able to use the clean coding techniques on my future projects so it will be easier for other people read.

Clean code is extremely important in becoming a strong software engineer and when working in a team having clean code is a must so your teammates can understand your code. The blog opens up by saying that in more or less all software engineering jobs you will be working with a new code base at one point or another and that inconsistency is a big fundamental problem when working with different code bases. The author ends the blog by saying “In the end, coding is writing” and as a developer our responsibility is to maintain a consistently so it will make our code easy to follow when being looked over.

Besides all of the great resources that it gives, a major takeaway from this blog that I will apply immediately to my next project is using clearer names. Before reading this blog if I wouldn’t put much effort into naming things in my project but I learned that applying clear names not only improves readability, but boosts the context making the intent of the code easier to read. If I am to use clear names it will help the reader understand more quickly.

My goal is to become a software engineer and in the CS program sometimes it is hard for me to write clean code because I am focusing on other parts of the assignment or don’t have this labeled well. This article has given me ways to write clean, effective code in the future and I hope it can do the same for you.

https://medium.freecodecamp.org/these-tools-will-help-you-write-clean-code-da4b5401f68e

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

Hello readers, welcome back. This week I will be talking about code reviews and why they are essential to the testing process in computer science. I read  a blog titled “what is code review and why is it so important” by Eugene L. who is a project manager. He begins his blog by talking about how code reviews is a great form of communication between team members and for junior developers, they can become more proficient through this communication and at the same time help improve the code. Although code reviews are used to spot bugs, they have resulted in teams understanding each other better which companies enjoy. Another point brought up in Eugene’s post is that code reviews increase productivity. Because the code will be reviewed by someone else  the developer will be motivated to write better code and make sure its flawless. Finally another reason code reviews are essential is that it helps the developer understand the product better and as a result will be able to communicate better .

This blog had great points and helped me understand why code reviews are  so important to when testing. When it comes to myself, sharing code hasn’t always been a strong suit with me because I tend to get nervous when other people view. I understand that I’m not the best and I understand after reading the blog that one of the ways to improve is by having my peers review my code. Feedback is necessary to have successful code reviews. If you’re working on a project with someone else or a team, you would want to make sure that everyone understands your code and how it effects the product, as a result it will improve the team chemistry. In my recent projects that I have had in my, I try to make sure that my code is understandable. Code reviews are a crucial part in testing and with them, the product will be much better than it would be without it.

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