Monthly Archives: March 2017

Chapters 1 and 2 Software Craftsman

Chapter 1

One of the first things I noticed in this chapter and it
made me cringe is how people seemed to have thought back in the early 90’s in
how they measured seniority by how cryptic your code was. I am sure it wasn’t
everywhere but I remember people back then talking like that. How anyone ever
thought that was cool or what not is another issue for another time I guess but
wow memories come flooding back, not because I was a coder in the early 90’s
but I knew some and hung around them and I remember hearing stuff like this. I
laughed a few times as well in this chapter, especially when he was talking
about adding abstractions and design patterns all over the place and how today
it would be called overengineering and stupidity. It is amazing just how far we
have come I guess. He hits the nail on the head though in talking about choosing
your passion for work and what makes you happy. I see it in a lot of the young
folks today talking about oh how much money this and that, but never hear them
talking about finding something they would be happy doing. I never thought much
like that, of course I would like to make a lot of money, but if I am not happy
making it what’s the point?
I like his take on seniority as well and how it is transient
and relative. I think too many people in general judge seniority in numbers of
years and not quality of product. I have been many a place and seen people with
2 years of experience blow someone away that had 10. It is true though however
that there really is no senior or junior developers unless you reference what
senior or junior is as pertaining to a certain language I guess. It is
interesting to see how things evolve over the years in what our
responsibilities are or will be once employed. We need to be a sort of jack of
all trades in the sense that we will be doing many roles as we evolve up the
ladder. I am looking forward to see what the rest of the book has to offer.
Chapter 2

After reading this chapter I look at agile a new way. I
never gave much thought to the name until now. The definition of agile is “able
to move quickly and easily” hence the methodology being quick and short
feedback loops. I think that it is awesome that these guys got together and
basically changed the way we think and do. Doing things in short iterations
like this makes for smooth flow in my opinion and less of a chance of failing.
I love the first line of the manifesto, “Individuals and interactions over
process and tools”, it is quite the revelation to me and how I like to think.
It makes so much sense I wonder why it wasn’t done a long time ago. I mean if
everyone is involved and working together and “communicating” it is common
sense that thing should go smoother. Keeping people out of the loop on projects
makes for a mess that sometimes can’t be cleaned up. He is right in saying though
it doesn’t work unless there is a full transformation with everyone on board. I
mean that is like anything though in my opinion, you can’t half ass stuff or
you end up where you started and doing it all over again. It takes work, but I think
once the work is put in and results are seen it is a no brainer I would think.
The embracing of software craftsmanship is needed and I am beginning to like
that term. We are craftsmen and like craftsmen we should strive to become
better each day and utilizing the tools we can accomplish this.

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

Chapters 1 and 2 Software Craftsman

Chapter 1

One of the first things I noticed in this chapter and it
made me cringe is how people seemed to have thought back in the early 90’s in
how they measured seniority by how cryptic your code was. I am sure it wasn’t
everywhere but I remember people back then talking like that. How anyone ever
thought that was cool or what not is another issue for another time I guess but
wow memories come flooding back, not because I was a coder in the early 90’s
but I knew some and hung around them and I remember hearing stuff like this. I
laughed a few times as well in this chapter, especially when he was talking
about adding abstractions and design patterns all over the place and how today
it would be called overengineering and stupidity. It is amazing just how far we
have come I guess. He hits the nail on the head though in talking about choosing
your passion for work and what makes you happy. I see it in a lot of the young
folks today talking about oh how much money this and that, but never hear them
talking about finding something they would be happy doing. I never thought much
like that, of course I would like to make a lot of money, but if I am not happy
making it what’s the point?
I like his take on seniority as well and how it is transient
and relative. I think too many people in general judge seniority in numbers of
years and not quality of product. I have been many a place and seen people with
2 years of experience blow someone away that had 10. It is true though however
that there really is no senior or junior developers unless you reference what
senior or junior is as pertaining to a certain language I guess. It is
interesting to see how things evolve over the years in what our
responsibilities are or will be once employed. We need to be a sort of jack of
all trades in the sense that we will be doing many roles as we evolve up the
ladder. I am looking forward to see what the rest of the book has to offer.
Chapter 2

