Author Archives: nbhc24

Sweep The Floor

As a new apprentice and low man on the totem pole you should be ready and willing to do the small unglamorous, but necessary jobs that need to be done on a daily basis.  You need to swallow some of the pride and ego that you may have developed while solving assignments in College and realize that you need to start from the bottom again and that you need to adhere to the team dynamic that you are joining, they already have a working relationship and have already built up trust with each other that they don’t have with you yet.

While this is just an analogy sometimes it is a literal translation, much like it does in the book.  When I was in high school I worked in a woodworking mill making hardwood flooring and wood trim and molding.  So there was always a lot of sawdust and dirt flying around.  Whenever we were swapping out stacks of wood to make more, or changing blades someone was expected to sweep and clean the tables of wood chips.  This wasn’t a glamorous job and no one wanted to start sweeping in the little bit of time that we had to rest in between handling and stacking wood flooring, but it was necessary in order to keep an organized work area.  As both the youngest and newest guy that responsibility usually fell on me.  While most of the time, especially at the beginning, I hated doing it instead of being able to take a full break as time went on it helped integrate me into the team.  I started getting the respect of the other employees and the boss because I had shown that I was there to work and wouldn’t make others pick up my slack.

That helped me form the belief that whenever you go somewhere new, whether it is in a new field or just a transfer to a new location that you should keep your head down and focus mainly on doing your job.  This isn’t to say you shouldn’t socialize and make friends, but you shouldn’t get too relaxed that you fall into some of the bad habits that other team members may have developed and then you start you off on a bad foot.  Be ready to be assigned the worst tasks that the team gets because they still need to be completed, and do them to the best of your ability; even if it is something a tiny as updating or proofreading some documentation.  Some may not seem like it’s going to change the world, but it needs to be done and your quality of work will show through no matter the task.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

Overall I feel that this sprint could have gone better, but as a silver lining, it gave us an opportunity to see what we need to improve on moving forward.  Luckily this happened early on in the project and wasn’t an issue that went unnoticed until the semester was almost over.  The important part is to reflect on the faults of this sprint in order to improve and avoid the same mistakes moving forward.  I do believe that we did start to come together as a team and work well together.  I feel that everyone on the team is willing to listen to everyone else’s opinions without passing judgment or shutting each other down even when disagreeing.

One important piece that we did not do is documenting.  We should have documented what we figured out to help us navigate what we were learning.  Looking forward I plan on taking personal notes recapping the team meetings just to keep a personal track on what we talk about.  I feel that we also need to encourage each other to start documenting what we find when working outside of team meetings, or even what we may come up with during the class time.  This will help reinforce what we learn and also allow us to more effectively share it with the rest of the team.

Another problem area was assigning tasks.  There’s an old saying that I learned years ago that if a job is assigned to everyone than it is assigned to no one.  Meaning that if it is kept general and said that “this is a team task” without specifying a role for every member, even if it is explicit for each member to complete the same task, then there is a strong chance that no one will do it and expect a different team member to do it.  There needs to be direct ownership of tasks to ensure they at least get worked on.  When there is no ownership that also means that no one can be held accountable for failing to do it.

The sprint wasn’t a complete failure though.  We read through the user stories to get a better understanding of what was going to be expected of us.  This also helped start team discussions as to which service and task we wanted to take on for the majority of the semester.  This also helped get us started on mapping out the program and services that the class will be working on improving.  We started to look at the ng2-amrs code both on our own and during the last few class periods.  We started to look at where we login to the site and walked through the code starting from the login to try and map out how the program runs and works with the REST API.  Again this would have been better to write some kind of documentation to reinforce our understanding of this mapping.

While not the most successful sprint I do believe that it was productive from the point that we learned what not to do moving forward.  My hope is that we can build on our failures and become more successful for the rest of the semester.  While it’s important not to dismiss this sprint entirely we can’t let it bring us down and lower the team’s morale.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

Craft Over Art

