The first part of the reading talks about pressure in the work place. Commitments are a big deal in a professional environment and while you should try to avoid them as best you can sometimes other people make them for you. You are not responsible for these commitments if you did not agree to them so you should not stress over them. Keeping everything clean will help reduce stress, so make sure to take the time to make sure your code is clean. I know that if I start coding quickly and dirty that it becomes a mess and I get stressed out. Don’t be too proud to get help, if you’re running behind find a co-worker that is willing to help you.

The second section talks about collaboration, it’s a very important part of programming, we can’t do it all ourselves sometimes. When working with a team do not “own” your code, make the code accessible available to change by anyone in the team. A lot of programmers did not get into their field to work with people, quite the opposite, most did because they don’t enjoy working with people. Unfortunately there is no way to avoid this, working with other programmers and clients cannot be avoided.

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

In the first section of the reading time management was discussed. One of the biggest time wasters could be meetings, they may seem important but many times they are not manditory. If you feel you are getting nothing out of a meeting, then leave. A big issue with wasting time is if you are not focused. Do your best to stay focused because if you’re not you’re not going to get anything done. A few strategies to help stay focused is take breaks, get enough sleep, drink caffeine, etc. I know if I’m tired and can’t focus it takes me twice as long as if I were focused.

The next section talks about estimations in your project. Theres a big difference between a commitment and an estimate. A commitment you must follow through with in your professional career, an estimate is a guess on your part and most likely will not be accurate. The best way to estimate tasks is to ask the people around you, they might actually know more about when you can complete a certain task. As a professional software developer you will become better at estimates, even though things could still happen that will throw your estimate way off.

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

Acceptance testing is discussed in the first part of the reading. This is a broad subject that can be looked at different ways. Some ways this testing can be done is by having someone help you write that tests that doesn’t know how to code the tests. Also when estimating when tests will be complete, it is very hard and should not be given an exact date, but a large time frame. When a test is acceptable it means it is done, fully and completely done.

Different testing strategies are then looked at. The QA team should not find any bugs, but they usually will and are a large part of the testing process. Unit tests are the most broad and cover the most about of code, these tests are mainly for the programmers. Integration tests take component tests and make one big test from them. System tests are automated and we can set them and forget them for the most part, but they cover a very small amount of test in the program as a whole.

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

The first part of the reading was about a topic I am well aware of by now. Test Driven Development is discussed and why we should all be using it. I have used TDD many times when coding and the benefits are clear, it may seem like you are doing more work than you should be, but at the end of the day you know your code is clean and almost bug free. It goes on to say that TDD should no longer be argued about using, it should be used without argument. There are no downsides that are large enough to prevent a programmer from using a TDD approach.

The second half of the reading was pretty straight forward, you should always be practicing. It doesn’t matter how long you’ve been programming you can always improve, you can practice to write code faster, learn a new language, write certain algorithms with ease. When it comes to TDD, just knowing exactly where the keys are to write your test can help reduce programming time dramatically. Most if not all practice should be done on your own time, so you become a more valuable employee over time.

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

Not much has happened this week, I have continued to work on the Angular2 tutorial. We participated in a group sprint and decided what would be done during this coming sprint. We were given access to an OpenMRS github project. I cloned the project and I’m currently working on getting it running in WebStorm. Not much can be done right now until we get the project up and running on our local server.

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

During this week we were put into groups and asked to join the courses Slack team and to make a channel for out group. We also learned about Scrum and how we should be working on our upcoming project in the Scrum fashion. Using the Scrum way of working together I think will help us to stay motivated and organized. I then researched OpenMRS and AMPATH, we will be working on projects within AMPATH. While working on this project we will be using Angular 2, so I did some research about Angular and looked up some helpful tutorials that I can use later to help start the learning process for this language. The Scrum way of working together I think will be a valuable skill that I can take away from this course and apply to my professional career.

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

In these chapters the difference between a professional and nonprofessional are looked at. Professionals take responsibility for their work and pay the price if a mistake is made. We all want to be professionals, but not all of us want to pay the price. Standing behind your code is another topic, be prepared to apologize, if you sent out your code and there was a bug, don’t hesitate to apologize and take responsibility. Also always be learning new things, outside of what your employer has you working on, this will help your career in the long run.

Another topic discussed was about when you should say not and not be afraid to say no. Many people feel the need to say yes to their superiors or colleagues to avoid an awkward conversation. To be the most professional you should be honest and upfront about your work and how long it might take for it to be completed. It is better to end up in an argument with your boss about a late finish date than to lie to them and say it will be done earlier knowing you cannot reach that date.

These chapters were very helpful to me in terms of how to react and how to work well in a professional work environment. One of the biggest that stood out to me is the right time to say “no” to your boss or co-workers. If you believe something is not achievable then you should have no hesitation to say no that wont be able to be accomplished.

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