After reading this chapter I look at agile a new way. I
never gave much thought to the name until now. The definition of agile is “able
to move quickly and easily” hence the methodology being quick and short
feedback loops. I think that it is awesome that these guys got together and
basically changed the way we think and do. Doing things in short iterations
like this makes for smooth flow in my opinion and less of a chance of failing.
I love the first line of the manifesto, “Individuals and interactions over
process and tools”, it is quite the revelation to me and how I like to think.
It makes so much sense I wonder why it wasn’t done a long time ago. I mean if
everyone is involved and working together and “communicating” it is common
sense that thing should go smoother. Keeping people out of the loop on projects
makes for a mess that sometimes can’t be cleaned up. He is right in saying though
it doesn’t work unless there is a full transformation with everyone on board. I
mean that is like anything though in my opinion, you can’t half ass stuff or
you end up where you started and doing it all over again. It takes work, but I think
once the work is put in and results are seen it is a no brainer I would think.
The embracing of software craftsmanship is needed and I am beginning to like
that term. We are craftsmen and like craftsmen we should strive to become
better each day and utilizing the tools we can accomplish this.

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

Chapters 1 and 2 Software Craftsman

Chapter 1

One of the first things I noticed in this chapter and it
made me cringe is how people seemed to have thought back in the early 90’s in
how they measured seniority by how cryptic your code was. I am sure it wasn’t
everywhere but I remember people back then talking like that. How anyone ever
thought that was cool or what not is another issue for another time I guess but
wow memories come flooding back, not because I was a coder in the early 90’s
but I knew some and hung around them and I remember hearing stuff like this. I
laughed a few times as well in this chapter, especially when he was talking
about adding abstractions and design patterns all over the place and how today
it would be called overengineering and stupidity. It is amazing just how far we
have come I guess. He hits the nail on the head though in talking about choosing
your passion for work and what makes you happy. I see it in a lot of the young
folks today talking about oh how much money this and that, but never hear them
talking about finding something they would be happy doing. I never thought much
like that, of course I would like to make a lot of money, but if I am not happy
making it what’s the point?
I like his take on seniority as well and how it is transient
and relative. I think too many people in general judge seniority in numbers of
years and not quality of product. I have been many a place and seen people with
2 years of experience blow someone away that had 10. It is true though however
that there really is no senior or junior developers unless you reference what
senior or junior is as pertaining to a certain language I guess. It is
interesting to see how things evolve over the years in what our
responsibilities are or will be once employed. We need to be a sort of jack of
all trades in the sense that we will be doing many roles as we evolve up the
ladder. I am looking forward to see what the rest of the book has to offer.
Chapter 2

After reading this chapter I look at agile a new way. I
never gave much thought to the name until now. The definition of agile is “able
to move quickly and easily” hence the methodology being quick and short
feedback loops. I think that it is awesome that these guys got together and
basically changed the way we think and do. Doing things in short iterations
like this makes for smooth flow in my opinion and less of a chance of failing.
I love the first line of the manifesto, “Individuals and interactions over
process and tools”, it is quite the revelation to me and how I like to think.
It makes so much sense I wonder why it wasn’t done a long time ago. I mean if
everyone is involved and working together and “communicating” it is common
sense that thing should go smoother. Keeping people out of the loop on projects
makes for a mess that sometimes can’t be cleaned up. He is right in saying though
it doesn’t work unless there is a full transformation with everyone on board. I
mean that is like anything though in my opinion, you can’t half ass stuff or
you end up where you started and doing it all over again. It takes work, but I think
once the work is put in and results are seen it is a no brainer I would think.
The embracing of software craftsmanship is needed and I am beginning to like
that term. We are craftsmen and like craftsmen we should strive to become
better each day and utilizing the tools we can accomplish this.

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

Chapters 1 and 2 Software Craftsman

Chapter 1

