Monthly Archives: January 2017

The Clean Coder Chapters 3 and 4

The Clean Coder Chapters 3 & 4
Chapter 3:
I had favorable things to say about the first two chapters
because they kind of reminded me that no matter where you work or shall I say I
have worked, a lot of it rings true but it is also to me just common sense. I
mean saying no and saying yes? I feel like a bit too much is dedicated to this
and it gets old real fast and I want to skip on but I pushed through chapter 3
and well once again I have to say it is really to me a lot of common sense
things. I guess I shouldn’t say common sense, but for me I learned a lot of
this by trial and error and promising things to people that I knew I couldn’t
get done but just wanted to please so and so and felt that I would just deal
with the blow back later. You can only do that sort of thing so many times (for
me once or twice was enough) before you catch on and realize not to promise
things that you can’t deliver and to commit to things that you’ll do when you
say you will. I guess the book does a decent job at laying out situations and
the outcomes so hopefully people won’t make the same mistakes that Bob made. I
feel though that I have lived through all of the scenarios in some way or
another so I guess I got a chuckle out of it. He says that the language of
commitment can sound scary and it can help solve a lot of the communications
problems facing coders. He is absolutely right but it definitely takes time to
learn how to do it and be taken serious about it. You have to build trust and
being straight about things is the best way to do it.
Chapter 4:

I feel that this chapter is also about experience and a bit
of sense. This is all life stuff and applies to any form of work in my opinion.
He talks about preparedness and how coding is intellectually challenging and
how if you aren’t prepared for it your work will suffer. I find that this seems
like my dad is preaching at me when I was 16. I mean of course your work is
going to suffer when you can’t concentrate or when you are tired. The worst
code written at 3am, I have been there and don’t do that anymore because I have
learned the hard way and the good ole flow zone where you think you are
actually doing an awesome job reminds of the people who say they do their best
work high or drunk. Sorry it just doesn’t work like that as like he said, yes
you may get a lot done, but what did you miss? I am sorry but I guess I am kind
of disappointed with the first few chapters. I was good with the first two at
first but the next two to me seem to be more of the same lessons just in a
different context and I can’t write anymore about them. It does however seem
like the rest of the book will be decent to me. I thought his other book (
Clean Code) was good so I figured that this would be more of the same and I
hope the rest is.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

The Clean Coder Chapters 3 and 4

The Clean Coder Chapters 3 & 4
Chapter 3:
I had favorable things to say about the first two chapters
because they kind of reminded me that no matter where you work or shall I say I
have worked, a lot of it rings true but it is also to me just common sense. I
mean saying no and saying yes? I feel like a bit too much is dedicated to this
and it gets old real fast and I want to skip on but I pushed through chapter 3
and well once again I have to say it is really to me a lot of common sense
things. I guess I shouldn’t say common sense, but for me I learned a lot of
this by trial and error and promising things to people that I knew I couldn’t
get done but just wanted to please so and so and felt that I would just deal
with the blow back later. You can only do that sort of thing so many times (for
me once or twice was enough) before you catch on and realize not to promise
things that you can’t deliver and to commit to things that you’ll do when you
say you will. I guess the book does a decent job at laying out situations and
the outcomes so hopefully people won’t make the same mistakes that Bob made. I
feel though that I have lived through all of the scenarios in some way or
another so I guess I got a chuckle out of it. He says that the language of
commitment can sound scary and it can help solve a lot of the communications
problems facing coders. He is absolutely right but it definitely takes time to
learn how to do it and be taken serious about it. You have to build trust and
being straight about things is the best way to do it.
Chapter 4:

I feel that this chapter is also about experience and a bit
of sense. This is all life stuff and applies to any form of work in my opinion.
He talks about preparedness and how coding is intellectually challenging and
how if you aren’t prepared for it your work will suffer. I find that this seems
like my dad is preaching at me when I was 16. I mean of course your work is
going to suffer when you can’t concentrate or when you are tired. The worst
code written at 3am, I have been there and don’t do that anymore because I have
learned the hard way and the good ole flow zone where you think you are
actually doing an awesome job reminds of the people who say they do their best
work high or drunk. Sorry it just doesn’t work like that as like he said, yes
you may get a lot done, but what did you miss? I am sorry but I guess I am kind
of disappointed with the first few chapters. I was good with the first two at
first but the next two to me seem to be more of the same lessons just in a
different context and I can’t write anymore about them. It does however seem
like the rest of the book will be decent to me. I thought his other book (
Clean Code) was good so I figured that this would be more of the same and I
hope the rest is.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

The Clean Coder Chapters 3 and 4

