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.

Chapters 1 and 2 Software Craftsman

Chapter 1

One of the first things I noticed in this chapter and it made me cringe is how people seemed to have thought back in the early 90’s in how they measured seniority by how cryptic your code was. I am sure it wasn’t everywhere but I remember people back then talking like that. How anyone ever thought that was cool or what not is another issue for another time I guess but wow memories come flooding back, not because I was a coder in the early 90’s but I knew some and hung around them and I remember hearing stuff like this. I laughed a few times as well in this chapter, especially when he was talking about adding abstractions and design patterns all over the place and how today it would be called overengineering and stupidity. It is amazing just how far we have come I guess. He hits the nail on the head though in talking about choosing your passion for work and what makes you happy. I see it in a lot of the young folks today talking about oh how much money this and that, but never hear them talking about finding something they would be happy doing. I never thought much like that, of course I would like to make a lot of money, but if I am not happy making it what’s the point?

I like his take on seniority as well and how it is transient and relative. I think too many people in general judge seniority in numbers of years and not quality of product. I have been many a place and seen people with 2 years of experience blow someone away that had 10. It is true though however that there really is no senior or junior developers unless you reference what senior or junior is as pertaining to a certain language I guess. It is interesting to see how things evolve over the years in what our responsibilities are or will be once employed. We need to be a sort of jack of all trades in the sense that we will be doing many roles as we evolve up the ladder. I am looking forward to see what the rest of the book has to offer.

Chapter 2

After reading this chapter I look at agile a new way. I never gave much thought to the name until now. The definition of agile is “able to move quickly and easily” hence the methodology being quick and short feedback loops. I think that it is awesome that these guys got together and basically changed the way we think and do. Doing things in short iterations like this makes for smooth flow in my opinion and less of a chance of failing. I love the first line of the manifesto, “Individuals and interactions over process and tools”, it is quite the revelation to me and how I like to think. It makes so much sense I wonder why it wasn’t done a long time ago. I mean if everyone is involved and working together and “communicating” it is common sense that thing should go smoother. Keeping people out of the loop on projects makes for a mess that sometimes can’t be cleaned up. He is right in saying though it doesn’t work unless there is a full transformation with everyone on board. I mean that is like anything though in my opinion, you can’t half ass stuff or you end up where you started and doing it all over again. It takes work, but I think once the work is put in and results are seen it is a no brainer I would think. The embracing of software craftsmanship is needed and I am beginning to like that term. We are craftsmen and like craftsmen we should strive to become better each day and utilizing the tools we can accomplish this.

Week 5 Reflections

Well this time around the sprint seems to be getting more comfortable as far as us working as a team and getting things done as well as discussing what needs to be done and who will be doing what and the likes. It has been a rather uneventful sprint in my opinion as we did some waiting on the folks at ampath to figure out what they wanted us to do and came up with 4 issues in the Jira board for us. That was actually pretty cool to see an issues board and to see how it operates as I am sure that when I get a job in the field I will be using something similar. We had a roll of for who would get what issue because our team and another wanted to work on the same issue. We lost and got our second choice, NGPOC-185 in which there is a concern over logging out when you are in the middle of filling out a form it doesn’t save the data you had in the form and they would like a modal to pop up asking if you would like to save or not. I have been going over ampath code as well as documentation(Angular) to learn about where the issue is and how to implement a fix.

I gained some more knowledge this time writing the login and auth modules. It was a bit of my own and a bit of looking at the code when I needed to, bu I feel more comfortable with Angular, not like super but confident I can actually do stuff with it now. I have also been going through a book on Angular 2 by Pablo Deelman called “Learning Angular 2” courtesy of ACM. It is good book so far and basically covers everything needed for Angular including testing. It should help me gain more experience with the language.

There really isn’t much more I can offer, but next sprint looks like it will keep us fairly busy as we should have the issue solved and implemented and apparently there is a list of other issues for us to tackle now so things are starting to get rolling along. Until next time….

Clean Coder Chapters 11 and 12

