In chapter 15 of the software craftsman goes about covering the whole “quality over quantity” shebang which I can not express enough on in terms of development. Now a days people would something that works properly than a whole bunch of half-broken features that seem like they are rushed and poorly done which ruins the reputation of the team when its not completely their fault.  In the end the author blames lack of skills which will defect the quality which ends up revolving around the whole “software craftsman” value around this entire book kind of symbolizing how having craftsman on your team will avoid these poor quality issues. In the end, quality and something that works is the most important part no matter what the requests made by the higher-ups.

If you do not understand “quality over quantity” comment, its not wise to lead without understanding this. Something short but sweet is much more preferred than huge and sloppy. Art is never rushed and creations are always viewed as an instance of beauty in the world, where its up to you to lead team to make sure it doesn’t look like a really bad smudge.

Finally, in the finale of finals. We take a stroll in the 16th chapters of this interesting book where we find out that the last topic the author covers in order to wrap up the craftsman story which is a career of a software craftsman. In the end, the career revolves around one thing which has been mentioned numerously here and other in the Clean Coder, and that thing is the feeling of passion. A true craftsman needs to love what they do, then they see the light of how awesome what they do is. you can’t get enlightened if you don’t have a spark to guide you. Simple enough just take it slow one step at a time and your milestones will reach you and your goals will be rewarding. Its an adventure worth taking only if you love it.

As the end of this course ends, as well as this book. Looking back at this as well as clean coder taught me many things mainly because they have been repeated in the same books, which isn’t a bad thing to be honest. They both tell the tales of professionals and their stories along with their experiences that crafted the advice that they give to us and in the end it all comes down to where you have to love what you do to enjoy it and be good at it. That is the biggest stepping stone, not just in programming, one needs to realize in order to advance far into life, into a world full of adventure.

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.

One of the ways to keep the workforce up and running is to continue providing fuel to everyone’s curiousness by giving them something to learn every now and then. Chapter 13 of the Software Craftsman focuses on the culture of learning and how it can spark and continue everyone’s motivation and morale. Some of the ways the author increases learning is having extra activities on the side for everyone to participate in, whether if its just a book club or a time slot dedicated for lunch and talking geeky things or even if it means having occasional group discussions to keep the environment engaged. Switching projects is also another tip that he mentioned however it could be a bit risky, but it is definitely effective especially if one has a hobby project they are working on and boredom of the current project lets them want to work on their hobby project.

What interested me was the fact that there is a chance not everyone wants to join in on the side fun, and that is perfectly ok as the author puts it as well. You can not change anyone and people have their own interests and stuff to do, but at least the opportunity is there for anyone who wants to give the side activities a try which is nice. The best part is you have done everything you can to make things better, and that’s something to be proud of.

In Chapter 14, the author takes a different turn and goes back into talking about technical aspects. In this chapter, driving technical is the main topic that is cover and if its one thing that author made clear, it is that taking on that challenge is very difficult. You are put into calling the right choices that will critically affect your project and the team and its a time where you must hope none of your choices carry consequences. As a leader you have to get used to everything and everyone’s different approaches against you or the project and it can be very stressful if you do not carry the same language.

Leadership on a more intimate and personal note means you have to lead a small team that you actually know how they work and you know their names by heart. While this is the most preferred structure to work with in my opinion, leadership for thousands of people will lead you to think of them as just numbers on a chart with no value as you do not know all of them which is scary. Knowing who you work with is critical as a leader and it is a greater chance you will not lose control.

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.

On our last sprint, we were flooded with challenges and problems (mostly not on our side) in a way most of our issues to solve is not in our control. Regarding the button, we knew how to fix it and decided on a location to put it which was on the header of the patient dashboard. The button was also not fixed still and we have not gotten any replies from the devs regarding the issue that Pat put up on JIRA. While we were trying to apply the solution to moving the button, we did not have enough time to actually implement it let alone also get the approval at the same time from Jonathan Dick about how the button should be handled, if it even worked for the matter.

Other than the button, the issue I was working on regarding changing color to reference a patient’s status took an interesting turn. After figuring out how to make a proper if statement in an HTML page within an element, I was notified by Ryan the repo was updated and they already addressed part of the issue which was putting a color on whether the patient was dead or not. They put a mutual operator as an if statement and made another style bracket with the right properties to call. There was a patient.person.isdead component that I could have used to tell if the person was dead and they used that. I decided to do the rest by adding in whether if a patient is defaulting or transferring but I could not because there was nothing to declare those statuses. When I asked Ampath about it, they said I can not do anything from here and they have to do some server side coding in order to tell the default and transfer statuses which led the rest of the issue out of my hand let alone the issue status was put to critical.

Regarding the contacts Kyle and Pat were working on, they were still not functional for some reason as the properties put into the contacts list were not saved and always resets to blank every time.

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.