The Clean Coder Chapters 3 & 4
Chapter 3:
I had favorable things to say about the first two chapters because they kind of reminded me that no matter where you work or shall I say I have worked, a lot of it rings true but it is also to me just common sense. I mean saying no and saying yes? I feel like a bit too much is dedicated to this and it gets old real fast and I want to skip on but I pushed through chapter 3 and well once again I have to say it is really to me a lot of common sense things. I guess I shouldn’t say common sense, but for me I learned a lot of this by trial and error and promising things to people that I knew I couldn’t get done but just wanted to please so and so and felt that I would just deal with the blow back later. You can only do that sort of thing so many times (for me once or twice was enough) before you catch on and realize not to promise things that you can’t deliver and to commit to things that you’ll do when you say you will. I guess the book does a decent job at laying out situations and the outcomes so hopefully people won’t make the same mistakes that Bob made. I feel though that I have lived through all of the scenarios in some way or another so I guess I got a chuckle out of it. He says that the language of commitment can sound scary and it can help solve a lot of the communications problems facing coders. He is absolutely right but it definitely takes time to learn how to do it and be taken serious about it. You have to build trust and being straight about things is the best way to do it.
Chapter 4:

I feel that this chapter is also about experience and a bit of sense. This is all life stuff and applies to any form of work in my opinion. He talks about preparedness and how coding is intellectually challenging and how if you aren’t prepared for it your work will suffer. I find that this seems like my dad is preaching at me when I was 16. I mean of course your work is going to suffer when you can’t concentrate or when you are tired. The worst code written at 3am, I have been there and don’t do that anymore because I have learned the hard way and the good ole flow zone where you think you are actually doing an awesome job reminds of the people who say they do their best work high or drunk. Sorry it just doesn’t work like that as like he said, yes you may get a lot done, but what did you miss? I am sorry but I guess I am kind of disappointed with the first few chapters. I was good with the first two at first but the next two to me seem to be more of the same lessons just in a different context and I can’t write anymore about them. It does however seem like the rest of the book will be decent to me. I thought his other book ( Clean Code) was good so I figured that this would be more of the same and I hope the rest is.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Week 2: The Clean Coder

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.

Week 2: Reflections on Learning & Work Products

This week my main accomplishment was setting up my work environment both on Web Storm and Trello.  My whole group made Trello accounts, and we set up our board so we can start getting the hang of how we will be working together this semester.  Trello helps us keep track of what’s done, what’s in process, and who’s doing what.  I personally really enjoy using Trello, because it’s an easy and visual way to stay on track with my group.  This week made me realize that working to complete this project is definitely different then the workplace because we don’t have full contact to each other at all times.  At work it’s everyones full time job to get the project done.  However, here at school, not everyone in the group is always accessible.

The most current thing I have been working on is completing the Angular 2 (Tour of Heroes) tutorial using Web Storm as my IDE.  This tutorial is a fun way to begin learning Angular 2.  Just beginning this tutorial with some of my group members in class taught me that working together and asking questions when you have an issue is very important to get things done efficiently.  Everyone in my group was working together in class to make sure we all had a working environment which was very helpful.  Next week I am going to be sure to post my “daily” scrum on Monday, Wednesday, and Friday because I wasn’t aware that we had to do that last week.  I think frequent updates are a great idea and will be useful when we are working on the actual task.  It will be good to see where everyone is at on daily basis.  Overall, I feel accomplished this week and am anxious to start learning Angular 2 more in depth this upcoming week.

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.

The Clean Coder chapter 3&4.

In our last chapter we focused on the importance of saying No as well as when and how to say no. Well, this chapter shows that knowing how to say yes in certain situation can also solidify our title as professionals. Saying “yes” is a verbal commitment and Roy Osherove splits it into three parts:  saying you’ll do it, meaning  it, and actually do it. The first part is easy for an individual to say. Saying you will do a certain task doesn’t not always signify that you mean it and it doesn’t always lead to completion. So how do we know who is actually committed? Well, we can confirm whether an individual is actually committed by  identifying their choice of words. Using phrase like “We need to get this done”, “I hope to get this done”, or “I Wish i had time for that” are all phrases that shows signs of non-commitment.  A person who is actually committed and takes responsibility for things would avoid using words like need, should, and wish. Instead, they will start their sentences with “I will” to express their commitment. Thus, putting them in a situation where they are obligated to getting the task done.

When saying “yes” we must consider all the possibilities such as deadlines, estimations, and our well-being. As a professional we can’t just simply say “yes” when we have to sacrifice discipline. Breaking discipline will only make things harder. The book gave an example of an employee named peter who was in a situation where he was considering sacrificing discipline to meet a deadline. It states that:

 as a professional he has a responsibility to maintain certain standards. His code needs to be tested, and needs to have tests. His code needs to be clean. And he has to be sure he hasn’t broken anything else in the system.

We have responsibilities as developers to make sure under any circumstance, that our code is near perfection before release.

This leads to chapter 4 of the book which talks about coding and rules that can be followed. I can agree that working working when you are tired will not lead to a clean and applicable code. The best time to code is when your head is clear, when you’re well-rested, and in a decent mood. I listen to music all the time while coding. It was a surprise to see that the book mentions that it is actually not productive to listen to music while coding. I find it funny that the author accident wrote the lyrics of a song in the comments of his code. Even though that hasn’t happen to me, I’m sure it can happen in the future.

 

 

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

