Monthly Archives: January 2017

The Clean Coder Chapters 1 and 2

This week our reading assignment was chapters 1, and 2 in The clean Coder. Just off these two chapters i have learned a lot about what it means to be a professional. I learned that there is a right time to say no, and that being straight up with your employers is better for both parties. Something that really stood out to me was when the manager and the engineer were having a conversation and the engineer went on a rant about “trying” to get something done and what that implies. Saying that you will try to get something done implies that you were not giving 100 percent effort. You can try all you want to do something, you can try to fly, you can try to turn lead into gold, but some things are just plain impossible. It is best to communicate these things to your manager when the proper situation arises.

 

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

The Clean Coder, Chapter 1 & 2

Chapters 1 and 2 in the book title, The Clean Coder by Robert C. Martin talks about professionalism and when to say “no” in workplace. Both chapters were very interesting to me, as a matter of fact, I wish that someone had given me this book to read during my first year of being a computer science major.

There were many great advises and suggestions for what makes and what it means to be a professional? If you want to take credit for some job, then there comes great responsibility with it because that job can either be a success or failure depending on your actions/circumstances. Some of the key topics that struck me the most were when the author talks about: work ethics: my career being my responsibility, get really good and grow at your field with time, work with other people and best way to learn is to teach others. I thought the author was speaking to me directly as to get moving on these ideas and get ready for the real world. One of my personal favorites suggestion was “In a week there are 168 hours. Give your employer 40, and your career another 20. That leaves 108. Another 56 for sleep leaves 52 for everything else.” I am so affected by these sentences that I am thinking about applying it to my life because if you do the math it makes perfect sense. It is manageable and applicable.

Chapter 2 gave me a taste of workplace. It explained that in the workplace we will be working with different people with their own goals and agendas, but we have to make sure that we are crystal clear during our communication with others. Make sure that we take a stand for what we say? and do not mislead or over promise. It is not bad or unprofessional to say “no” to your boss once in a while if you think your boss is being unreasonable and does not understand the scope of what he/she is asking for? I personally feel that it would be very hard to say “no” to a boss who is in the same field as you, but if your boss is from the business world and all he/she is concern with the profit and his/her bonus then I do not feel I would hesitate to say “no” if he/she asks me something unreasonable/impossible.

 

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.

Reflections and Learning Week 1 (1/24/17)

The first week of my capstone was pretty much just preparation for the project. When I walked into the class, people kept telling me they wanted me to be a team leader. The fact that I missed the first day of class due to having my wisdom teeth removed put me in a completely clueless state as I did not know what exactly was going on. I ended up being elected as one of the team leaders with no clue what i was doing, but i ended up noticing people were picking pairs to work with so i guessed it was a recruitment kind of thing. After the processor told me what I had to do, i ended up picking people for me team as well as the other folks who picked people for their team too. From that experience, I learned some bits of being a recruiter.

Afterwards, the professor told us that we are working with OpenMRS which I heard briefly about. After setting up Slack, a chatting system that makes communications easier for development, my team and I did research on the project as well as AMPath. We worked together to organize the project we have to work on and are currently planning to start learning Angular (a programming language) since that is what we will be coding in.

I should have gotten information previously before going to class since i missed it, i would have been more aware if i read all the alerts on blackboard. This could apply to actually working at a company and not knowing whats going on since I did not ask any questions. Let alone, this act could have injured communication with my team if i kept acting that way. As learning in the level 3 course, communication is important while developer software. Even though the course was talking about QA testing, the same principle of communication applies here too. In the end, I’m more interested in seeing how to approach working on features for AMPath, as i have not programmed with a team before. That will be a true learning curve.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

Week 1: The Clean Coder

Week 1 of CS448 I was assigned to read Chapters 1 & 2 of the book, The Clean Coder.  A quick summary and my thoughts on both of the chapters:

Chapter 1 discussed what it means to be a professional and some ways to achieve be one.  A huge point the chapter touched on is that a professional takes responsibilty for his or her mistakes.  An example the chapter gave was, a nonprofessional who allows a bug to slip through to the product delivered to a customer would shrug it off and move on.  A professional on the other hand would be writing a company check for $10,000.  Some of the major points that the chapter gave to developers that stuck out to me were; they should be testing every single line of their code, they should always make sure to test the whole system before shipping it to a customer (not just the features recently fixed), and that they should be keeping up to date with all of the latest stuff.

Chapter 2 discussed how you should say “no” to a manager, boss or even a customer in the workplace.  The chapter went through and gave different scenarios, using dialogue, where someone was asked to have a certain task done by a certain time, which just simply wasn’t possible.  A good tip that the chapter gives is that you should never lie boss just because you cannot get done what he/she wants in time.  You need to be assertive and let them know respectfully that you will need more time, and what you CAN have done by that time.  In one example in this chapter, a woman named Paula is asked by her manager Mike to be done with the work in 6 weeks.  Paula tells him over and over again that the team will need atleast 8 weeks and there is no way they have it done sooner.  After going back and forth a few times, Mike says “OK, Paula, but I bet you guys can work miracles if you try.”  Mike basically wasn’t taking no for an answer.  He went on to promise the customer that they will have the demo in 6 weeks.  That was an example of the wrong thing to do on Mikes part.  You should NEVER make a false promise and tell someone you will have something done for them if you can’t.

My initial thoughts when beginning the reading was that I was a little bit relieved.  This book isn’t your average boring text book, which was I was expecting it to be.  It’s actually a pretty easy and interesting read.  The book engages the reader and explains things in a way that you can relate to.  Chapter 1 was interesting to me because I never really thought of the term “professional” in the context they described it as.  I just thought if you are in the workplace .. you are considered a professional.  However, I learned that this is not the case at all.  There is a lot that goes into be professional, and chapter 1 opened my eyes to that.  Chapter 2 was my favorite of the two.  I personally have had the problem where I didn’t know how to tell my manager I couldn’t get something done in time.  In the past I have just said, “Ok, I will have it done”, then last minute broke the news even though I knew from the start I couldn’t do it.  I will definitely use what this chapter taught me in the future and say no the right way.  Overall, I enjoyed reading this book for week 1!

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, Chapters 1 & 2.

“The Clean Coder: A Code of Conduct for Professional Programmers” is the first book I am reading by the author Robert C. Martin. Going through the pre-requisite introduction portion of the book Martin noticeably states that this particular book is full of catalog of his errors from his 42 years of experience in software engineering field and a set of guidelines to avoid them. I am expecting a lot of takeaways form this book for my Capstone course and professional career as well.

Chapter 1: “Professionalism” discussions about the taking responsibilities and the various ways to be able to accomplish the responsibilities in regard of the true essence of professionalism. First part of chapter surrounds with the things every software professional should be familiar with such as Test Driven Development approach, QA process, code flexibility and so on. Of course these principles are important during the software development process. When the writer starts to talks about gaining credibility and trust through continuous learning, practice, collaboration, and customer service; things get excited. I agree with the writer how learning process is necessary for self-empowerment. Being up-to-date with the new disciplines and techniques is a must in Computer Science field. Similarly, practice help individual to refine and enhance our skills. Personal drive and team-building skills are valuable and necessary for developers striving for the top of the profession, but more is required. Though most developers bring a project to the table, pushing it through requires a strong ethic of customer service. Customer is critical because it establishes a path that helps make sure that the features you are developing are really going the address your customer’s need.

Chapter 2: “Saying No” focuses upon team work. Martin gives a clear vision of how to be a successful team player. He states a team player is not someone who says yes all the time. Sometimes the only way to get to the right yes is to be unafraid and say no. I completely agree with the thought that, “What we all have to realize is that saying yes to dropping our professional disciplines is not the way to solve problems.” It rapidly becomes impossible to control all aspects of all the projects within a large area of responsibility. It is critical to develop teams that can bring the necessary talents to bear without requiring your direct intervention.

 

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

