Software Craftsman Chapters 11 and 12

Chapter 11

I enjoy how this chapter opens with the “Don’t Be a Smart-Ass Interviewer”. There is nothing more I dislike than someone who thinks they are better than you and try’s and prove it. If I ever walk into an interview and that happens I would like to think I would leave. I don’t have the time or tolerance for such nonsense. I also enjoy some of the questions he says to avoid in the brain teasers, “How many golf balls can you fit into an airplane?” Hahaha. All joking aside I think that this chapter is pretty much a common sense issue and unfortunately I think that some people really need it beat into them. It is common sense you shouldn’t ask questions you don’t know the answer to and don’t make the candidate look like a fool. If someone does not know these basics, they probably shouldn’t be interviewing anyone, or maybe even be in any position. I also like how he talks about not blocking the internet during a coding activity and goes on to say, “I wonder how they would do without it?” I also like his thoughts on not asking the interviewee to write out code on paper or white boards and feels they should stick to what the candidate would face on the job. Great tips and I am certain I will run into interviews where I am asked to do these things.

His take on not asking to wrote algorithms or algorithmic exercises is awesome. I like his thought pattern here on how they should ask something closer to the reality of the projects at the company and that how many problems weren’t related to the algorithms, but the lack of good tests and the like. Overall good chapter and some great advice.

Chapter 12

I really don’t have much to say in this chapter as I think it speaks for itself. Lack of morale is a company killer in my opinion. It is all pretty plain to see that if you lack motivation and hate the job you are doing than you will not bring anything of use to the company. It is contagious as well. People moping around complaining about this and that and blaming everything on so and so, when they really need to take a hard look at themselves. 

Software Craftsman Chapters 9 and 10

Chapter 9

There a lot of good point in this that I never gave thought to. I don’t believe I will be in a position to hire anyone for a while, but this chapter gives some good tips on recruitment. He makes a good point in how companies don’t get better because they are hiring the wrong people or advertising the wrong skill set etc. In my limited experience looking over job boards fr the CS field there does seem to be a lot of boiler plate style templates. I also notice that they are usually looking for x number of years experience in such and such and he is right that the number of years is not a very good judgment tool and experience. I have seen people which less time in a language that know 10 times more and are that much better than people with 10 years experience so it an uneven gauge. I also agree that companies should be involved with the community and have seen companies that do this. I use the web application meet up and go to presentations and talks by various companies in the field and they are great for networking as well as talking to potential new hires and such. It is also good to see for the person who is looking for a job in that they get to see what the company is all about and the people that work there.

Overall I think this chapter was well put together and there are a good amount of tips for the employer as well as future employees. I will probably refer back to this chapter in the future.

Chapter 10

I like how he described the interview as a business negotiation. I never thought of it like that, but that is indeed what it is. The company has its outlooks and is looking to keep up revenue and the prospective employee that could possibly help in achieving said goals and or challenges. His points on the hiring companies perspective is good. I feel like that when hiring people you would want hem to ask questions about the company. It shows interest as well as commitment to the company in a sense because they took the time to research th place and find out things about it so they could ask questions. There are time though that maybe the questions they had were answered during the interview, but still that should be stated. There are a lot of good points, but a lot are also in my opinion common sense like paying attention to how enthusiastic the person is when talking about technology or their previous jobs and experience, as well as project thy have worked on. If you have a dull unmotivated rock sitting opposite you, you may want to end it there.

I would have never given much thought about paying attention to what the interviewers role in the company is, but he makes a good point about interviewers that aren’t developers and are instead project leads or managers. I would have never thought that might mean that developers may not be empowered to make decisions. The single interview process is also interesting and worth noting. It would not have dawned on me that the company might be in a hurry and doesn’t take the time to hire the right people. I think overall there are some great points here. I like how he describes a good interview and I couldn’t put it better myself. “A good interview is like a good an informal chat between passionate developers.” I have been on interviews like this and have been hired. They are good because both parties are at ease and it makes it easier to be open about yourself. I agree as well about it being a mistake to hire someone without seeing them code or their code at least. It can give a good glimpse at their confidence and experience as well as decision making skills and the ability to take constructive criticism. Bringing your computer I don’t think I would have thought of, but it is a good idea so they can see what tools you have and use etc. Last but not least I can’t agree more with developers must interview developers.

