This will be the final sprint retrospective for our Capstone Project where I give a general reflection on what occurred this previous sprint. This previous sprint was perhaps the most extensive one we encountered. We completed the component and wrapped up our presentation for the class. On the component we figured out what to finish with and finish strong with it. Everything was stylized to what we thought right to be. Our buttons were working previously but the submit from the last sprint wasn’t. after much discussion on what we wanted and how to approach the situation we figured it out. For the button we used a service for it, James came up with this idea. We also found something of it on google after some searching that was perfect for what we needed. All in all the button/submit button wasn’t to hard of a task for our team to conquer. Finalizing the presentation was not something to difficult, we all had our sections to cover. In short this semester was my team was a good one, we got a good amount done and got more familiar with all the components used.
Draw Your Own Map
For this weeks blog post I will be discussing the pattern known as Draw You Own Map. The context behind this one is that any given employer can offer only a limited subset of all possible career paths. The problem that would arise from this is that none of the career paths your employer provides actually fits you. The solution that would come from this situation would be to simply identify the next logical but ambitious next step in your career. Realize that it is not up to your employer, your career counselor or your professors to give you a hand up or decide your fate. Arriving at the next step and charting the course is a decision that ultimately comes down to your responsibility. You need to take the first step that is the most important part, even if that step doesn’t seem to significant. This first step should generate the momentum needed to help carry you toward your goal, no matter the terror you may feel. Try to define small, yet achievable steps allowing feedback that you can use to modify your road map which could also make it easier to get help from Kindred Spirits to achieve said goals. If the vision of which your employer sees of you and the one you see of yourself do not match your preferred accordance examine the opportunities to see if they’re heading in the desired direction. Instead follow other successful apprentice paths that share a resemblance to what you are going through. You should constantly reassess your map as your circumstances and values change. Sometimes the map will be in accordance with that of those around you, other times the map will require you to chart your own path through the wilderness. The only constant is that the map is yours, and you are free to redraw it at any time. A good action to take with this is that you could list three jobs that you think you could do while following the current one. Then begin to list three jobs each of those would lead to. Are these really the full range of desirable jobs for the next few years of your life? Ask yourself if this set of jobs is more representative of the range of career options you have before you and what places you want to take in this career. If you are unhappy with the list so far, repeating the exercise with different jobs, business or technology domains could help. Then repeat the exercise again to see where you would end up. Yet again this is something anyone who catches themselves in should do, as it will help you in the long run and in general.
Use Your Title
For this weeks blog post I will be looking into he Use Your Title pattern. The context behind this one is that as a result of your dedication to learning, you’ve been hired or promoted into a position with a title containing the words senior, architect or lead. The problem that will arise from this is that the job title doesn’t actually match what you see in the mirror. When you introduce yourself into this new setting you feel as if you have to apologize or explain the difference between your skill level in your actual job description. A solution to this is that you shouldn’t allow the title to actually affect you. Its just a distraction that should be kept on the outskirts of your active conscious. Use the title only to gauge your organization not yourself. Don’t get fooled by a fancy title, your mother might think you deserve it but the impressive title and responsibilities mean your apprenticeship is over. They serve only to remind you that there is a shortage of craftsmen in the industry. While on the other side of this coin is an unimpressive title despite the fact that you may have surpassed your colleagues. The frustration that comes from a lack of recognition should remind you that the industry has a problem. Using this as a measurement of your own organization and fitting it rather than allowing the frustration to bog you down. Another variant that comes from this theme is the informal versus formal titles. For example you may have grown into a position of authority on your own team despite the formal title remaining. These informal titles can be hard to actually ignore, because they are constantly reinforced by peers and colleagues. These titles remain even if they conflict with your own self assessment, keeping with your mentors and kindred spirits will be critical to keeping you grounded in reality. The recommended action to all of this is simply write down a long and descriptive version of your job title. Making sure it accurately reflects what you really do at work and your skill level. This is again another pattern that I agree with and can see myself using in the future.
Sprint RetroSpective 5
This sprint was much more productive since last in my opinion. First throughout the sprint we kept running into simple errors. One error I had several times was my angular not being recognized for some reason but then a clean reinstallation fixed this. This happened to Harry just a few days ago which has been resolved. After the angular problems we had some connection issues to see the component on the local host site. James was the first one to run into this while me and Gulshan where on the other component branch fine. We were using another groups component “Tabs” for reference to see if our repositories were set. After a day or two issues were resolved. Just yesterday we ran into yet more problems on this issue, this time on our own Q-Form branch component. Firstly, Harry couldn’t see the Q-From branch or rather the deletion of the Questionnaire Form branch to the new formed Q-Form branch. Then James was having an error that I don’t even know what he did wrong. After that was resolved we finally got our component branch working. Now all we have to do is just add our stuff in and structure it how we want and we should be good. After this component we should have time to do more components if we do not run into similar errors.
Confront Your Ignorance
For this weeks blog pattern post I will be looking into the pattern known as confronting your ignorance. The context behind this one is that you have identified the gaps within your skillset that are thereby relevant in your everyday work. The problem that will arise from this is that the tools and techniques needed to master seem unobtainable as you don’t know where to begin. These may already be around you with people around you doing them but there is an expectation you already have this knowledge. The remedy to this that you should pick one skill, tool, or technique and seek to fill the gaps of your knowledge about it. Finding out the most effective ways that suit your style. For some the best approach involves getting an overview of introductory articles and FAQs. While others may find jumping straight into the construction of Breakable Toys the best approach to understanding something. Whichever approach works do not forget to ask around your Kindred Spirits and mentors to see if someone already has the skill and if they will be willing to share their knowledge. Others may be actively seeking this skill as well which can allow you both to work towards this goal. There aren’t enough hours in a day to hone all your skills to a high level, so making necessary trade offs between them is something that will have to happen. This pattern is closely related to Expose Your Ignorance, but implementing it is a less difficult task to your pride since it can be down privately. But eventually you may have to Expose your Ignorance as well, since learning in public will allow an apprentice to being their transition to a journeyman. Taking the list of items from Exposing your Ignorance and striving to learn each one, while crossing the completed off is a good place to start. This way you can see gaps you maybe hadn’t noticed before. This pattern is important to say the least, one that most people should honestly follow if they need to.
For this weeks Blog Post I will discussing the pattern known as “Sustainable Motivations”. The Sustainable Motivation pattern is almost what it sounds like, where you require motivation to keep going. Anyone who knows programming knows that if a programmer is given the chance to do it there way, that is there biggest motivation. The context behind this is that you must develop your technical skills because of this you will find yourself working in a messy reality of specified projects for customers with different demands. The problem that arises is that when working in the real world trenches of projects you will find rigorous, tedious, exhausting, frustrating and constraining effects. The solution to this is that you need to ensure your motivations for craftsmanship will be able to adapt and survive through the Long Road ‘s (pattern) trials. For the most part there will be days and more that you love your job, getting paid to develop software and such. Where the work will just come natural to you without much effort. These days wont be ordinary days, because most programming jobs you will face tedious, vague definitions, and overly complex problems. You could even face some spotty leadership problems, difficult coworker personalities and other troubles. Because of this you may begin to question your commitment to the craft. When faced with these problems its almost imperative that you are aligned with the Long Road. Some examples could include you hating your programming job and are only motivated by the money. Where you value climbing the corporate ladder over honing the skills of your craft. But also are motivated by your reputation as a technologist, allowing you to survive and endure to the sun shines once more in your job. Another example could be you are motivated by your enjoyment of actual programming, where you then come up on a length of time where you cant find the love. But you are motivated by the money, and that programming is financially the best option right now, causing you to be motivated. All of these are good examples of how to be motivated but the best way to figure out yourself is to write down some motivations for you. Keeping this list somewhere safe where you can come upon it when times get tough. This pattern is something 96% of people can relate to, in almost any motivational situation and one I will see myself using down the road.
Sprint RetroSpective 4
This past sprint flew by in all honestly, seems like last week we just started. This sprint we accomplished a few goals we set out to do. Our main goal/issues to solve were the branching situation and what our exact task was. Next was setting up pull requests for our user stories correctly. Took us a little bit but I think we got it situated at the moment. With only some angular issues popping up here or there but nothing we couldn’t solve. Harry has set up a few wire frames over the past few weeks, even if they weren’t stuff we were working on giving a better idea on what we were working on. For the coming Sprint we are reaching the Endgame time period, where we are going to have to actually power through as a team and accomplish our goals. I have faith in my team, as when it comes to brass tacts we all can pull through. Essentially I am looking forward to once again setting forth with my team and accomplish our goals.
Studying the Classics
For this weeks Blog Post I will be looking into the pattern known as “Study the Classics” where one is but to study the classics. The context behind this one is that you are self-taught or valued skill training over theory. The problem that would arise from this could be experienced people collaborating with you are constantly referencing concepts that they have assumed you read. But since you are value practice over theory you may have skipped over this reading/research. This will of course cause some problems, perhaps nothing serious but will lead to some confusion between the two parties. A solution to this is go back and study the classics if you will. If you were to pick up a book and think how old or out of date this book is, then you are probably reading the wrong kind of book. Successful apprentices will tend to focus on long lived books (classics) and use the internet or through practice to see how the information has evolved exactly. A classic they give in the excerpt is “The Psychology of Computer Programming” while this is “dated” wit h its punch cards and room sized computer parts the book was non the less relevant with is wisdom. Classics portray vital information to keep you heading in the right direction down on the Long Road, another apprenticeship pattern. By just focusing on classics you may take it to far and abandon more pragmatic knowledge and information that would enable you to improve your day to day craftsmanship. A simple remedy to this is to just mix the classics with modern, pragmatic books and/ or articles to your reading list. A way for this to act is simply pick up the oldest book in your pile. Or if you are looking through another developers book, take not of the oldest books and ask them why they still own them, sparking a conversation relevant to its wisdom it gave. Overall this is something I see myself doing down the road.
Sweep the Floor
For this weeks blog post I will be discussing the pattern known as “Sweep the Floor”. Sweeping the Floor is about you starting from the bottom and then getting into the more complex tasks. This being you contributing to simpler tasks, learning from these and becoming more skilled then graduating into larger more complex tasks. Imagine you are an new apprentice on a project, unsure where you stand compared to others on the team and they are unsure about you as well. You want to earn your place on this team, contributing where you can, gaining their trust and growing in the craft essentially. To do this you could simply volunteer for something simple that is necessary to complete. This is a good starting way to contribute to a foreign team and to the teams success early on by showing you can do high quality jobs even for simple matters. Skimping on quality here could lead to trouble later on when it turns out later that this part is actually very important. Some various examples of these tasks include maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, setting up a project wiki and so forth. Basically you would be focusing on the edges of the system where less risk lies rather than the heart of the project where the stress and complexity would be. But this of course could prove tougher to swallow if you have spent a lot of time and money in a computer science degree. The moment leading up to your career in theory has been doing all of the said above tasks almost just without pay. Another negative aspect of this would be you ending up as the teams gopher, condemned to do menial tasks no else wants to do. You may find yourself intimidated by doing anything other than sweeping the floor, feeling only comfortable doing this. There is also danger in that you may not be able to develop appreciation for bigger projects due to the smaller menial tasks you are accustomed to. In short finding the tasks nobody wants to do or complains about and creatively resolving these problems in ways that exceed peoples expectations will allow you to slowly soar above, something that most including myself can get behind.
Sprint Retrospective 3
This past sprint not much has progressed since the last sprint in all honesty. Since the last sprint we were given a few new details onto what we are going to be doing exactly for this project. We discussed the matters as a team going into some of the files, we were originally given from the ngl-2 repo. As the sprint went on we talked about what are task should be. We had ideas of what we wanted to pick for our team role. But never really solidified our decision only verbally talking about what we wanted. We know what needs to be done or rather what the final product should be looking like. So now we will begin to start actual work on the project it would seem. With each team working on different problems like setting up a mock server and so forth. In short not much has really changed since last sprint retrospective but I personally feel we are a step closer in the right direction than previously. I am looking forward to working on this project with my team as we get closer to an end product.