Week1: Getting Started on Project

During week1, I did not do much. The biggest tasks that I achieved were, first of all, the creation of group. I ended up in Sudarshan’s group with four other team members (including Sudarshan). We picked our team name: FantasticFive (#coolestname). I signed up for slack account and Tan made a group channel for our group so we can communicate with each other outside class.

I also start researching to learn about the OpenMRS project at http://openmrs.org/

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.

Reflections, Week 1

I spent this week learning JavaScript and Angular 2. I found a nice website that has video lessons on JavaScript (https://javabrains.io/topics/corejs); I listened to almost all of the videos.

I found learning Angular 2 quite annoying. I have become so used to Java that it is going to take me some more time to really get used to Angular 2. After searching for a while, I found a channel on youtube about Angular 2 that I liked (https://www.youtube.com/playlist?list=PL6gx4Cwl9DGBYxWxJtLi8c6PGjNKGYGZZ). I watched the first few videos and plan to watch the rest by end of this week.

I also plan to learn TypeScript this week; from what I have learnt TypeScript is a super set of JavaScript and adds features like class based object orientation and type checking to JavaScript and it is also really important in Angular 2.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

Capstone Project: Week 1 Reflections

This was the first week we began working on the Capstone project class. This week we didn’t do too much in the line of actual development so I don’t have too much to talk about. However, we did form the teams that we’d be working with for the entire semester. Myself and a group of my friends were lucky enough to all be paired together. We’ve done some group projects before and know each other’s work ethic and what we need to do to push each other. I really enjoy working with these teammates as well, so that helps immensely when you’re about to spend the next 3 months with them working on a project.

We are going to be working in the Ampath project that is part of the OpenMRS group project. I have looked into the OpenMRS project prior to this class but never took the dive to begin developing for them. I am incredibly excited to have an opportunity to work with a code base as large as this one. This will be the first time I really dive into a project that I haven’t worked on or seen previously and will be working with someone else’s code quite a bit and that will be a new experience as well. The project we will be working in using Angular2 which is a javascript framework that I have done small personal projects in but haven’t done anything to this scale so I am incredibly excited to be getting this experience as well.

As a side note apart from school, I have been brushing up on my Angular2 skills by following this scotch.io tutorial as well as learning Ruby during some of my extra free time. I am enjoying Ruby as a language however, I find developing in PHP to be my comfort zone and ruby syntactically is a bit different. I find myself forgetting to close if statements with end as well as my loops. I am sure this is something I will get used to but it will take time!

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

The Clean Coder: Chapters 1 & 2

The Clean Coder, this is my first book by Uncle Bob (Robert C. Martin) that I’ve read. Clean Code was on my list of “to read” books along with many other great books for programmers and developers. I had been working through Godel, Escher, Bach: An Eternal Golden Braid, albeit at a sluggish pace and that is a great book as well. However, I read through the first two chapters of The Clean Coder this week and it is simply amazing. It’s a breath of fresh air from all the other “coding” books. What’s most interesting about this book is the fact that, at least with these first two chapters, the ideas extend far beyond just software development. His ideas of professionalism will essentially make any type of career better.

Chapter 1 began by talking about Professionalism. Uncle Bob’s main point in this chapter to strive towards professionalism was taking responsibility for our problems. He elaborated on this and really pushed the point of “Do No Harm”, and by this he meant strive create working and easily maintainable code. Obviously this is what we all strive for as programmers, but he went a step beyond that and began talking about making the responsibility of “perfect code” ours and ours alone. Don’t leave it to the QA team to find and report bugs, take that on yourself. Don’t leave it up to someone else to refactor your code to make it more extensible, do that yourself. I really appreciated this point, because sometimes I find myself slipping into the mindset of, “I don’t need to take care of that, it’s someone else’s problem. Even if I don’t have the answer 100% I should do my best to help the person reach the solution faster.

Chapter 2 talked about Saying no. This is something I personally struggle with. I am the kind of person who generally can’t tell people no – especially my bosses. I was bread with the mindset, from an early age, that when your employer instructs you to do something, do it. Now not to say this is a bad mindset by any means, but in the real world this can seriously hurt your career and your companies future.

My first major piece of “Software” the I ever attempted at building was a simple front end for a database that also had some data crunching abilities. I also had to design and build out the database. My company is not a software company but an environmental engineering firm so no one really had a clue about building software/coding. Fairly straight forward and easy to build project, for a Senior in his CS degree program. However, when I started this program I was in my first year as a CS student. At this point I had written small programs in languages like Java or Python, but each of these programs did simply CLI type functions and nothing too complicated. I think the most interesting thing I had done at this point was a Fibonacci calculator that used recursion and memoization. I hadn’t approached any problems that essentially required an architecture that used a front end as well as needed data persistence. I had no idea where to begin but I dove in anyways. I told my boss it was going to take 3 months or so to build something like this. I was going to work non-stop over the summer on this project to get it done. The end of the summer came and I felt I barely had anything done. I was probably half way done with the feature sets that had been requested but felt I was on a roll. When my boss asked when it wouldn’t be done, I responded with the fact that I was “unsure”. I wasn’t sure what more bumps I was going to hit along the way because I had no experience at this. He gave me three more weeks and he wanted it done. I said okay.

I got all the features done is this program and it’s still being used at my company today. But I get requests constantly to fix some bug because I didn’t have time to test it. Because I didn’t tell my boss “No I can’t finish it in three weeks”, I was left with an embarrassing piece of work that I always afraid to show people due to my unprofessionalism during the development of that project.

In summary, I am extremely excited about going through this book and being able to apply what I read to not only Capstone project but also to my day to day work life. I think that not only developers should read at least the first 2 chapters of this book but anyone who builds a product for a customer.

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

The Clean Coder Chapters 1 & 2

In Robert C. Martin first chapter of The Clean Coder: A Code of Conduct for Professional Programmers, he talks about what it is to be a professional. Professionalism, in Martin’s view, consists of two things: responsibility and accountability. To emphasize these aspects, Martin goes over what should be done as a programmer to make sure you’re working as a  professional. First he talks about how you should take responsibility for your code. If there are bugs, you should know about them, and take responsibility for them. You should not rely on QA to find your bugs, and apologize to them if they do find any. Make sure to always test your own code and know that it works. Also always automate your tests so that you can run them whenever they are needed. Never harm the structure of your code, but don’t be afraid to update it to make it flexible. Also keep learning for your career and not for your employer. This means take time to do task like read up on current practices, software, and anything that is relevant to your field. Also learn new languages, help people that are new to the field, and find ways to practice your expertise with other professionals. Martin also states that being a professional as means understanding humility and that means knowing when to apologize for a mistake they have made.

In his second chapter, Martin goes over why it is important to say no when you are in a professional environment. He goes over that confrontation is a part of being a professional and, if you continuously give into demands to satisfy your boss or yourself, it can lead to terrible outcomes. In this context, saying no is more to make sure that you don’t give false hope to your employer, overburden your team, and produce trash code. Martin also points out that it is better to stand up and say something about a bad situation rather than say nothing and let things fall apart.

I thoroughly agree with everything in the first chapter. This type of thinking about how to code, making sure it works, and take responsibility for what you have done has been repeated through so many of the previous classes that I’ve taken. I also agree with Martin on the fact that you should always use time outside of classes/work to practice or read up on items that are related to your career. I personally found the second chapter more relevant to myself because I have been put in a position where it would have been better for both myself and my employer to have said no. Luckily at the time I wasn’t working in the computer science field, but for a small company. The owner would continuously ask me to start jobs, which I would agree to, and then add on more work on top of that. It got to the point were I was never able to finish one project because I could not say no to the additional work they wanted done. This eventually burned me out to the point of dropping all the projects and then quitting the job. Now I know that saying no is not giving up, but making sure that you keep your projects, and yourself, on track.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.