Overall another good chapter with a lot of good information that I will probably revisit in the near future.

Software Craftsman Chapters 7 and 8

Chapter 7

One of the main reasons to implement an Agile environment I believe is that you are constantly reviewing and re-tooling the process to make it work in an efficient manner. I like how he opens with something similar to this and says something to the effect of not being tied down to a heap of documents and diagrams that were written a century ago. Technologies change fast today so what may have been good yesterday may not be good today, literally. In the author’s words Agile development provides a “quick, short feedback loop”. I understand, but I don’t understand why all companies don’t use extreme programming practices. He says that in one company they noticed a 1/3 reduction in production bugs. That is amazing and saves the company a lot of cash and it’s amazing that companies seem to value it so little as far as the book says anyway. I like his stance on how to convince a manager to use the practices by promoting the value of the methodology instead of the practice of it. That is good advice. Another thing that I was surprised by was the efficiency of automated testing, I mean I know that is a time saver and all that, but I didn’t realize the scale of its goodness. It does make sense though because as he says, “as the system grows so do the number of tests.”. Writing them before hand is a time saver and also gives you something to code to. I am not going to go into the rest of the chapter because it is a repeat of the Clean Coder. Test Driven Development, Refactoring, Pair Programming, Refactoring, Continuous integration, yada, yada, yada. I find that the book has its good points, but it is a lot of Clean Coder and I think that either one or the other should be read, but certainly not both in my opinion.

Chapter 8

This chapter brought back memories of me and my good ole commodore 64 chopping away at te keys in basic. I only wish I had stuck with it back then, but I am glad that I got back to my roots and got back into it again. I think out of all of the chapters I relate to this one the most, but on a personal level. I like the Yogi Berra quote, “ You’ve got to be careful if you don’t know where you’re going because you might not get there.” I thought I was doing what I loved at my last job until I got hurt that is. Then I was in a whole new situation and I didn’t like it. I am finally at the point that I know what I want to do and am happy with the decision, but it took a while to get here. I have been and am using a lot of his tactics. Expanding technical knowledge, attending user groups, and networking to name a few and they have been fantastic to me. Like he says a career is an investment. I am glad I am a bit older and have gained a lot of wisdom along the way so the process of changing careers has been ok, scary in a way but ok. I am doing what I love and can’t wait to put it into practice.

Sprint 7 reflections

Well this past sprint went well. Issue NGPOC-185 was successfully fixed and our pull request was accepted, tested, and put on the live test build which is awesome. I learned a good amount by reviewing the code and trying to figure out the issue, though in the end Dan solved it. I have found it quite the experience so far. After completion of NGPOC-185 we decided to split into 2 teams which was for the better because it seems like a lot of the issues don’t need 6 people working on them, but for a start it worked out well as we were getting our feet wet. We chose issue APTS-159 to work on which they wanted the list in a form to show in order of date, newest to oldest as it was supposedly backwards. After investigating the issue and implementing a solution we found out that issue had already been fixed. Brings back memories of people not closing tickets and wasting time. In this scenario it was a learning experience, but in the real world time is money and this would have cost the company a few bucks. It is kind of nice though to see the process working and having to dig through code to figure out where an issue lies and then figure out how to implement a solution. I love troubleshooting.

We are now on 2 issues, one as our split group of 3 and the other as a whole team. We will probably only get one done possibly because time is running short. The first issue is AA-680 which is “Can't add child to parent relationship”. The problem we believe lies in the database which we do not have access to so we are waiting on an answer from OpenMRS on this. We have found where the relationship lies in the code, but cannot do anything until we get an answer. The issue is that there is only a parent/child relationship and no child/parent relationship. In other words if a child is seen at the clinic, there is no way to add a parent to the form in the relationship drop down. It seems like in this industry, or at least this project there is more time spent waiting on clarification than anything. I understand there are different time zones and such but it sometimes seems counter productive. I guess though you can have multiple issues signed out and at least there is communication. I feel like I am learning more about how the process works than actually learning Angular, not that I am not learning Angular I just guess I thought it wold be different. That is the beauty of it though I guess.

