Chapter 1:

It talks about how just because you might have been a developer for a long time, doesn’t mean you are better than anyone else. No one person can say their skills are better than someone else’s because they have been working for a longer time, it doesn’t define their talent or knowledge. And with the times changing, companies want people who not only can code well, but can also help out in other parts of the field. Now, people want more things faster with better quality. And usually its integrated with everything else. I can relate to this because I understand that even if you work in the same place for a long time doesn’t mean you have the most experience. Someone new could come in and be way more experienced.

Chapter 2:

Seventeen influential people in the coding industry got together to share ideas and try to better their methods and techniques. What they came up with was agile development. It helps companies stay up to date with evolving soft wares and applications and the risks in involving them. With this type of development came problems. These people didn’t get the results they wanted, being agile actually ended up hindering their process. I can relate to this because to be great developers starts with being craftsmen at our craft. And to be good craftsmen, we have to master technical practices and constantly deliver quality.

From the blog CS@worcester – CS Blog by Gautam by csblogbyg and used with permission of the author. All other rights reserved by the author.

Chapter 11:

This chapter gets into the topic of doing what you are supposed to do, and what you’ve learned to do, even under pressure. Your training and experience has taught you to be calm and decisive and use your time wisely. It is also controlling and avoiding this pressure so it doesn’t become a problem in the first place. I personally sometimes have trouble doing this because I am very driven by the deadline, being under pressure helps me complete my work on time and drives me to finish what I have to do. But I did read that it would be best to avoid situations of pressure, to try to spread it out over a longer period of time to lessen its stress. It also talks about commitments and how they shouldn’t be made if they seem unrealistic, and the risk should be shown to the business to they can manage it the right way. It also talks about how you should make sure that there are no messes in your code, and you keep it clean. Most of all, do not panic, because worrying about it will not help you in any way, just take your time and don’t rush your work and follow your disciplines. If all else fails, go to a team member.

Chapter 12:

This chapter talks about how most programs and software are made in teams and that it is more professional to work in teams rather than a loner. Collaboration is one of the most important parts of programming. Even though sometimes it might be hard to get along with someone who isn’t really in your social circle, and you might even like to work alone, be focused all by yourself with no one to bother you, it is much better to work with people because you see the same problem from different perspectives and be able to solve issues you might have missed working by yourself. But with advantages come disadvantages, you should always make sure you know what the people who pay you are thinking and what their goals are. Your most important needs are to meet the needs of your boss. This means you would have to know all that is going on around you and interact with managers, analysts, and other team members. It is important to support everyone around you and keep your business afloat, and to do this you need to deeply understand everything that is going on around you, including your short term and long term team goals. You should always make sure that the code you are writing is accessible to the whole team and not just you, everyone needs to be able to work on it and make changes, not just you, and that is how you learn from each other. Sometimes pairing is the most efficient way to solve problems or debug. I understand this because most of the times if I ever get stuck on anything I always go to someone for help.

From the blog CS@worcester – CS Blog by Gautam by csblogbyg and used with permission of the author. All other rights reserved by the author.

My team and I finally got OpenMRS and AMPATH fully functional on all of our computers. At first we were encountering many problems and did not have everyone on  the same page but as time went on we did end up figuring everything out together. Even though some of us had our stuff working, we were encountering different types of problems that were even hard to decipher at first but many different downloads and re installs later, we actually have stuff working. I even encountered an issue where my GUI was just not showing up even though I had the same standalone as everyone else. It would not show up no matter what I tried doing. Even though it took us a while, we ended up coming together and helping everyone in need to get up to speed. Plus it was hard to stay on the same page as everyone because we all have different work to do outside of this class. It is now that we are actually starting to apply this scrum framework and realizing how to go about our work and communicate better outside of school. Most of our problems were not from actual work, but set up and getting the login to work. We have not finished rewriting the module but are still working on it. All in all, we started off our team work a little shaky but are surely making up for it and improving our communication and team skills where they are lacking.

From the blog CS@worcester – CS Blog by Gautam by csblogbyg and used with permission of the author. All other rights reserved by the author.

Chapter 9:

This chapter gets into the importance of meetings. Whether you should go to meetings, should be entirely up to you. You are being invited to a meeting, and you can decline that offer if you feel that the meeting might not be the best use of your time. You should always make sure you are using your time wisely because you can be missing important meetings if you get lost in your work, while on the other hand you could be completely wasting your time by being at a meeting you don’t even need to be at. You should always make sure that your presence at a meeting is necessary and truly needed, you should make sure that it is a mandatory meeting before going. And being at meetings, you should leave if you feel that your time is being wasted. Make sure you are using your time wisely, stay focused and make sure to get your rest, it is important to do so, you can’t get anything done with a tired mind. I can relate to this because many times as an intern I had to decide if me being at the team meetings every week was important or not. Also sometimes I’ve tried to work with low amounts of sleep and it has just not ended well.

Chapter 10:

