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.