One of the first things I noticed in this chapter and it made me cringe is how people seemed to have thought back in the early 90’s in how they measured seniority by how cryptic your code was. I am sure it wasn’t everywhere but I remember people back then talking like that. How anyone ever thought that was cool or what not is another issue for another time I guess but wow memories come flooding back, not because I was a coder in the early 90’s but I knew some and hung around them and I remember hearing stuff like this. I laughed a few times as well in this chapter, especially when he was talking about adding abstractions and design patterns all over the place and how today it would be called overengineering and stupidity. It is amazing just how far we have come I guess. He hits the nail on the head though in talking about choosing your passion for work and what makes you happy. I see it in a lot of the young folks today talking about oh how much money this and that, but never hear them talking about finding something they would be happy doing. I never thought much like that, of course I would like to make a lot of money, but if I am not happy making it what’s the point?
I like his take on seniority as well and how it is transient and relative. I think too many people in general judge seniority in numbers of years and not quality of product. I have been many a place and seen people with 2 years of experience blow someone away that had 10. It is true though however that there really is no senior or junior developers unless you reference what senior or junior is as pertaining to a certain language I guess. It is interesting to see how things evolve over the years in what our responsibilities are or will be once employed. We need to be a sort of jack of all trades in the sense that we will be doing many roles as we evolve up the ladder. I am looking forward to see what the rest of the book has to offer.
Chapter 2

After reading this chapter I look at agile a new way. I never gave much thought to the name until now. The definition of agile is “able to move quickly and easily” hence the methodology being quick and short feedback loops. I think that it is awesome that these guys got together and basically changed the way we think and do. Doing things in short iterations like this makes for smooth flow in my opinion and less of a chance of failing. I love the first line of the manifesto, “Individuals and interactions over process and tools”, it is quite the revelation to me and how I like to think. It makes so much sense I wonder why it wasn’t done a long time ago. I mean if everyone is involved and working together and “communicating” it is common sense that thing should go smoother. Keeping people out of the loop on projects makes for a mess that sometimes can’t be cleaned up. He is right in saying though it doesn’t work unless there is a full transformation with everyone on board. I mean that is like anything though in my opinion, you can’t half ass stuff or you end up where you started and doing it all over again. It takes work, but I think once the work is put in and results are seen it is a no brainer I would think. The embracing of software craftsmanship is needed and I am beginning to like that term. We are craftsmen and like craftsmen we should strive to become better each day and utilizing the tools we can accomplish this.

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

Chapters 1 and 2 Software Craftsman

Chapter 1

One of the first things I noticed in this chapter and it
made me cringe is how people seemed to have thought back in the early 90’s in
how they measured seniority by how cryptic your code was. I am sure it wasn’t
everywhere but I remember people back then talking like that. How anyone ever
thought that was cool or what not is another issue for another time I guess but
wow memories come flooding back, not because I was a coder in the early 90’s
but I knew some and hung around them and I remember hearing stuff like this. I
laughed a few times as well in this chapter, especially when he was talking
about adding abstractions and design patterns all over the place and how today
it would be called overengineering and stupidity. It is amazing just how far we
have come I guess. He hits the nail on the head though in talking about choosing
your passion for work and what makes you happy. I see it in a lot of the young
folks today talking about oh how much money this and that, but never hear them
talking about finding something they would be happy doing. I never thought much
like that, of course I would like to make a lot of money, but if I am not happy
making it what’s the point?
I like his take on seniority as well and how it is transient
and relative. I think too many people in general judge seniority in numbers of
years and not quality of product. I have been many a place and seen people with
2 years of experience blow someone away that had 10. It is true though however
that there really is no senior or junior developers unless you reference what
senior or junior is as pertaining to a certain language I guess. It is
interesting to see how things evolve over the years in what our
responsibilities are or will be once employed. We need to be a sort of jack of
all trades in the sense that we will be doing many roles as we evolve up the
ladder. I am looking forward to see what the rest of the book has to offer.
Chapter 2