This chapter talks about projecting valid estimations and also about the difference between estimation and actual commitment. An estimation is a guess from your part and it might not accurately represent when it will actually be done, where as when you are actually committing to something, you will have to commit to and finish what you have on your plate. Because you are a developer you must get better at your estimations and commitments even if you might not be too good at them now, it is a something you will get better at with more practice and as a developer you will need to stay at the top of your game and actually do the things you commit to. I understand this is important because I have had committed to projects that I had given the wrong estimates for and had not been ready and finished with my work, when it was actually time to pass it in. So improving this quality as a developer is key.

From the blog CS@worcester – CS Blog by Gautam by csblogbyg and used with permission of the author. All other rights reserved by the author.

Chapter 7:

This chapter is mainly based around the idea that communication is key and is necessary for a developer have, not just their ability to develop. It is very difficult to keep up with what you think the business side of developing would want and what they actually want or think you are doing. With that in mind, the programmers can only make what they Think is wanted from them, and so this process is filled with errors. It also talks about how not only developers, but also business have a problem with their premature precision. Both sides, business and developer usually want to know an estimate of what people are going to get and what you are supposed to deliver to give an exact estimate of how long the process should take, but this task is nearly impossible. Also the outcomes of a product usually end up being different from how it was planned on paper simply because it doesn’t always come out how you imagine or plan it to. What helps this ambiguity sometimes is acceptance tests. Acceptance tests are tests written in a collaboration of stakeholders and programmers in order to define when the requirement is done. This all helped me realize and look back at times that ambiguity could have led to some miscommunication in the group which effected a person to think that they were done with their work, when they were not. So using acceptance tests would help by making it all much more clear than before and help define the context of the problem in precision and communicate its context clearly.

Chapter 8:

This chapter teaches about the fact that writing unit and acceptance tests is good but not enough, what you really need is to have good testing strategies. Even though the company you work at might have its own QA group, you should not use them to find your bugs, your goal should be to eliminate any bugs that could be present in your code, before it even gets into QA hands. They should be working together with you and your team to try to make sure the high quality set for the system is actually reached. Now even though your goal is to try as hard as you can that no bugs should slip through, that is plain impossible and that is the whole reason the QA group is there, to help you catch the bugs you missed. I also learned that QA work with business and make automated acceptance tests that establish the true specifications and requirements document for the system. While the business updates and gives their requirements, the QA then turn that information into tests for the developers.  This also showed me that the QA group is there to use testing to see the true behavior of the running system and report it back to the developers and business, not interpret the requirements.

From the blog CS@worcester – CS Blog by Gautam by csblogbyg and used with permission of the author. All other rights reserved by the author.

Chapter 5:

This chapter talks about how at first you might be skeptical about test driven development, but using it will undoubtedly show you how much better developing through the method of tests first is over writing a lot of code and then some tests for it (that don’t even end up working). It talks about how if anyone still wondering if test driven development is the right way to approach code, they are blind to not see that it is the best way to do so and that its proven that it works. At first you can’t even write any production code before writing your first failing test. You can’t write more of the test code either and can’t write any more production code that is passing the currently failing test. This way of writing code has proven to reduce defects by even up to ten times. This effeminately helps me see that writing tests to fit your code rather than to write code and then tests to run in it is the (maybe not best way to code with the least amount of errors.

Chapter 6:

This chapter talks about how every coder, like every athlete needs to practice his skills and continue to do so to master and perfect them. Only then will he get better and make his coding stronger. It was not common for programmers to be practicing their coding languages as a way to help them up until around 2000. It wasn’t until recent years when we even started using screen editors, so we used to take a long time to compile codes and find errors to debug. We would have to wait for code to be returned to work on it again. Now, with the evidence showing us how much we can catch such problems before they even appear, we need to realize that this is the superior way of coding and should be used by all professionals. It does not matter if you are just new to coding or are even a master coder, practice will make you better and you might even uncover skills you might have never found or tricks you pick up while practicing, no matter what the situation, practice makes perfect. I have realized that doing the same thing over can help you see it in different ways, that is why practicing is important no matter what you are doing.

From the blog CS@worcester – CS Blog by Gautam by csblogbyg and used with permission of the author. All other rights reserved by the author.

We haven’t been doing too much, we just finished our first sprint and got together to talk about our reflections and how everything went and whether anyone had any problems or not. We also performed a review for each individual group member in our group and how how they performed doing the tasks we were assigned or even if they hadn’t been posting their daily scrums and quickly talked about everything we needed to cover. This helped us get a feel of how each sprint would go and helped us strengthen our scrum framework and communicate thoroughly with each other.

From the blog CS@worcester – CS Blog by Gautam by csblogbyg and used with permission of the author. All other rights reserved by the author.

Saying Yes:

Even though it might be important for you to know when to say “no,” it is just as, if not more important to say “yes.” You will need to learn the language of commitment. The three parts to making a commitment are to “say that you’ll do it,” “mean it,” and “actually doing it.” This chapter helped me learn that using this language of commitment, you can figure out what someone is saying by noticing the words they use. It is rare when people say something, that they actually mean it. and will get it done. Some other people will mean the things that they say, but will still never get them done. And last but not least, there are those people that will commit to big promises and will never even mean to get them done. Specifically, if you want to know signs of non commitment, they can include, using the words “need/should,” “hope/wish,” and “lets.” Chances are that if these words are being used, that the person doesn’t feel that it is feasible to do these tasks or even if they just don’t mean it. Starting to use these language tricks instead of following your gut can help you tremendously in your professional career and help you understand if people really mean what they say or not. This helped me realize that subconsciously sometimes I will have a task at hand that I will want to have done by a certain time, but sometimes might not be able to, and that it might be because of non-commitment to myself, by either not believing that I will be able to finish certain parts or even have it straight undone. I need to understand and not overestimate how much overtime I can put into a certain project.

Coding:

We also learned about when to and when not to code. It talks about how it is either good or bad thing depending on the level of focus or concentration you have on the topic. Since coding can be a strenuous activity, it can require you to juggle a couple different factors together at once. These factors could include things like having your code actually work. Secondly, your code must solve the problem, given to you by the customer. Your code your fit well into the system that you already have, and most importantly, your code must be readable and understandable by others. Not concentrating o these factors can have you exposed to distractions that otherwise would not be present in your team of developers if you were organized. Even if you try to ignore these things and code your way anyway, the code you come up with will be wrong. It will be convoluted and filled with bugs and it wouldn’t really solve the customer’s problem so it will have to be redone. Much like being tired or distracted, or even having the time be really late like 3 am, do not code, it will not come out as well as you plan it to. Professionalism can be related to the amount of hours and dedication you put into it. It can be seen i your work. But also we are warned about coding in “the zone.” It will have you lose sight of your big picture and have you seeing tunnel vision. This chapter helped me realize, that no matter what, and no matter how good you are, your life will always involve throwing your curve balls and challenges as you code, you will just need to find fixes and ways around it to come up with good code but it can always be done and distractions can be put to the minimum.

From the blog CS@worcester – CS Blog by Gautam by csblogbyg and used with permission of the author. All other rights reserved by the author.

So the second week of class didn’t consist of too much either, other than getting your environment set up and just getting your required software and making the accounts we will need to further our work. Even though we only had one class this week, we still got a chance to get together and work on a list of some tasks given to us. We are still focusing on doing tutorials and learning as much as we can of angular 2. I learned about what slack was and how to use it/what its used for. We all set up our slack channels and linked them to trello so we can effectively communicate through out the week, even if we don’t see each other and apply scrum framework to our processes. I also learned about trello, and that we can use the trello with our slacks to make a backlog of items we need to work on, are working on, and are done with and all share it with each other. We all also had to create a student account to get to access all the tools from Jetbrains for over a year, giving us many of its useful tools like the Webstorm IDE. We also all introduced ourselves and posted on a forum and replied to our AMPATH client for the first time.

From the blog CS@worcester – CS Blog by Gautam by csblogbyg and used with permission of the author. All other rights reserved by the author.

While in my capstone, we are also expected to stay up with the chapter readings in The Clean Coder. I’m sure that I am going to end up learning a lot of things from our readings, especially how to behave in the professional environments we will all soon be present in.

Professionalism:

This first chapter helped me realize how “professional” is a loaded word. It really all depends on you. You could be working straight out of your basement and still have your work considered more professional than someone working with a team of developers. It all comes back down to the quality and effort put into your work, and your accountability/responsibility. Obviously it is impossible to make code that has zero imperfections and no bugs but that doesn’t mean you can’t take responsibility for your imperfections. You need to start being held accountable for your errors and to make them as minimal as possible, even though it is impossible to error less, you can only try to make it as close to zero as you can, but remember that might need to apologize but don’t keep apologizing and making the same mistakes as if you didn’t learn anything from it.  Most of all, practice and stay up with knowledge, learn the new techniques coming out and keep up with the times except sticking with old techniques. Keeping with the old ways will hold you behind and continuous practice is the only way that you will improve your craft.

Saying No:

One of the most important parts of being a professional is knowing when to say “no.” Even if you are talking to your boss about a due date, a professional speaks truth to power and knows when when to say “no” to their managers, only slaves are not allowed to say no. Laborers look for people who can tell them “no.” They need to be told “no” in situations where something really can’t be done on time or any other problems arise because if someone didn’t have the guts to say so and does not end up reaching up to par with the progress he told his boss that hew would be done with, it could lead to a larger scale and even worse disaster than before. Not lying to anyone you work with is the best thing you can do. Communicating is important even when something can’t get done on time rather than just for problems. Trying to defend your position and explaining the “why” in the situation could help even more. Rather than just passing for whatever your boss or coworker might tell you to do, you need to explain to them that it might be impossible to do what they want rather than false promises which they believe blindly. Offering to “try” to finish a project before you think you can finish it is a lie and a commitment to succeed when you might not be able to, which just ends up putting a burden on you.

From the blog CS@worcester – CS Blog by Gautam by csblogbyg and used with permission of the author. All other rights reserved by the author.