Chapter 13 of The Clean Coder discussed the importance of being able to work in a team, the right way.  Having the ability to work well in a properly formed team is very important in life, and especially as a computer programmer.  This chapter talks about something the author calls, a “gelled team”.  A gelled team is basically the idea that all team members will learn each other’s quirks, strengths, and weaknesses; which will then lead to the team beginning to “gel”.  As a team you need to work together and be aware not only of yourself, but also everyone else on your team.  There is no “I” in team!!  This chapter goes on to talk about how a good team will take the time needed to “gel” so they can progress and get as many projects done as smoothly as possible.  A gelled team is not formed around a specific project.  The author describes a gel team to have the ability to “accept many projects simultaneously and will divvy up the work according to their own opinions, skills, and abilities.”  I agreed with this chapter and agree 100%.  From my personal experience, being in a team that works well and fluently together has always been a much more successful experience then being in a team where everyone is kind of off on there own, and not communicating with one another.  It was interesting that the author talked about the idea of not forming a team based off of a project, but forming a team based off of being able to finish anything.  I really liked that idea, and it’s something that I personally have not seen in the workplace.  In my software engineering internship, the teams were mostly formed around a specific project.

The last and final chapter of The Clean Coder is chapter 14.  The final chapter of this book definitely summed up a huge aspect of what it truly means to be a computer programmer.  The whole point this chapter made was that school can of course teach you the theory of computer programming, but it will never teach you the discipline, practice, and skill of being a craftsman.  School is very helpful in getting the main idea of what you will need to be doing as a computer programmer.  School will teach you a lot of technical things like design patterns, algorithms, and how to code in general.  It is very important to know these technical and theoretical things as an engineer.  The chapter goes on to discuss that after we graduate from school and our on our way to the workplace, we are now the new mentors and guidance for the next generation of computer programmers.  When you are in the workplace you need to have the knowledge to be able to mentor the younger developers coming in.  As computer programmers we need to realize this is our job and soak in all we know now so we can later guide others.  You should pass your craftsmanship down to the younger people so they too will have the knowledge we have.

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

This week I read chapter 11 & 12 of The Clean Coder.  Chapter 11 discussed how to handle pressure.  I really enjoyed reading this chapter because at some point everyone is going to feel like they are under a lot of pressure.  The most important thing this chapter taught me is that you need to stay clam and don’t panic.  Panicking will cause you to be too stressed and not be able to think clearly.  This is not good for anyone.  You need to just stay focused and do what you can do.  A little tip I always think about when I am stressed out about school or something is that it’s not the end of the world.  Even if you can’t get something done, most people are very understanding of certain situations. However, you always need to COMMUNICATE.  This chapter talked about how no one likes surprises and that is very true.  If you are open and explain why you can’t get something done ahead of time, there will be no surprises when the due date comes along.  Many times people are willing to help.  One point that the chapter talked about that stuck out to me was to always avoid pressure.  You can do this by not committing to something you can’t finish and keeping your code as clean as possible.

Chapter 12 talked about yet another extremely important topic of the computer science world.  It talked all about working together.  Programming is literally all about working together and being able to collaborate your work together to make a great product.  The chapter talked about how you need to learn to talk to people and work together.  I know there are a lot of people who would rather work alone, but as a programmer you are almost never working alone.  I can already relate to this chapter.  Even just in my computer science major classes, most projects and group activities consist of us working together.  I personally work well in a team and I like working with people.  Collaborating with others has never been an issue for me!

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

This week I read chapters 9 & 10 of The Clean Coder.  Chapter 9 talked about a very very very important topic; time management.  A big thing this chapter discussed that I do agree with is that attending every meeting you are invited to is a simple waste of time.  During my internship, there was meetings I didn’t even attend because it wouldn’t have benefitted me in anyway.  You need to use your time wisely and not attend a million meetings a day, and then only have 3 hours to do your work.  It was very interesting that the author talked about your caffeine intake during this chapter.  During the work day, I tend to sometimes overload on caffeine. Although it does really help to keep me awake and focused, I can agree that I sometimes get a little too hyper.  If you are all cracked out on caffeine, you may start to focus on the wrong things which isn’t good to do.  I agreed with pretty much everything this chapter talked about.  I learned first hand that meetings can be an incredible waste of time, too much caffeine can be a not so good thing, and long walks and getting out of the office can really help.