“Craft Over Art” is a pretty straight forward apprenticeship pattern that is easy for many to overlook.  At its foundation it means that you’re program and code can look elegant, but the main focus should be that it is useful.  You can’t get too caught up in the elegant design of your code that you sacrifice functionality.  This can be a difficult balance to find though because programming is something that you need to present to a customer and if there is no beauty at all then the customer won’t want to accept the project as meeting specifications.  The pattern also raises a strong point that if the software breaks it may be better to make a quick repair that solves the problem that may not look nice, but it gets the program up and running again.  We should see ourselves as craftsmen that need to make something work as the main priority, the same as an electrician for example.

A friend of mine is an apprentice electrician and this pattern reminds me of a conversation that we had.  He was describing an electrical panel that he had to wire.  He was excited with how neatly and organized it came out.  While our conversation didn’t specifically get into the topic of functionality it was a simple panel and the functionality was implied.  As a craftman the functionality of his project was so fundamental that it was not even thought about to mention.  The fact that he  completed it means that it met its functionality goal.  The emphasis was on the beauty that was achieved.  He put craft over art and since the art was optional and a preferred goal, but not required, that was the bragging point.  Because it was above and beyond the standard.

After thinking on this post I hope to move forward with this in mind not only for programming, but in most of the things that I do.  The baseline for success in programming should be two simple questions; “is it functional?” and “does it solve the original issue?”  If you’re able to answer yes to both of these questions then we can start working on the artistry and beautification of the code.  While a certain level of beauty may be important to the client I feel like if it is not functional than no amount of beauty or elegance will fix that.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

Find Mentors

It’s important to realize that the path you are taking (it doesn’t matter what path that is) has more than likely been traveled before, or at the very least where you stand at the beginning of your career is where many have stood before you.  There is no need to reinvent the wheel and learn all the ins and outs while trying to determine and travel your career path without guidance.  There is an abundance of craftsmen with a career full of information out there, whether it is your boss, a senior team member, or just someone in the field that you look up to.  What is important is that you seek them out and develop an open dialog back and forth with them so you can prosper in whatever you decide to do.  Ideally you want to find a master craftsman that has walked a good distance along the path and not someone who is only a few steps in front of you.  While you should still develop a relationship with the person in front of you, and is the basis of other apprenticeship patterns, it is not as a mentor and not the topic of this post.  Your mentor should also be ready and willing to accept the responsibility of taking on an apprentice.  It is a very fulfilling and very important relationship to develop in your career and will benefit you greatly to learn from their experience and grow as a developer.  Remember though that your mentor does not know everything though and is not infallible.  There should be a respectful, open, back and forth communication between both of you.  A communication designed not just to receive directions and blindly follow them to build your career, but one where you can ask why they made those choices in their own career or why they are recommending this course of action to you.  One that is strong enough not to crumble if you take in your mentor’s advice and in the end still decide not to follow it, but to take a different route that they may not agree with but still respect your choice.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

This was our first sprint as a team and was anything but normal.  I would like to say that I believe that having a sprint where the main objective to set up our personal and team environments was a great starting point.  It allowed everyone on the team to help each other get ready for the project and not feel like we had to rush.  It also gave us to sit together as a team and go through the same steps that we will in future sprints.  There was definitely a lot of experience to gain with very little risk if we did not complete the sprint the correct way.  That’s not to say there was no risk, because if we did not set up our environment or study Angular we will be in trouble next sprint.  We did not start contributing to the project though so it was less stressful than a trial by fire and risk falling behind at the beginning of the project and put the team in a bad mood and kill morale for the rest of the semester.  The other side of this sprint though was that most of the activities were personal and did not contribute to a group whole at the end of the sprint so for times in the middle of the sprint it was hard to be able to talk during the working classes to the rest of the team about our progress and work as a team.  I am fully aware though that that will not be the case moving forward though and even though we will be working individually I think since they will be pieces of a whole it will be easier to collaborate during class and reach out when we run into roadblocks.