The Clean Coder: Chapters 3 & 4

The 3rd chapter “Saying Yes” from the book “The Clean Coder” by author Robert C. Martin, revolves around the language of commitment. Martin introduces one of his colleagues, Roy Osherove in order to give a better judgement and analysis of the words Martin said during his workdays “I’m committed . . . I guess.” Osherove thoughts clearly indicates that the statement as a bad one. He talks about the three main points of commitment.

1. You say you’ll do it.

2. You mean it.

3. You actually do it.

For most of the times, till now when I, myself commit to do a certain task I just thought to do it at some point in time. But, now I came to realize that I was just following step 1 and step 2 at most. From now onwards, I will be very sure on my own commitment that I actually Say, Mean, and Do.

Furthermore, Osherove clearly defines signs of non-commitment such as the words: Need\should, Hope\wish. Luckily, I wasn’t using those for making my commitments, so I considered to be on the safe side. Although making a dialect commitment may sound somewhat unnerving, it can help take care of a significant number of the correspondence issues. On the off chance that you can’t make your commitment, the most critical thing is to raise a warning as quickly as time permits to whoever you focused on.

Moreover, chapter 3 has more to offer on learning how to say “yes”. Professionals are not required to state yes to everything that is asked of them. However, they ought to strive to discover innovative approaches to make “yes” conceivable. After reading this portion of the chapter, I will bear the responsibility to maintain certain standards. I learned where to draw the line of professionalism with regard to family (hopefully in future) and my working time. I should be clear about the work-load, overtime, and ultimately the cost of it.

Chapter 4: “Coding” discusses the act of coding, and the context that surrounds that act. The main theme of this chapter is that, “Dedication and professionalism are more about discipline than hours. Make sure that your sleep, health, and lifestyle are tuned so that you can put in eight good hours per day.” Author Martin has different way of coding, so do I. He believes his creative output are usually generated with driving home and while taking the shower. Meanwhile, he doesn’t mix his music with coding. Writing about myself, I found myself productive when I am more close to nature and its surrounding.

With that being said, coding does requires many competing factors at once. First and foremost is that the code must work, and must fit well into the existing system. It also must be easy to read by other programmers. Some of the times I found myself not writing the complete code and just leaving in the middle just because it’s too hard. For this, from now I will seeking for a help to get my project move forward. Furthermore, a simple external force interrupts my coding time. Next time, as the author suggests pairing can be very helpful as a way to deal with interruptions, I will find a partner to reconstruct the mental context I usually have before interruption.

From the blog CS@Worcester – Software Dev Capstone by osworup007 and used with permission of the author. All other rights reserved by the author.

Week2: Signing up for different accounts

Second week on the final project went very quickly. We had a snow day last Tuesday and only one class Thursday for the week. On Thursday, we ran our first official project sprint. Our group succeeded in achieving every task except Complete Angular Tour of Heroes. We signed up for Trello, OpenMRS and installed WebStorm IDE on our individual laptops. Although, we installed everything on our separated machines, but we worked together as a team to make sure every team member got everything working correctly. We also post an introduction to OpenMRS community from our individual accounts. Tan created another channel for daily scrum standups.

From week2, I learned that working together as a group can be very efficient because if a member is stuck or doesn’t know something there is a good chance that another group member can fix that issue. So, you do not spend extra time on figuring out. I feel like we are lacking communication between our group members outside class, but I think it is because we are not that deep into the project. I also feel comfortable that through the daily scrum channel on Slack we can stay up-to-date in terms of where everybody is and where we need improvements.

From the blog Software Learning and Development – Site Title by hhussainsite and used with permission of the author. All other rights reserved by the author.

Fundamentals of Software Version Control

NOTES FROM Fundamentals of Software Version Control Michael Lehman 1. Overview of Software Version Control Overview of software version control Version Control is the process of keeping track of your creative output as it evolves over the course of a … Continue reading →

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

Clean Code Chapter 3-4

In chapter 3 of clean code, it was interesting to read his thought on switch statements. As someone who uses a lot of switch statement, it does look very ugly when it is inside your larger code class. It was a common mistake for me in the beginning of coding to have these huge switch statements inside the code. When things need to be changed, I would have find the switch statement inside my code and change it. The solution in the book is to use an abstract factory to hide the switch. However, even then it says the statement are only tolerated if they appear once and are used to create polymorphic objects.

In chapter 4 on comments, the book states that comment does not make up for bad codes. I chuckled when reading that as it was something that I’m guilty of doing.  There are codes I written where I comment that the code is a mess here and I will fix it later. Of course, I rarely ever go back and change it. It is a hard habit to fix especially since you know the code works, although it looks ugly and maybe a bit inefficient. Cleaning it up will benefit you and people who will read the code in the future.  The more you put it off, the less likely you will go back and change it. Commenting with a “will clean up later” just further exacerbate that problem. It is something I should work on in the future.

From the blog CS@Worcester – Site Title by nealw5 and used with permission of the author. All other rights reserved by the author.