Extending the topic of interviews, the author goes into what not to do while interviewing a candidate in chapter 11. One of the topics he goes into is making sure not to sound like you are smarter than the candidate himself, it just makes you look like a fraud and the whole meaning of the interview is not about you its about what the candidate knows. On top of that, an interview is not a quiz, there is no wrong or right answer but only an answer of getting a sense of what you are getting from the candidates. Trick questions are not welcome, however if you want to see how a candidate approaches an answer that may be valid if you are not grading it in terms of correctness. Do not block candidate from the internet too is also a good point that the other makes, we all are not perfect and the fact we wish to use a resource for help like google or stack overflow is a good thing.

If only we could read someone’s mind would interviewing be easier, though we may not like what we see so many that is not the best bet. I agree that finding good developers is hard to begin with and also time consuming. But that makes it well rewarding in the end where you realize you found the right person to hire, who may or may not use the internet. No one is perfect but patience in your search is very rewarding.

What is also important in a project’s development is the teams morale which I am glad that the author covers in chapter 12. What is the point in working in a project if you are not motivated to do so? There is this feeling called passion and it is the greatest feeling in the world because you get to express love in regards to what you to, which in this case is programming. If passion is gone, production will fail greatly, its like one drains a soul of what was once alive and well and measures should be taken to prevent that from happening.

If there is a way to release stress from everyone in a simple matter, it would be great but it does not hurt to get rid of most of it instead of all of it because stress keeps you aware. Too much of it is like a drug that could cause problems. Avoiding this agile hangover is hard but is worth in terms of find a solution into keeping the environment a happy and cherish-able place.

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.

Chapter 9 of the Software Craftsman, covers one of the most delicate processes in develop, which is making sure who actually gets to work in your team or not. This could either destroy or strengthen your project as a whole, which is the case where you must take this opportunity to be super careful and thoroughly examine each candidate as they are tasked to be one of the pillars holding up the roof. The worst thing you could either do is put up a bad job posting which is not descriptive enough to properly communicate who you are looking for in the workplace and also not interview the candidate yourself if you are said too busy or some other lame excuse. Missing this opportunities is what causes obstacles you are force to handle in the future unless you are fire-friendly which is not a good sign in the first place.

The hiring process is surreal as there is a huge pool to pick from and the boss’s professional experience is what aligns with the skill-set of the applicant to see whether or not the boss knows what the candidate is doing even though the boss may not know. I agree the agencies that recruit people should be used as last resort, as the person to hire should come from yourself, the one leading the team.

While kept short, the author continues the topic of recruitment in a way in chapter 10 except that he talks in particular about interviewing the perfect developers known as software craftsman.  If one wants to hire of these craftsman, the author places an above-and-beyond view on them saying that they do not just want a job but they want to have a good partnership too and also have more expectations than the person interviewing them which is the impression I am getting at. They can also learn from the interview how the team is like and how they are being treated which is interesting which pulls of a reverse kind of vibe.

There is nothing wrong with interviews people who are very talented and may be the ones you are looking for, especially when they are looking for a lot as well. I was not looking for much when i got interviewed for my job, and my boss was not looking for too much either which kind of helped me catch the vibe there, which of course changed overtime.

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.

Overnight, Ryan found out that the pull request he processed with AMPath unfortunately did not go through as apparently the way we edited the code and the way we moved the button’s location was not the way the AMPath dev’s wanted it. At first we were upset, because the lack of communication and detail in regards to moving the button let us think different on how to approach the issue. Johnathan Dick wanted the button to be placed in a way where it would also have a fixed position. This way whenever the user scrolls the button stays in place in the same place so you will not have to scroll back up in order to click on it.

For the record, the button did not work still and AMPath did not get back to Pat regarding the button not working as a whole either which was also a bummer. After we knew what was needed to be done (which again was not stated in the ticket), we decided to see where we should put the button. We thought to put the button in the header area since the header always stays the same position and it would be easier to use that as a relative position. This idea came in handy because we were also told that AMPath is going to most likely be used on tablets so we have to test on different resolutions as well which made it more trickier to place the button on the right place. Professor Wurst managed to get us a tablet to test the resolution thankfully.

While this was happening, we decided to split into groups where I tackled another issue which is changing the color on the patient dashboard to indicate the patient status as well as Pat and Kyle were trying to get the contacts section of the dashboard to work. On my end, I found out how to change the color of the patient dashboard and was told to change the color accordingly if the patient was transferring, dead, or defaulting. While I found the CSS and changed it, I did not know how to change to certain styles dynamically in HTML since i did not know how to do a proper if statement in a element tag in the html area of the site.

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.

We are human, so it is no surprise that we thing differently. There probably will be case out there developers question the practices during development in terms of following a organized structure or workflows. Chapter 7 of this book covers why these practices are needed. Covering the use of technical practices, it is mentioned that there is a learning curve and people in the team would have to adapt which also means more time and money which makes it harder to persuade to use these practices. The chapter also goes through Test Driven Development which is gratefully something I am familiar with and how the extensive testing is important in terms of making sure nothing breaks.

When I was going through the chapter, I saw that TDD was mentioned as a recommended practice and it reminded me about when I had to use that during my software quality assurance testing course. Using java and Junit testing to extensively test software brought back the memories when trying to relate to the author when he relates to why these practices are recommended.