Chapter 10 of The Clean Coder  discussed the topic of; estimation.  As a computer programmer, you need to be aware of what you can and cannot get done, and how long it is going to take you.  The book states, “Professionals draw a clear line between estimates and commitment.” This quote stuck out to me because that is extremely true.  A professional person wouldn’t make it seem like they were committed to finishing something if they knew they couldn’t get it done.  Computer programmers are human, and even though you should get something done by a certain date, sometimes it’s just not doable.

“They do not commit unless they know for certain they will succeed. They are careful not to make any implied commitments. They communicate the probability distribution of their estimates as clearly as possible, so that managers can make appropriate plans.”

The paragraph above was the most important thing said in the whole chapter.  I will definitely take this with me in my work in the future.

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

I read chapter 7 & 8 of the clean coder this week.  To sum up chapter 7, it basically talked about how important it is to write automated acceptance tests.  Communication between two parties can be extremely difficult in the workplace.  There are many times where a customer and a developer, or really any two parties might think they completely agree on all the details they discussed, but in reality they might leave having two totally separate ideas.  It is very easy to assume someone understands something when in fact they aren’t on the same page at all.  This chapter showed me that writing these acceptance tests are a great way to solve the problem of miscommunication in the computer science field.  The chapter defines acceptance tests as, “tests written by collaboration of the stakeholders and the programmers in order to define when a requirement is done”.  I really enjoyed reading this chapter.  It brought light to my eye that there is a way to fix the problems of not getting across what will be done clearly and precisely.  I remember in class we talked about “the definition of done”, and this chapter also discussed this.  Your definition of done can be completely different then the person sitting next to you.  It is very important to clarify specifically when discussing what is going to be done so everyone is on the same page.  I remember I had a presentation once and I thought one of the members in my group was going to make slides on a certain topic.  When it came the day to present, we realized that we completely miscommunicated and ended up both doing the same thing.  This chapter reminded me of this specific time.  It’s a good idea to follow this practice in order to prevent these types of things from happening in the workplace.

Chapter 8 discussed how important it is to constantly test your code as a developer.  This chapter touched on 5 main types of testing that should be run as frequently as possible.  1.

1. Unit Testing
2. Component
3. Integration
4. System
5. Exploratory

I could not agree with this chapter more.  The deeper I get into the field of computer science and programming, the more I am starting to see the importance in testing.  Although testing can be extremely tedious and boring, it is something that you must do as a professional engineer.  Many developers tend to think that they don’t need to test anything because that’s the QA’s job.  However, this is not true at all.  This chapter talked about the importance of the developers and QAs working together to test EVERYTHING.  An interesting statement that was mentioned in this chapter was, “It should be the goal of the development group that QA find nothing wrong.” I really liked what the author said and I agree.  In order to be a great coder, you need to not only be able to write a good program, but you also need to write good tests so you can catch the problems before the QA, or worse, the customer.

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

This past week I have managed to get the openMRS code up and stably running.  I began trying to run this by doing exactly what I did for the tutorial I completed last week.  When I realized that wasn’t work I decided to ask my teammates what they did.  Turns out there was a file called, “Read Me” on the git hub repository.  This file gave in-depth instructions on how exactly to run the code.  This was very helpful and taught me to look for that type of file first when encountering a problem with running unfamiliar code.  I have began to create a new login page at this point in time.  As I started to try to do so I was very confused with how I would do this.  I decided to take a step back and read up on some more Angular 2 stuff, focusing mostly on the structure of how you are supposed to code in this language.  This sprint I plan to successfully create the login page and then go on from there.  I still don’t have too good of an understanding of Angular 2 so I am going to try and understand everything I am doing when making the login page, rather then just doing it so it works but not really understanding what I’m doing.  Last week when I was doing the tour of heroes tutorial I didn’t always pay attention and understand what I was doing.  I was kind of just following the tutorial so it worked, which wasn’t the right way to go about it.  I should have been paying more attention to the things I was typing and not just copying down what it said to.  This week I will take that lesson and focus on learning the language as well as consciously getting the program to work.

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