This made the rating difficult for the first sprint as well.  It quickly became hard to rate the rest of the team on their contributions to the team during the sprint when there was not much of a team effort needed, with the main exception being if someone needed assistance setting up the environment or asked a specific question on one of the user stories.

I feel like this sprint got our team ready to go though and I look forward to helping improve this application throughout the semester and working with my team.  We are set up in a good place and we have a solid foundation to start working on our portion of this project.  I also like that we will be working on a real world application that we can put on our resume, but also one that is doing good throughout the world and be able to point to it in the future and say “I helped make that better.”  I’ve talked to a few people about it, but I think that as a whole everyone is excited to start working on this application and feel that even though we are on separate teams we are all willing to help other teams.  This really has the feeling of a project that is bigger than us and no one is competing against anyone else the way that some may feel if we were all completing the same assignment or taking tests.  We are all taking on this task together and ready to do it to the best of our ability.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

Draw Your Own Map

A very important apprenticeship pattern to keep in mind is Draw Your Own Map.  The pattern discussing the importance of planning out the next steps that you need to take in your career.  It is important to talk to your bosses and others that have been in the field longer than you about the direction that you need to take to advance your career, but it is important to note that while you should listen to what they have to say and take it into consideration do not blindly heed their advice.  When you do this, you are no longer in control of where your career and to a degree where your life is headed.  You need to sort through all the advice you are given and decide if it is in your best interest to follow said advice. One thing that I have always believed in and kept in mind when following advice of others or handing out advice of my own is that it is very easy for someone else to tell you what you should do because they don’t have to wake up and deal with it tomorrow.  By this I mean that ultimately the path you choose and decisions you make will impact your day to day life, career, and happiness.  Most of the time while your advisor may care what happens and worry about if you will succeed they don’t have to feel the pressure of what happens or the negative or even positive consequences from that decision.  You need to remain in control of your own life and career.  The best way to do this is to draw an actual diagram of where you want your career to head and what you need to do to get from point a to point b.  Life isn’t that simple though and things change so it’s important to constantly examine the map to see if you are on the right track.  If not see what you need to do to get back on track, or maybe things changed and you want to take a new direction either from a new-found interest or responsibility change in your life and then it’s time to redraw your map to have a plan of your next steps.  No one else is going to do it for you or care as much about the success of your career as you.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

Unleash Your Enthusiasm

Unleashing your enthusiasm focuses on bringing enthusiasm to your new team.  It emphasizes approaching your new team with energy and readiness to learn as much as possible.  The book explains that a lot of new developers may be hesitant to appear too enthusiastic, thinking that the team that they are integrating into might not be welcoming to the new injection of enthusiasm into their work place.  Enthusiasm is infectious though and in just a short period your enthusiasm to work and learn will spread to the other team members and the overall work environment will rise.  I agree that this works not only in software development, but in any industry.  During my time in the Army there were plenty of days that were miserable at best.  No matter what the condition was though if you had a positive energy and enthusiasm it made the day a little easier.  When one person showed up with this type of attitude they were quickly berated and rejected by those who were determined to stay miserable.  Soon enough though the positive attitude spread to others and everyone had seemingly found what little good and joy there was to find that day.  Work then seemed easier and the day moved quicker.  No one could tell you any specific time or event that the change occurred.  The tone of the team just kind of changed as the enthusiasm spread.  I think that a high morale and enthusiasm for the job will greatly improve the overall morale and performance of the team.  I found the study from the aircraft carrier interesting.  The idea that new employees mixed with seasoned vets of the industry makes sense, but is often overlooked until it is brought up.  The vets share their experience with the new employees while the new employees are able to share the newer ways of teaching and question the way things have been done in order to change procedures if necessary.  When the employee is in the middle of these two extremes is where changes are made and new procedures and policies replace the old.  It’s important to for all to remember that this process doesn’t work without a mutual respect and open mindedness towards all.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

All About Apprenticeship Patterns