The next issue we are now working on as a team is APTS-254 and they want a reminder to pop up 6 months after switching to a new ART line. This is another issue we are currently waiting on answers for . We have nailed down the area it is in and it seems like we need to just implement a reminder function possibly, but once again we are waiting on clarification, so it’s the hurry up and wait game I guess. It isn’t anyone’s fault it just gets frustrating because we all want stuff now and that isn’t how the world works. I feel confident that I can look at a project now and understand how things work and figure out the routing and logistics of it and that feels good. I am glad I have been able to have this experience and hop that we can get one more issue pulled up before the end of the semester which is soon.  

Software Craftsman Chapters 5 and 6

Chapter 5

I have to say it seems like just after I get done with a decent chapter I move on to the next and boom! You can tell that this is an Uncle Bob series book. I am so tired of hearing the word professionalism and professional that I want to puke. I am going to keep this chapter’s blog short. Maybe it is because I have been through a lot of the scenarios he talks about that I get irritated. This chapter is almost exactly like a chapter that Bob wrote in the clean coder. Never say I’ll try and get it done because the boss takes that as you will, don’t over exert yourself or you’ll get burnt out, you can’t code good at 3am, sleeping in the parking lot and getting a horrible nights sleep is a bad idea etc. I get that it is important to learn how to say no, and not commit to something you know you can’t deliver even if it means getting that nasty look from your boss or a guilt laden trip from hell. I just think it is over done in the series. I understand that important things need to be reinforced, but I think it is over done here. I will stop ranting now, because the book does have its good points, I just am not fond if certain chapters.

Chapter 6

I do have to say that this book seems to alternate good and bad chapters to me. This chapter I thought was informative and had some useful stuff. I agree with these guys on their stance of having clean code and working software, or being a software craftsman if you will. He hits on many things in this chapter and something stood out to me right off the bat. He said that “some organizations believe that with a good management team, deep hierarchies, micromanagement, strict process and a large amount of good documentation and the project will succeed.” One other line was that many organizations see developers as lesser skilled than the higher qualified managers. He hit the nail on the head with those two statements. I have seen this in most every industry I have worked in. They always seem to forget that us underlings are the cogs that keep the machine turning. That is not to say that good management isn’t important, I just think there is a lot of backwards thinking and it is maybe because they pay the management ludicrous numbers and they need some way to justify it?

I also thought that his stance on working software is not enough was well done and very true. I think there are a lot of hacks in every trade that thinks that good enough is ok. I firmly believe that you should take care of your code like you are looking after your garden. It needs to be weeded and groomed and fed to ripen and blossom. It is like a living being it seems to me. Especially after working on the Ampath project and seeing how projects work and the communication and all of the collaborators working together. He says the cost of dealing with bad code can make companies less competitive and I agree. It reminds me of a saying my father used to say to me, “Don’t do it half ass because you’re just going to have to do it over again and it will take twice as long as if you’d just done it right in the first place.” I can’t argue with that wisdom as I found out the hard way a few times more than I care to admit.

Over all I really enjoyed this chapter and took away some things from it. I really hope that I don’t end up working for a company like some of the nightmares he was talking about. So much about Agile development makes sense and on paper is grand, I just hope that at least some of the methods are employed when I get out there.

Software Craftsman Chapters 3 and 4

Chapter 3

