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.
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.
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. Most of the time while your mentor may care what happens and worry about if you will succeed they don’t feel the same pressure of what happens or the negative or even positive consequences from that decision. In the Army it is all about progressing and moving forward in your career. My mentor was always pushing for me and others to take more professional development classes, physical fitness, and marksmanship that all play a part in promotions and moving to the next level. I didn’t put in as much thought or personal planning into this process that I wish that I had and kind of just went along with the flow. While I still moved forward, I missed a lot of opportunities that were available to me because of that and I intend to fix that in the next chapter of my life.
This is my last semester and while I have already started to submit applications there is another process that I only half thought of until reading up on this pattern and ingrained even more on this second edition of this post. I am going to sit down and physically draw some type of diagram or timeline, whichever seems to make more sense to me after I start, to map out immediate (~1-2 yrs), short term(~5-10 yrs), and long term goals(>10 yrs) and check points of what I want out of life moving forward.
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.
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.
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.
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.