This is an interesting chapter. I have been in many different types of high pressure situations, some that required in the moment think on your toes stuff in the military and other just plain old the boss or company wants this and wants it yesterday type stuff, but to be honest I have never given it much thought as far as what I do in or out of crisis. I like how he keeps hammering home to not make commitments you cannot keep though, that will cause a crisis for sure. A good bit of his points are in my opinion common sense ways to avoid unneeded pressure. Keep your code clean, keep your system and design clean etc., but others I had never given thought to, especially in th crisis part where he says, “You know what you believe by observing yourself in a crisis.”, so true. Thinking back on my life and some of the situations I have been in I have thrown out the norm of doing things and switched to a whole new set of rules, but I think in some cases that needs to happen. I do agree though that in this field you should stick with what works for you in and out of crisis as there should be no need to change how you do things as long as you have a system that is efficient and clean.

 

He gives some great tips that should be lived by, don’t panic, communicate, rely on your discipline, and get help. Those are great tips and I like. I mean I guess it is easier said than done, but practicing these things outside of crisis will make you handle them better. The biggest pieces of advice I could give from this and he says also is “SLOW DOWN, COMMUNICATE, and get HELP!!”. There is nothing worth a heart attack or stress related illness over a job. Calm, cool and collective they say. Communication is huge and goes hand in hand with the get help part. Speak up, don’t be afraid to ask questions or for help, this isn’t grade school and no one is going to blow you off or laugh at you. I think the best tip is avoid pressure if you can.

The more of the book that I read the more I think it grows on me in a way. I see so much of what he has gone through in my own life and the trials I have endured. It fascinates me that no matter what industry you are in, it seems like you run into the same scenarios or strategies. I know this chapter is about collaboration and I agree with him in that working together as a team is usually better than by yourself no matter how much you think working alone may be better for you. In my opinion the more heads the better off you are to an extent. I mean of course the people on the team have to have a similar mindset and all striving towards one goal, but as long as that is the case things usually go a bit better. The team keeps itself in check and egos are hard to get in the way. I do get though that most of us computer guys and gals are geeks and don’t work well with others in a normal sort of way (whatever the definition of normal is) but we do however work together well with one another I think. Like he says though, there are of course times when it is right to work alone and that is fine, but I like his idea of it being best to collaborate with others and pair a large fraction of the time.

Week 4 Reflections

Ok so I think that I have learned a bit this sprint as a lot of things were new to me. I think the first thing is it feels like the Scrum side of things is finally rolling to where it actually makes sense to me and I can see the benefits of it now that I am putting it to use. I like how it all works and it helps to keep me organized and on track. It feels good to be putting the tools of the trade to use. Aside from the Scrum side of things I have learned a lot about Angular and the project we will be working on. I am still finding it challenging as I have never used Angular before and am really not familiar with Javascript aside from the basics and I feel like that it is making it harder for me to grasp not knowing it ahead of time. I am having to not only look up Angular stuff, but also referring to J.S. docs as well. It isn’t hindering me that much just a bit more work than I had originally thought.

I was excited to get the OpenMRS standalone running, thanks to some of the other classmates help with code that needed changing, but it was definitely a great feeling. I didn’t have much of an issue getting it up and running. The NG2-amrs build was a little more frustrating to get up and running. I spent a good deal getting help from classmates as well as the README (who would of thought that would be helpful right?) but I did get it going and did cartwheels. A bit was stupid mistakes and not taking a break when I should have, but that is part of the learning process. Come to find out, that was the easy part so far.

I am now actually into the code, well the login/auth code side of things and digging into the meat and potatoes of what we will be working on. The goal up until now was to re-write the auth/login module to get a better understanding of how Angular works and how Ng2-amrs login is working. We as a team ended up breaking the story down into smaller more manageable tasks so it wasn’t so overwhelming. Initially we had committed to re-writing the whole module on one card, but split into re-writing the HTML/CSS component first then digging into the actual auth/routing side of things. That made life a bit smoother for me. I basically copied the HTML/CSS taking note of things that I didn’t grasp, such as the Angular additions (I have a good understanding of HTML/CSS). The challenge is in the writing of the actual Angular. I had to do a lot of peaking at the original code as well bouncing back to DOCS/README/Tutorials and other help sites, but got it done. I am still far from fluent and need a lot of help I think to further my understanding, but I am persistent and have more help than I could ask for and am not afraid to ask. That is why we are here in the first place. I am still not 100% up to par on the RESTful architecture and routing but I am getting there. The more I am exposed and the more I write and do the more comfortable I am.