I am finding it hard to get into this book. So far it seems like a re-write of the Clean coder but with different wording. I hope I am proven wrong as I progress further but so far I am kind of disappointed. Do we need a chapter devoted to talking about whether the skill of programming is a craft, trade, engineering, science, or an art and five definitions and metaphors for software craftsmanship? I can’t believe there are debates over this to be honest, I mean I was always taught that when you work you do your job to the best of your ability and put in an honest day of work for your pay. I think it should be common sense that no matter the profession, you should do it with pride and professionalism. Does it matter what you label it? I agree that there needs to be meetings like the Agile summit and all that to talk about practices and techniques that can help to improve coding efficiency as well as end product results as this happens with most trades and professions. New strategies are implemented and such, but work ethic and professionalism should be a given in my opinion. I guess there are folks out there that don’t know about this or maybe don’t care how their code or work looks as long as the paycheck keeps coming in, but I have found that these types usually don’t hold jobs long. Maybe I am being over critical, I just think the chapter was a bit much.

Chapter 4

This chapter is a bit better than the last, there are a lot of good points here and I feel a bit bad about condemning the book previously, but I am writing about my feeling on the book as I go and that is how I felt about chapter three. I enjoyed how he opened in the first couple of pages about the talk with his friend and his response to him after he told him how he hadn’t been promoted and how the company hadn’t sent him to seminars and such. “Who is in charge of your career?”, what a great comment and so true. I have met many people who have this attitude that the company owes them and should see how good they are and send them here and there. Well I got news for you, that is not how the world works. I hear it here at school and I too am sometimes caught up in the I wish we learned this or that and then come to my senses and realize that I have the tools to learn this stuff myself and that is how you get better.

There are many good points in this chapter. I am still in awe at how much there is out there to learn and the tech changes it seems daily. There is always something new to learn and a lot of this is new to me, not the learning part but the technology. I would have never thought about following blogs before coming back to school. I do have to work on who to follow however as there are so many out there. I am slowly finding a niche. I am slow to Twitter and social media and could use some work in that area. I am not sure why, maybe an age thing or I just haven’t tapped into its full potential yet.

The rest of the chapter is well done as well, but I am not going to go on and on, but it is, in my mind one of the most important things in this field, practice. If you aren’t practicing your craft, you lose a step. I didn’t know about katas until I read the clean coder and will one day give them a try. There is no excuse to not practice these days. The word though can throw you off though as some folks despise practice as it reminds them of the horrendous drills you had to do in sports and such. Coding practice though is much more fun as there are so many ways you can hone your skill set. Open source, katas, projects, etc. Choose something you like and it is a heck of a lot better.

Sprint 6 reflections

Well this learning reflection is going to be short as spring break got in the way and well I was lazy over the break and didn’t accomplish as much as I would have liked. I will say that this whole experience so far has been decent, but has had its challenges to me. It has taken a while to get to where we are at and when we finally got issues the semester is half over so that is kind of frustrating, but like with anything in life, things don’t always go as planned. We have been working on an issue to do with logging out while you are editing a form and it is not saving your data. The whole team has been assigned to separate parts of this and my part was to figure out the routing to use when it was all said and done. Upon looking into the issue though I cannot do the route until someone else does their part so I was kind of at a standstill in a sense. I have become more familiar with the projects code though and I happy about that. After discussing the issues we found out that we were looking at the issue wrong and were now waiting on the folks at ampath to get back to us. I will quote a team member as to what we need to work with no, “So the actual problem with the code is that the confirmation dialogue is being run asynchronously using an observable. Which means as soon as the observable is made it is being returned regardless of whether you have clicked accept or not. Which means the value that's returned by canDeactivate is neither true nor false which is what glitches out the routing. Supposedly, if you make the return value of canDeactivate, Observable<boolean> it'll wait for the returned Observable to complete before judging the activation but for some reason that's not working.”

So what initially seemed to be straight forward has proved to be a bit more challenging as we get further into the proverbial can of worms and are now trying to come up with a plan of attack at this. I like how this is unfolding though as I am learning a lot even though it doesn’t seem like we have done a whole lot we are still learning about what problems and issues can arise while tackling a bug and the process of working together as a team as well as using electronic communication and the various tools at our disposal to solve the issue. I am confident that this issue will be solved now that we have a direction to go in and I am looking forward to tackling the next challenge. We are going to be pairing up and doing some pair programming for the next issues. I have never done this in practice and am looking forward to it. I have read enough on it and it seems like a good way to do things.