After reading this chapter I look at agile a new way. I
never gave much thought to the name until now. The definition of agile is “able
to move quickly and easily” hence the methodology being quick and short
feedback loops. I think that it is awesome that these guys got together and
basically changed the way we think and do. Doing things in short iterations
like this makes for smooth flow in my opinion and less of a chance of failing.
I love the first line of the manifesto, “Individuals and interactions over
process and tools”, it is quite the revelation to me and how I like to think.
It makes so much sense I wonder why it wasn’t done a long time ago. I mean if
everyone is involved and working together and “communicating” it is common
sense that thing should go smoother. Keeping people out of the loop on projects
makes for a mess that sometimes can’t be cleaned up. He is right in saying though
it doesn’t work unless there is a full transformation with everyone on board. I
mean that is like anything though in my opinion, you can’t half ass stuff or
you end up where you started and doing it all over again. It takes work, but I think
once the work is put in and results are seen it is a no brainer I would think.
The embracing of software craftsmanship is needed and I am beginning to like
that term. We are craftsmen and like craftsmen we should strive to become
better each day and utilizing the tools we can accomplish this.

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

Chapters 1 and 2 Software Craftsman

Chapter 1

One of the first things I noticed in this chapter and it
made me cringe is how people seemed to have thought back in the early 90’s in
how they measured seniority by how cryptic your code was. I am sure it wasn’t
everywhere but I remember people back then talking like that. How anyone ever
thought that was cool or what not is another issue for another time I guess but
wow memories come flooding back, not because I was a coder in the early 90’s
but I knew some and hung around them and I remember hearing stuff like this. I
laughed a few times as well in this chapter, especially when he was talking
about adding abstractions and design patterns all over the place and how today
it would be called overengineering and stupidity. It is amazing just how far we
have come I guess. He hits the nail on the head though in talking about choosing
your passion for work and what makes you happy. I see it in a lot of the young
folks today talking about oh how much money this and that, but never hear them
talking about finding something they would be happy doing. I never thought much
like that, of course I would like to make a lot of money, but if I am not happy
making it what’s the point?
I like his take on seniority as well and how it is transient
and relative. I think too many people in general judge seniority in numbers of
years and not quality of product. I have been many a place and seen people with
2 years of experience blow someone away that had 10. It is true though however
that there really is no senior or junior developers unless you reference what
senior or junior is as pertaining to a certain language I guess. It is
interesting to see how things evolve over the years in what our
responsibilities are or will be once employed. We need to be a sort of jack of
all trades in the sense that we will be doing many roles as we evolve up the
ladder. I am looking forward to see what the rest of the book has to offer.
Chapter 2

After reading this chapter I look at agile a new way. I
never gave much thought to the name until now. The definition of agile is “able
to move quickly and easily” hence the methodology being quick and short
feedback loops. I think that it is awesome that these guys got together and
basically changed the way we think and do. Doing things in short iterations
like this makes for smooth flow in my opinion and less of a chance of failing.
I love the first line of the manifesto, “Individuals and interactions over
process and tools”, it is quite the revelation to me and how I like to think.
It makes so much sense I wonder why it wasn’t done a long time ago. I mean if
everyone is involved and working together and “communicating” it is common
sense that thing should go smoother. Keeping people out of the loop on projects
makes for a mess that sometimes can’t be cleaned up. He is right in saying though
it doesn’t work unless there is a full transformation with everyone on board. I
mean that is like anything though in my opinion, you can’t half ass stuff or
you end up where you started and doing it all over again. It takes work, but I think
once the work is put in and results are seen it is a no brainer I would think.
The embracing of software craftsmanship is needed and I am beginning to like
that term. We are craftsmen and like craftsmen we should strive to become
better each day and utilizing the tools we can accomplish this.

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

Chapters 1 and 2 Software Craftsman

Chapter 1

One of the first things I noticed in this chapter and it
made me cringe is how people seemed to have thought back in the early 90’s in
how they measured seniority by how cryptic your code was. I am sure it wasn’t
everywhere but I remember people back then talking like that. How anyone ever
thought that was cool or what not is another issue for another time I guess but
wow memories come flooding back, not because I was a coder in the early 90’s
but I knew some and hung around them and I remember hearing stuff like this. I
laughed a few times as well in this chapter, especially when he was talking
about adding abstractions and design patterns all over the place and how today
it would be called overengineering and stupidity. It is amazing just how far we
have come I guess. He hits the nail on the head though in talking about choosing
your passion for work and what makes you happy. I see it in a lot of the young
folks today talking about oh how much money this and that, but never hear them
talking about finding something they would be happy doing. I never thought much
like that, of course I would like to make a lot of money, but if I am not happy
making it what’s the point?
I like his take on seniority as well and how it is transient
and relative. I think too many people in general judge seniority in numbers of
years and not quality of product. I have been many a place and seen people with
2 years of experience blow someone away that had 10. It is true though however
that there really is no senior or junior developers unless you reference what
senior or junior is as pertaining to a certain language I guess. It is
interesting to see how things evolve over the years in what our
responsibilities are or will be once employed. We need to be a sort of jack of
all trades in the sense that we will be doing many roles as we evolve up the
ladder. I am looking forward to see what the rest of the book has to offer.
Chapter 2