Last week I finished the tour of heroes tutorial.  I learned a lot from just working through it and understanding the implementation of Angular 2.  I liked how the tutorial brought you through something and then had you change it to make it better.  For example, we started off declaring the type “hero” in on of the main folders.  As the tutorial went on, it had me move thedecloared type, “hero”, into its own class.  I learned a lot more then I thought I would from doing that.  This week I already forked the am-path project on git and got it up and running.  That was definitely an accomplishment in itself.  My goal for this current sprint is to work through the AMPATH code and to get a feel of how everything works together.  As of right now I haven’t actually looked at any of the actual code so I am planning to start that tomorrow or Thursday.  I think everything went pretty smoothly this week and I can’t really think of anything I would do differently.  I’m happy we are getting closer to finding out what we will be doing to contribute to the AMPATH project.

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

This week we were assigned to read chapters 3 & 4 of The Clean Coder.  Chapter 3 was very interesting to me right off the bat; mainly because it was the complete opposite of last weeks chapter “Saying No”.  Chapter 3 was called, “Saying Yes”.  To sum up the chapter, it basically discussed how to tell if someone means what they are saying, and ways to change what you say to really mean it.  I found this chapter very useful because I personally know that I say things I don’t really mean to commit to all of the time.  One thing this chapter brings up a few times is when you hear someone say, “I need to lose weight”.  That is an extremely common phrase that people say, but it doesn’t necessarily mean they are truly going to commit to losing weight; they might just want to get around to it .. someday.  Chapter 3 stresses on the fact that as a professional, you should make it crystal clear when saying yes that you really do mean it and are going to commit to it.  Being able to say yes I will get something done as a professional and actually get it done is huge.  I have never really put too much thought into everyday conversations of people saying “yes” but not meaning.  But now that I think about it, there is so many times where someone says “yes”, but I just know that they don’t mean it so I don’t take it seriously.  In the workplace, that is not the professional thing to do and now I am aware of that.

Chapter 4 took a turn and was different then the last 2 chapters.  The difference with this chapter was that it was about your personal attitude towards coding, not how you communicate with others.  Although it is very important to have good communication skills as a developer; it is also very important to write good code.  The author took this chapter to discuss his personal things he has discovered that make his code a lot worse in the past.  A few of the tips he gave are:

1. Don’t code if you are tired or distracted
2. Don’t code at 3 AM
3. Don’t code when you’re anxious
4. Don’t code when you’re “In the Zone”
5. Don’t code when listening to music

I am not going to sit here and list everything he said in the chapter, but I will say I don’t agree with some of his points at all while others I completely agree with.  For one, I have coded some of my best work when listening to music.  It’s interesting how music can help some people focus, while may distract others.  A tip I originally didn’t agree with at all was “Don’t code when you’re ‘In the Zone’”.  When I’m in the zone, there is no stopping me.  I love being in the zone and feel very productive when I am.  However, he did have a point that you may just be working at rapid speeds but not producing that good of work.  When you’re in the zone and writing a bunch of code, that is usually the code you will always have to revisit lateron and he’s 100% right about that.  It was interesting to me to recognize that being “in the zone” may not always be such a good thing. Finally one tip that stuck out to me that I can personally relate to is finding solutions in the car on the way home.  This has happened to me more then once where I left the office with no answer and on the way home, the solution just coming to me.  Something about taking your mind off of the problem and focusing on something else can lead to answers.  In the chapter, he calls this “disengagement” that may allow your mind to hunt for solutions in a different and more creative way.

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