I read through Chapter 1 of Apprenticeship Patterns a few times and really like the approach of seeing software craftsmanship in different levels.  When I think about it I guess that I’ve always thought of software development as either able to do it or not and getting better at it as you practice.  I like the idea of seeing it as being an apprentice, a journeyman, and a master.  It puts software craftsmanship in the same boat as other skills and trades.  It makes it sound like something that is more attainable to more people who are willing to practice at it.  Many times in just the past three and a half years of school when I tell people that I am majoring in computer science quickly say that they could never do that.  The truth is they could if they wanted to and practiced at it.  It is a skill/trade like plumbing or car maintenance.  You may not know anything now, but if you went to school for it or took the time to learn on your own you will grow your toolkit.  Seeing it as three levels is nice and makes it seem like less of a constant climb, it still is because the field is always changing, but when you reach the next level it is a little accomplishment rather than a constant climb with no specific advancement.  As the book says though that the definitions of apprentice, journeyman, and master are not the same as you would find in a dictionary.  For other trades there are unions set up and standards set in place that dictate when someone moves from apprentice to journeyman and journeyman to master.  There is no such set up for software development.  That would be an interesting development in the field if there was a governing body of some type and software developers created a union type set up.  I don’t believe that it will happen though as it is a new skill/trade and not seem the same as a plumber or an electrician.  For software developers it will be a more gradual and seamless transition rather than taking a test or working in the field for a certain number of hours.  As a portfolio grows and more skills are learned a developer will start to either search for a job at a higher level or start taking on more responsibilities at their current company.  Then without realizing they will be in the role of a journeyman and have a few apprentices that they will be around and either intentionally or unintentionally inspiring them and helping to shape their careers.  Then years later after working on many projects and taking leads they will make another gradual transition to become a master of their craft.  These won’t be as pronounced as your more traditional skills and trades.  I don’t think that it will change anytime soon because it is viewed differently than physical trades.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

Intro Post for CS-448

My name is Timothy Kmiec, I am a senior at Worcester State University and this will be my blog site during Spring 2018 semester for CS-448.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

Agile Testing Can Make or Break The Business

A recent blog post from Cigniti discusses the importance that Agile Testing has in enterprises (http://www.cigniti.com/blog/agile-testing-really-helpful-enterprises-stay-innovative-competent/).  The post does not argue whether or not Agile Testing is essential for enterprises, but instead discusses why it is essential for enterprises to employ this method of testing in it’s daily operations.   It is becoming increasingly clear that their are many benefits to incorporating Agile Testing in their enterprise.  Enterprises need to be flexible and able to change in order to stay competitive and try to keep an edge over rivals.  One of the biggest and most obvious advantages of Agile Testing is the flexibility it provides to not only the testing team, but all teams involved.  The short sprints that Agile Testing provides allows companies to adjust their goals quickly and easily if the customer or the development teams changes their desired outcomes.  This is essential to businesses that want to maintain an advantage over other companies and stay attractive to clients.  Agile Testing also helps improve the overall customer experience.  The flexibility and constant ability for change helps a business adjust to a customer’s inevitable desire to change their minds on what they want from their product.  Agile Testing also helps the testing team and development team communicate more and relay information back and forth to work with each other rather than against each other.  While there is always risks in producing a product Agile Testing greatly cuts down on these risks.  Being able to stay in constant conversation and working in sprints it allows teams to catch and resolve issues as they arise.  Companies can then adjust time frames as well as end user products in a timely manner rather than waiting until closer to the release date and having to push the launch back completely or risk losing the contract with the customer.  These all boil down to communication between all teams involved on the project.  Without proper communication Agile Testing falls apart and loses much of its efficiency.  It’s important to realize that the completion of a quality product that satisfies the customer’s needs is more important than the pride of any individual or team involved.  Programmers should be ready and willing to bring up any issues or faults that are found as well as be receptive to any constructive criticism from other team members.  This allows Agile Testing to work effectively and efficiently throughout the entire development process.

 

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.