I guess to wrap it up for this Sprint, I have to say I am pleasantly pleased so far and look forward to what is to come and to see how my blog grows and I grow in the process. I am looking forward to learning more about the Ng2-Amrs project and collaborating with other developers via the MRS wiki and forums and digging into the issue tracker on the JIRA server (another thing I know zero about and am looking forward to learning) and just how everything fits together. It is great actually seeing the process unfold and learning new things. Until the next learning reflection blog…..

Clean Coder Chapters 9 and 10

Chapter 9: Time Management

This is a very interesting chapter as everything revolves around time and it is something that we never seem to have enough of am I right? Of course I am. I myself have been trying for years to come up with some sort of consistence as far as a schedule goes, but with my situation up until I started with college was different as I am on disability so I tried to keep to a regular schedule so I didn’t get caught in some weird time continuum while I figured out my next step. I have found it difficult to manage time while in school though and try to set a schedule, but each semester that changes and well I get out of sync. Thank goodness this is the final semester (well until grad school if I go that route) and I will hopefully be gainfully employed shortly thereafter. Anyways I suppose I should get back to the chapter at hand, time management. I found it amusing how he referred to meetings as necessary and huge time wasters because it is so true no matter what your job is. I never gave much thought about how much per person it actually costs for a meeting. There are a lot of good points in the chapter concerning meetings in general, but a lot of it is in my opinion common sense. Have and agenda and a goal. Well of course there is an agenda and a goal, I know there are a lot of times where meetings don’t seem to have either but there generally is. I really like the stand up meeting like we are suppose to do for Agile development. Twenty seconds per question, no more than a minute per person; in, out, done the way it should be in my opinion. Short, sweet, and to the point I say. No beating around the bush. I liked his quote from Kent Beck, “Any argument that can’t be settled in five minutes can’t be settled by arguing.”. Awesome words of wisdom. There are a decent amount of items in this chapter I really enjoyed, especially how he compared stuff to D & D type games, like focus manna, if you use up all your focus manna in the meeting, you’ll have none left for coding, how very true indeed.

Time Boxing and Tomatoes. I am definitely going to give this a shot. I think it is a really great idea to set a timer and let nothing interfere with your plan, actually carrying out to a tee may be a different story but still worth a shot none the less. I love it; dividing your time between tomato and non tomato time. I am actually laughing right now thinking about it, how many tomato’s did you get done today Jim?  Only 15, slacker! Over all I thought this chapter was well done and a very important, if not one of the most important things that needs to be worked out. If you can’t learn how to manage time effectively and overcome adversity when something hinders your plans, you will have a hard time getting things done and you will probably find yourself moving out of a job versus up in the job.

Chapter 10 Estimation:

I really like how he put it right out there in the first sentence. “Estimation is one of the simplest, yet most frightening activities that software professionals face. So much business value depends on it. So much of our reputations ride on it. So much of our angst and failure are caused by it. It is

the primary wedge that has been driven between business people and developers. It is the source of nearly all the distrust that rules that relationship.”

He hits the nail on the head as far as what an estimate is and how they are interpreted differently. As commitments and guesses. In reality an estimate is just a guess at when you think you will be done, however they are never set hard in stone, but the issue is that the business man hears oh it will be done by such and such date, great. I mean there really isn’t much that I have to say on this chapter other than when I give an estimate, I try and be as clear as possible and look at all the facts and take in all the information that I have and add on some extra time just in case it falls through. I also make sure that I communicate if anything isn’t going according to plan and adjust accordingly. There were a lot of great techniques he described, but I think it is something that has to be learned by doing, and by making mistakes.

Clean Coder Chapters 7 and 8

Chapter 7 Acceptance Testing