After reading this chapter I look at agile a new way. I
never gave much thought to the name until now. The definition of agile is “able
to move quickly and easily” hence the methodology being quick and short
feedback loops. I think that it is awesome that these guys got together and
basically changed the way we think and do. Doing things in short iterations
like this makes for smooth flow in my opinion and less of a chance of failing.
I love the first line of the manifesto, “Individuals and interactions over
process and tools”, it is quite the revelation to me and how I like to think.
It makes so much sense I wonder why it wasn’t done a long time ago. I mean if
everyone is involved and working together and “communicating” it is common
sense that thing should go smoother. Keeping people out of the loop on projects
makes for a mess that sometimes can’t be cleaned up. He is right in saying though
it doesn’t work unless there is a full transformation with everyone on board. I
mean that is like anything though in my opinion, you can’t half ass stuff or
you end up where you started and doing it all over again. It takes work, but I think
once the work is put in and results are seen it is a no brainer I would think.
The embracing of software craftsmanship is needed and I am beginning to like
that term. We are craftsmen and like craftsmen we should strive to become
better each day and utilizing the tools we can accomplish this.

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

Chapters 1 and 2 Software Craftsman

Chapter 1

One of the first things I noticed in this chapter and it
made me cringe is how people seemed to have thought back in the early 90’s in
how they measured seniority by how cryptic your code was. I am sure it wasn’t
everywhere but I remember people back then talking like that. How anyone ever
thought that was cool or what not is another issue for another time I guess but
wow memories come flooding back, not because I was a coder in the early 90’s
but I knew some and hung around them and I remember hearing stuff like this. I
laughed a few times as well in this chapter, especially when he was talking
about adding abstractions and design patterns all over the place and how today
it would be called overengineering and stupidity. It is amazing just how far we
have come I guess. He hits the nail on the head though in talking about choosing
your passion for work and what makes you happy. I see it in a lot of the young
folks today talking about oh how much money this and that, but never hear them
talking about finding something they would be happy doing. I never thought much
like that, of course I would like to make a lot of money, but if I am not happy
making it what’s the point?
I like his take on seniority as well and how it is transient
and relative. I think too many people in general judge seniority in numbers of
years and not quality of product. I have been many a place and seen people with
2 years of experience blow someone away that had 10. It is true though however
that there really is no senior or junior developers unless you reference what
senior or junior is as pertaining to a certain language I guess. It is
interesting to see how things evolve over the years in what our
responsibilities are or will be once employed. We need to be a sort of jack of
all trades in the sense that we will be doing many roles as we evolve up the
ladder. I am looking forward to see what the rest of the book has to offer.
Chapter 2

After reading this chapter I look at agile a new way. I
never gave much thought to the name until now. The definition of agile is “able
to move quickly and easily” hence the methodology being quick and short
feedback loops. I think that it is awesome that these guys got together and
basically changed the way we think and do. Doing things in short iterations
like this makes for smooth flow in my opinion and less of a chance of failing.
I love the first line of the manifesto, “Individuals and interactions over
process and tools”, it is quite the revelation to me and how I like to think.
It makes so much sense I wonder why it wasn’t done a long time ago. I mean if
everyone is involved and working together and “communicating” it is common
sense that thing should go smoother. Keeping people out of the loop on projects
makes for a mess that sometimes can’t be cleaned up. He is right in saying though
it doesn’t work unless there is a full transformation with everyone on board. I
mean that is like anything though in my opinion, you can’t half ass stuff or
you end up where you started and doing it all over again. It takes work, but I think
once the work is put in and results are seen it is a no brainer I would think.
The embracing of software craftsmanship is needed and I am beginning to like
that term. We are craftsmen and like craftsmen we should strive to become
better each day and utilizing the tools we can accomplish this.

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