Chapter 8 covers one of the hardest  tests of being awesome. People tend to dream big, which is another human thing do, but when they go out to settle for what is driving their ambition they find it harder than it seems and give up. As the author calls it, the long road is the road where people are having a hard time trying to stay motivated to be good at something and are realizing it is a challenge when it comes to mastering a skill.

If you have a purpose, a focus or a goal to aim for, I can not express enough it will take time and effort, more than you would imagine in order to achieve it. The good news is though is that it can be done indeed and the fact that the finish line does exist somewhere, the only thing stopping you are your doubts and that should be the only obstacle you would ever need to avoid. Though, its not easy to stay focused, especially if you are aiming for big projects. Setting sub goals along the way help out a lot as it keeps you thinking you are getting closer to your main goal, which is not a trick because you are really making progress.

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.

Going into Chapter 5, the only thing I can recall is the same topic the other author discussed in Clean Coder was pretty much the same thing. This chapters covered the confidence and necessity to say No during a project when you need to even though it may upset your client. There is a thing called dead-lines which have to be accounted for and these dates tend to cause the most stress in development where in some cases the deadline may or may not extend. There comes a time where your employer want you to add more to the plate even though there is already enough to deal with let a lone there is the fact that unexpected events happen during development which can not stop the deadline from happening. The chapter describes how to professionally say you can not do something as well as give a good reason why to. After all, it may make you a hero.

Interesting enough, this topic instantly reminded me of the Clean Coder book which talk about the same topic and pretty much has similar advice. That is actually a good thing knowing that something you read is reliable especially if different people go by it.  I love its mentioned you should provide options if there is bad news. It sounds like you want to make the best out of what you got and not just not wanting to do work.

Chapter 6 covers what is also another aspect in development which is knowing that even though you have something that is functional and working, is does not mean it is the end of the project, the finish line is far from over and the team only hit a milestone. There comes the whole fact of maintenance and on-going support that the software will require after launch. You need to have updates to fix bugs and hopefully add new features, let alone if the developers know how to do so professionally. Speaking of bugs, testing your software profusely is another key part after launch as there are bound to be user reports of certain areas not working, you may never know.

As I like to put it. The end is not the end and even though your software is out in the wild  (congrats by the way you do deserve some champagne) you have to give the impression that you care about the product and tell users you are still there for them when they need help using what you created  No it doesn’t have to be forever, but a garden does need to be looked after.

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.

After contacting Jonathan Dick regarding trying to find the draft button and trying to get the forms to work. He told us to use the test 2 server path in order to get access to the forms and such and in theory it should work. We tried that originally and it did not work. We thought we had to log in to openMRS itself and see if that was where the button was because we had no clue where else to look. Afterwards, we did what Jon told us to do for the sake of it and then this time around it actually worked. We managed to load the forms and then Kyle managed to find that orange “back to draft” button that was on the far right of the screen. What was unfortunate is that the button did not even work when we tested it out, so Patrick reported that to AMPath however they did not reply back to him about it. Instead we just focused on moving the button to place AMPath devs wanted us to move it. We decided to move it to the left side because it would be easier to see and not miss.

When we got into class on day, we saw that Patrick already found the code to move the button and have moved it to the left side of the screen and we were proud of it. All we had to do was find the appropriate styling and edited the button’s alignment. After feeling proud of it, we ended up pushing the changes to the main repository that Ryan created and then Ryan began the process of requesting a pull request hoping that it would get approved.

Our teammate was disappointed on a grade we gave him regarding his lateness and that he was put into the improvement program. We decided to help him out to improve his score before it was too late.

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.

In the third chapter of the Software Craftsman, the author goes in depth of what Software craftsman actually is. The author uses this term in order to describe good and angelic developers who always want to do their best and give their project the most value they can ever give it. They want to be productive and get things moving along and just leave things in a cluster, and that means with clients and publishers as well. I guess this is what he calls a ‘Dream Team’.

In my opinion, this probably should end up being the whole resolve of the book even though its just a chapters that’s not even the first one the author dives into.  I feel like in this chapter the author is being kind of sarcastic because he does not tell you what the definition of being a Software Craftsman is. He is telling you what it isn’t and also what other sources say such as wikipedia. Instead of getting straight to the point he just mocks the reader. Later on he finally stats that Software Craftsmanship is about professionalism in software development. This chapter could have been straight to the point and overall shorter. I’m reading to learn not to waste time.

In the fourth chapter, the author continues touching base on developers’ behaviors except this time he is talking about the attitude toward the project. Making a good point that if we think good code from the past is still good, then we are not learning anything, the author goes into how much craftsman care about their work, which also includes discovering new things and adapt to better outcomes to help suit development in this future time-frame.

This chapter came to me as a good advice kind of area where he mentions good practices a developer should commit too on their own time that inflicts on their skills. Always practicing, staying up-to-date and keeping communication with the outside world are great ways to actually stay in shape as a developer and evolve the precious skill set.

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.