Chapter 7 hit home for me in ways unrelated to programming as a lot of stuff seems to be for me lately. It seems no matter the jobs I have done, there seems to be a lot of similarity between them. I am probably only going to hit on a few points that struck me in this chapter. The first was his co-worker wanting him to show him how to script something and Bob ended up writing the whole thing calling himself the tool while his co-worker was the sculptor who had soon lost interest or realized that what he initially wanted to do himself was actually harder than presumed. I find that this has happened to me in the past and I have been on both sides, the sculptor and the tool. I t is pretty cool to me how different areas of expertise seem to have similar issues, just different ways of solving them is all, a different tool set if you like.

His take on premature precision is spot on as well. I like how he put it it, “Business people want to know exactly what they are going to get before they authorize a project. Developers want to know exactly what they are supposed to deliver before they estimate the project. Both sides want a precision that simply cannot be achieved, and are often willing to waste a fortune trying to attain it.” That is beautiful and 100% true. Everything always looks better on paper as he says and once the final product is out there is usually some well I wasn’t really expecting this or that or I thought that it was suppose to be or do this. I do like his take on low precision requirements for estimates as that is exactly what they are estimates and to include error bars with them. I think there should be no surprises when writing up an estimate or planning out work for a customer or boss and that things should be made as clear as possible. It isn’t 100% perfect, but what is?

The Definition of Done is another good one. What exactly is done and how do you define it? I like his answer, “all code written, all tests pass, QA and the stakeholders have accepted. Done.”. That is for sure a good definition of done, but I think that done can be defined in many ways depending upon the project you are working on. It could be all steps are done for an iteration or a portion of said iteration possibly and I believe that each team or work environment should make their own definition of done with the possibility of even modifying it if need be.

I think out of all of the chapters so far this one has given me the most value as I think that a lot of this I will end up putting to practice in some way or another. Automating acceptance tests to save time is crucial and to facilitate communications between both parties and how to eliminate communication errors. It isn’t always going to work in all cases but I think there is a lot to learn here for me.

Chapter 8 Testing Strategies

I am not going to ramble on about every detail here as I think this has been covered and will continue to be covered until it is second nature I would hope anyhow. It seems like TDD is the way these days, at least for some and I agree that it is extremely, if not the most important part of the job. I understand that the code has to be written but if it doesn’t perform like it should then what good is it. I think the parts about QA should find nothing are great and that if they do it should be an extreme surprise. That means you did your job. I think or hope where ever I end up landing a job that they put a good amount of time and effort into testing. I really don’t have much experience in testing as the pyramid is laid out, I have only really done unit testing on a microscale basis, but for sure can see the benefits as you move up the pyramid. I thought the “Bug Hunt” day was a pretty cool way of testing the product as it gives everyone incentive to find bugs and ensure that the software is performing to standards.  

Week 3 reflections

This week’s learning reflections will be short as we really didn’t do much. We finished our first team sprint and had our reflections meeting as well as doing our daily scrums. I feel like I am finally getting used to the whole Scrum thing and like it and believe as a team we are utilizing it well and in the long run it will only help us get better as a team. I think that we have had positive results so far and look forward to what the future holds for us. I think we have good continuity and will learn a lot from each other and about the development process this semester.

Clean Coder Chapters 5 and 6

Clean Coder Chapters 5 and 6

Chapter 5:

I have to say that I enjoyed these two chapters, I think in part because they are on stuff that I need work with and don’t have too much experience in them, well the test driven development (TDD) anyways. I find it interesting reading about coding experience from someone who has been coding since punch cards and to see how much the skill has evolved. I used to have a Commodore 64 and was familiar with the Apple 2 machines and programming in Basic. It is awe inspiring to see how much the languages have grown and power of systems increase since then. Well back on subject and TDD. I do not have really any experience outside of some TDD examples I have done for class and reading about it, but I can see how it can be great. I think it may be hard for me to get used to as though it makes sense to me in theory, putting it to work in practice is another story. I like the 3 laws of TDD and imagine it is going to take some getting used to writing tests before writing any actual code, and sticking to it. I can see the benefits for sure. The thing that I like is that it seems to force you to write smaller parts of the whole and in the end you end up with not only a bunch of smaller modules, but you also have the tests to go along with them and the confidence that what you have will work. The other plus is that when you add code or update, you are only doing it to smaller parts of the whole so it is easier to track the bugs when something does break I would think. It is crazy that his FitNesse program takes only 90 seconds to run and has 90% test coverage with only 17 bugs in his list. That there seems to me like proof in the pudding on TDD. As I said before, this is something I will have to work on and gain confidence with and take his advice on courage. I really like the statement, “When you have a suite of tests that you trust, then you lose all fear of making changes.” For now, I will just work on following the three laws of TDD.