Chapters 1 and 2 Software Craftsman

Chapter 1

One of the first things I noticed in this chapter and it
made me cringe is how people seemed to have thought back in the early 90’s in
how they measured seniority by how cryptic your code was. I am sure it wasn’t
everywhere but I remember people back then talking like that. How anyone ever
thought that was cool or what not is another issue for another time I guess but
wow memories come flooding back, not because I was a coder in the early 90’s
but I knew some and hung around them and I remember hearing stuff like this. I
laughed a few times as well in this chapter, especially when he was talking
about adding abstractions and design patterns all over the place and how today
it would be called overengineering and stupidity. It is amazing just how far we
have come I guess. He hits the nail on the head though in talking about choosing
your passion for work and what makes you happy. I see it in a lot of the young
folks today talking about oh how much money this and that, but never hear them
talking about finding something they would be happy doing. I never thought much
like that, of course I would like to make a lot of money, but if I am not happy
making it what’s the point?
I like his take on seniority as well and how it is transient
and relative. I think too many people in general judge seniority in numbers of
years and not quality of product. I have been many a place and seen people with
2 years of experience blow someone away that had 10. It is true though however
that there really is no senior or junior developers unless you reference what
senior or junior is as pertaining to a certain language I guess. It is
interesting to see how things evolve over the years in what our
responsibilities are or will be once employed. We need to be a sort of jack of
all trades in the sense that we will be doing many roles as we evolve up the
ladder. I am looking forward to see what the rest of the book has to offer.
Chapter 2

After reading this chapter I look at agile a new way. I
never gave much thought to the name until now. The definition of agile is “able
to move quickly and easily” hence the methodology being quick and short
feedback loops. I think that it is awesome that these guys got together and
basically changed the way we think and do. Doing things in short iterations
like this makes for smooth flow in my opinion and less of a chance of failing.
I love the first line of the manifesto, “Individuals and interactions over
process and tools”, it is quite the revelation to me and how I like to think.
It makes so much sense I wonder why it wasn’t done a long time ago. I mean if
everyone is involved and working together and “communicating” it is common
sense that thing should go smoother. Keeping people out of the loop on projects
makes for a mess that sometimes can’t be cleaned up. He is right in saying though
it doesn’t work unless there is a full transformation with everyone on board. I
mean that is like anything though in my opinion, you can’t half ass stuff or
you end up where you started and doing it all over again. It takes work, but I think
once the work is put in and results are seen it is a no brainer I would think.
The embracing of software craftsmanship is needed and I am beginning to like
that term. We are craftsmen and like craftsmen we should strive to become
better each day and utilizing the tools we can accomplish this.

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

The Software Craftsman: (Chapters 1 & 2)

A huge point that Chapter 1 of The Software Craftsman discusses is what “seniority” is in a company and how it’s measured incorrectly a lot of the time in the workplace.  The chapter states, “There is a huge difference between having 10 years experience, and having 1 year experience repeated 10 times”.  That quote stuck out to me and made me think how true that is.  Just because you have worked somewhere a long time doesn’t mean that you have more knowledge then the person sitting next to you who worked half the time you have at that company.  The other main point this chapter talked about is something that I actually think about all the time. It talked about how developers should be able to keep up with the modern ways of working.  As a developer you need to keep up with the modern tools and equipment.  If you’re doctor was using medicine from 1990, and not upgrading his practices, you would be concerned.  That is how you should think as a software developer!

Chapter 2 discusses what it means to be agile, and how to solve the problems that come along with that with software craftsmanship.  The chapter stresses how you NEED to have a good balance between process-oriented and technical-oriented disciplines and methodologies.  It also talks about how you need to be able to work with your team as a whole.  I agree with this chapter that although being agile can be beenificial, it can also cause a lot of problems.  This is where you need to take your craftsmanship and apply it to help fix those problems.  Becoming more agile in computer science is a “game changer” as the chapter stated.  I now see how being agile in the workplace is very important and can change a lot.  I wish to take this knowledge and hopefully become more agile.

 

 

 

 

 

 

 

 

 

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.