Chapter 6:

This chapter’s subject in my opinion is so very important, practicing. He hits the nail on the head here. You can’t better if you aren’t practicing your art. I certainly need more of it and don’t do enough, but I am working on it and I plan on using some of the techniques in this chapter to help with that. I enjoyed how he puts it together with martial arts terms. I will be working on the Katas that he linked and other items. I don’t really think that I can write a whole lot about practicing as I think it speaks for itself. Without practice you get stale and lose your touch. I really like some of his ideas on picking a new language to practice with and finding an open source project to work with. I believe that all of these ideas will help to make me a better programmer as long as I put them to work and keep up what I have been doing. I am passionate about this and sometimes feel like I am behind the curve, but I just keep plugging away and learning more every day.

Week 2 Reflections

Reflections on Week 2

This week was actually pretty good for me. I think that our team works well together and that it is going to be a productive semester. This week I was able to get my accounts set up with OpenMRS and trello and learned a bit about Scrum and finally started to put it to use. I like it because I am finally putting everything that I have been learning so far to use or will be. Aside from getting the basics set up we are going to be using Angular this semester and I have never used it before. I am familiar to some extent with Javascript but I feel that I have so much more to learn with Angular even though it is based on JS.

I went through the Angular Tour of Heroes tutorial here and I have to say that though I enjoyed it, I am still a bit foggy and will be going back through it and doing another tutorial I have found. I am fairly comfortable with a lot of it, but when it came to routing and navigation I felt a little lost so I am going through some more on that area. I really like how the framework actually works though and think that it is going to be a great experience this semester and hope to be proficient with it as I hope to get into Web Development of some sort and I know that this is used a lot. It doesn’t really take a lot to get an app off the ground running, but digging deeper is going to be fun. I really like how it is easy to split your app off into multiple modules or components as your project gets bigger. I am confident that it will all come together though and I will be proficient before I know it.

I am looking forward to what this week brings and what new challenges are ahead of me. I am taking everything as it comes in and trying not to put too much on my plate and so far I have been able to do that. 

The Clean Coder Chapters 3 and 4

The Clean Coder Chapters 3 & 4

Chapter 3:

I had favorable things to say about the first two chapters because they kind of reminded me that no matter where you work or shall I say I have worked, a lot of it rings true but it is also to me just common sense. I mean saying no and saying yes? I feel like a bit too much is dedicated to this and it gets old real fast and I want to skip on but I pushed through chapter 3 and well once again I have to say it is really to me a lot of common sense things. I guess I shouldn’t say common sense, but for me I learned a lot of this by trial and error and promising things to people that I knew I couldn’t get done but just wanted to please so and so and felt that I would just deal with the blow back later. You can only do that sort of thing so many times (for me once or twice was enough) before you catch on and realize not to promise things that you can’t deliver and to commit to things that you’ll do when you say you will. I guess the book does a decent job at laying out situations and the outcomes so hopefully people won’t make the same mistakes that Bob made. I feel though that I have lived through all of the scenarios in some way or another so I guess I got a chuckle out of it. He says that the language of commitment can sound scary and it can help solve a lot of the communications problems facing coders. He is absolutely right but it definitely takes time to learn how to do it and be taken serious about it. You have to build trust and being straight about things is the best way to do it.

Chapter 4:

I feel that this chapter is also about experience and a bit of sense. This is all life stuff and applies to any form of work in my opinion. He talks about preparedness and how coding is intellectually challenging and how if you aren’t prepared for it your work will suffer. I find that this seems like my dad is preaching at me when I was 16. I mean of course your work is going to suffer when you can’t concentrate or when you are tired. The worst code written at 3am, I have been there and don’t do that anymore because I have learned the hard way and the good ole flow zone where you think you are actually doing an awesome job reminds of the people who say they do their best work high or drunk. Sorry it just doesn’t work like that as like he said, yes you may get a lot done, but what did you miss? I am sorry but I guess I am kind of disappointed with the first few chapters. I was good with the first two at first but the next two to me seem to be more of the same lessons just in a different context and I can’t write anymore about them. It does however seem like the rest of the book will be decent to me. I thought his other book ( Clean Code) was good so I figured that this would be more of the same and I hope the rest is.

The Clean Coder Chapters 1 & 2 and Week 1

The Clean Coder, Chapters 1 & 2

After reading the first 2 chapters I felt like I had read my own experiences over the past twenty something years. I wasn’t a programmer or in anything to do with computers, but the more I read and learn about this field the more I find that even though I was doing something different, a lot of the same issues happen no matter where you are.

In the first chapter on professionalism he talks about how it is easier to be a nonprofessional because they don’t have to take responsibility for the job they do. That got me to thinking about the term. No matter what job or jobs I have had I always tried to do them as a professional. I think the term work ethic could be used to describe professionalism as well. You get out what you put in. I felt like I had been in similar situations as I read the chapter. He seemed to go through something everyone must go through at some point in life. I enjoyed how he learned from his errors and passed wisdom on. The lessons learned from releasing the product without properly testing and it went south. This was all to save face and look good because it went out on time, but then the backfire. Though you think you are saving time, in the end you lose time and man hours when if it had of been done right the first time a lot could be prevented.

I like his take on the do no harm function as well. We can’t be perfect, but we must be responsible for our imperfections and should always be trying to get our error rate approaching zero and expect QA to find nothing wrong. If that is the thought process you should genuinely be surprised when they do find a flaw. I have been in the situation where I half assed something to get it done on time and was not surprised in the least when it failed. Wasted time and hours when I should have just done it right the first time.

I really felt like his work ethic and knowing your field hit the nail on the head as well. They gave me something to try and think about. I like the time breakdown. It humbled me actually when he was talking about the first 40 are for the employer and 20 aside for me. I had never thought of it that way and it humbled me. He set up some very realistic ideas on how to utilize time. As far as knowing the field, I feel like I have a lot to do. I know I am just getting started, but I didn’t realize just how much there is to just know for the basics. I picked up a copy of the gang of four design patterns books to increase my learning on that end and plan on just plucking away each day to increase my chops.

Overall I gained a great deal from chapter one and plan on reading it again. I wish I had come across this sooner.

Chapter 2 and saying no brought back many memories as well. I think a lot of people in general have issues with saying no and want to just get along and cause no waves. I am one of those, well was. I do not like to say no because it is uncomfortable for sure, but that was because of the way that I said no. I usually offended someone because I didn’t think before I spoke. I have changed. He makes some great points on how to and not to approach situations. His role playing scenarios were ones I have been a part of myself to some degree. I was one of those people that used to say I’ll try and had never thought boss would think of that as a yes I can get it done on time. It makes sense though because I’ll try is like beating around the bush.  Overall there were a lot of good points that can be used no matter where or what job you are doing. I am sure that once I get into the field that I will be practicing my version of saying no and this book will come to mind.

Week 1 learning

I am still trying to process everything that I have gone over this week and am still in the process of going over it. The first couple weeks of the semester are the hardest for me. I try to make a schedule of my time so I can manage everything. I am excited for this one though as it is my last undergrad semester and a long time coming. I have been going through some Angular 2 tutorials to get a grasp on how it works, and using the node package manager and other tools. I think it is going to be a lot of fun to learn and use and I hope to become proficient with it.

The Open MRS project is overwhelming to me so far, but that is I guess because I am just getting into what it is all about. I tried the demo and like the functionality and can’t wait to get my hands dirty. I think it is great that so many folks are collaborating on this records system that can help so many people around the globe. I am eager to get started in this journey and hope that whatever we do this semester has an impact in the years to come. I know I am going to have a lot of challenges, but I welcome them with open arms.

New post for Software Dev Capstone

This is my up and running post for this semesters software development capstone class. I look forward to a great semester and some good blogs and a lot of learning and put everything we learned together.