Pattern Overview :
I believe this was a very short pattern but its content did not disappoint at all. It brought light to a few apprenticeship concepts that are needed in order for one to be called a master. Usually, developers are often self taught since the practice is so highly technical, they tend to gain hands on training instead of the theoretical concepts. When this is the case, you as the developer misses out of the fundamental theory and structure of programming.
Understanding the theory behind the practical actions gives you knowledge and proper understanding of how things are suppose to work. It also introduces you to acceptable and common practices in the field of development. Successful apprentices in the field spend time reading and understanding concepts from old software books.
I truly believe and agree with the author concerning this topic. I know that reading not only keeps the mind busy but also explains how things are done and acquired. So the author advices to stick to classics since they provide and hold the most knowledge. The Knowledge and understanding that is founds in these classics provide vital information that guides and keeps up coming developers informed. With this being addressed, the author again addressed a con of this practice. He believed that reading old classics would cause one to be stuck in the old ways and forgot about new and upcoming technology. I think this is invalid because i believe instead keeping you obsolete, the idea origins and knowledge get passed to you and you are in some way given a a head start on combining the old up with new modifications and designs. Once again fully understanding the methods and practices if the classics heightens your understanding of the craft and gives you the ability to build upon what you have read.
Reading in it self is a great practice that keeps us alert and informed but reading about development introduces you to new arenas that had not yet being discovered yet. Long Lived books in the industry are often written by developers who take a lot of pride and pleasure in their ling of works and do not hesitate should an opportunity come up.
Once again, i think we had a successful sprint this round. Once again we increased team communications and continued to form better team bonds. This is specifically because this sprints task required us to consult each other for things we have expertise in so we could build together what we needed to build. I this sprint we took upon quite a few tasks to get accomplished. Some of these tasks included taking the offline checking of the current ampath build and moving it to the outside of error checking and by doing that, figure out a way to fix the OnlineTrackerComponent bug we found in the program. Another that that needed to be done was establishing communication mediums with the AMPATH group and addressing some development issues we wanted to discuss with them. We needed to know if we had to worry about storing secondary and additional user login credentials offline. Knowing this would prove pivotal to our developmental Sprint. We were also able to create a backend of the new UI we were implementing using Balsamiq. Another task that was sought out this sprint was to update the HLD with local storage approach and add a checkbox to the user settings page to give option to store credentials locally. This task was taken by one of our teammate and although they were working on it alone, collaboration between the individual groups was needed because there were a lot of dependency issues.
From this sprint i learnt that sometimes not all the task we seek out to accomplish during the sprint planing is able to make it through the entire sprint. During the initial sprint planning, we had a talk about implementing a local database that would store and keep user credentials so for the few days into the sprint i began building the database base but as the sprint progressed and our team was able to communicate with the Ampath people, we realized that that extraneous part of building the database was not necessary needed. Instead understanding the encryption method of the user credentials would better suit us in our task of creating an offline login. Needless to say, i had to clear the drawing board and start again.
Overall i felt like this was the biggest lesson i could take from this sprint because i started building and spending time on it but since it was ruled out as not necessary, it almost seemed like i had wasted that sprint time. IT made me realize that in this software development industry, the product owner and the businessman have the keys and unless you ask them for it often you will develop and code in a backdoor without even realizing that your design grew old in the specifications. Establish a good and frequent communication method with the people overseeing the demands and design of the project serves as key in become a good program develop. It makes no sense to design and solve a problem with no longer exists in your scope of work.
Pattern Overview :
The author begins this chapter by introducing the importance of reflections in one’s career. As a software developer, the more progress and tasks you complete everyday in your line of work inches you daily to mastery level. This comes along with an acknowledgement of strengths by your leaders thereby often leading to a promotion or elevation in position where your knowledged skills and expertise can be passed on to someone else. This is why the author encourages us in this pattern to constantly reflect back on our work. Being a good leader covers a wide range of expectation but one of the biggest leadership qualities is to be able to lead by example. You can’t preach clean coding when you haven’t taken the time to introduce clean coding in your own coding practices.
I agree with the author on this pattern greatly. This is because through out my little experience in life, i have had many opportunities to lead and i have realized that understanding yourself, methods, shortcomings and practices helps you become the best leader you can be. And the only way you can accomplish all the above mentioned feats is to take the time and reflect. I bring up all these points because as you continue to lead the team, there will be days when the questions and daily challenges will force you to define and defend your views and methods as a leader. If you have not taken the time to reflect and acknowledge what needs to be acknowledged about you, moments like this will eventually be your downfall as a leader. It will send a messages of incompetence. As a leader, its part of your job to ensure that your voice somehow become the sound of reason for your team when things go downward.
I would advice everyone to practice some of the methods the author talked about especially the personal practice map. This is because, it gives you a vivid image of your progress through the years and also gives you a reference point to share with your team members who have similar issues and questions. It also helps you to highlight your observations, reflections, and changes that has happened throughout your programming years.
Coming into this sprint, we had a pretty nice groove going on. Team-wise, we had decided on what we wanted to contribute to the on going ampath project and this sprint presented us with the opportunity to start building what we have been discussing. Our task as a team is to build an offline log in capability for the current users on the system. We decided to also get a visual layout of the task we wanted to complete that way we could properly diagram and see what we were building. But to accomplish all this task, we needed to understand how the session service code worked in the application.
Completed Tasks :
Although the original tasks we set out to complete didn’t seem too hard, it required many moving parts and sessions to fall in place before we could actually start building it. First and foremost, we as the team needed to contact ampath and verify with them if the approach we chose to address the log in issue was the best way to address the issue and also everything would be compatible with their software. We also needed to figure out how to store user credentials in local Storage so the user can log in when offline. The storage of user data would need a secure database configured. We as a team decided to research pouchDb and look up its implementation. I personally spent a few days reading up on it and began to start implementing git in code. although i could finish building the sample project i was working on, i think i got enough understood that i can help the team should we encounter any problems and depending on our progress as a team, i will probably go back an finish building that local database test app.
Another thing that got completed this sprint was the visual layout of the application and how its offline module was expected to work. We were able to draw a model of what we wanted to build using the balsamiq tool. after diagraming it, we were able to trace some of the server side code to get a feel for what the program API was like. With this API knowledge, we are able to build and know how to implement new services and functions in the existing application. Mathew was also able to build a prototype of what we need the application to be doing when we log in.
We were able to get most of the thing we had initially decided to get taken care of this sprint period. Just like every sprint, there were still a few tasks that were not able to be completed. Mainly because they are an things that need to remain on the board until the project is fully completed. Some of these task included collaborating with other teams to ensure that the technology that is being used is compatible for all factions involved in the project development. we also currently need to create a backend design of the UI using balsamiq.
The author opens this apprenticeship pattern by addressing all the intangibles that are often overlooked in the programming world. He talks about the challenges we, as developers encounter in our career. He addresses the issues of horrendous real-world projects that are often rigorous, tedious and exhausting. It can grow from frustrating at times to morphing into overly chaotic or constraining issues that are backed by a business man who only knows what the current trend demands. All through this, the author urges us to hold firm and ensure that our drive for mastery propels us to withstand the situation.
I was fortunate enough to be taking the CS-348 class so i got to witness the dynamics of a software development environment through one of our in class simulations and there i realized that the constant specification changes by the business man often can lead to stressful and frustration environment to work in but it is here that the author tell us ground our motivations to the walking the long road pattern. In that pattern, we are though to continue taking on task that build and molds our skills. So in the mist of all the chaos, we are expected to find a related source of interest in programming that will continue to carry us when the going gets real tough.
I personally feel like this is the hardest pattern to master because normally, programming is challenging so the only thing that keeps us going at it is our passion for coding/ developing software. Now should that passion be attacked, we have no more source of interest. But the author tells us to persist even when we have lost drive and find a secondary source that can fuel us through the tough time until our original passion returns. I do agree that it does get to a stage that being able to provide for you family comes into the equation so this rules out switching of area or quitting in generally and money often serves as the secondary drive that can propel us until we get our initial vision back. The life of a programmer is filled with many adventures, learning slopes and curveballs but finding joy in programming amidst the bad times deepens the love and passion to be great !.
Sweep The Floor
When reading this pattern, i was a little puzzled the first time but after a second read through i understood what the author was insinuating. No one hands over the most important tasks on a project to a graduate they just hired. That would be putting the future of the company in jeopardy. This is mainly because you do not know how competent a person is without seeing their actual work.
In this chapter, the author brings to light how apprentices can gain trust of their respective teams and build their way to becoming master craftsmen on the team. By “Sweeping The Floor” newcomers or new hires are able to build a portfolio performing tasks that the other team members would not like to do. And when performing these tasks, they are to do it with a sense of urgency and purpose. By ways of such means, you are able to build trust, contribute to the team and also demonstrate your level of competency and understanding of the team tasks. We often forget that before we get to celebrate the big victory, having multiple little victories builds ones self confidence and skills that would eventually contribute to the “big wins”.
The author did mention the value of our college degree once we graduate and i think this is the most surreal thing i read from the entire chapter. Knowing that all the time and effort invested in acquiring my degree only goes to raise expectations on what i could potentially bring to the team but doesn’t solidify me as knowing how to develop a software. with this said, the only way to solidify and earn my teams respect as a programmer is to create well organized code and programs when i work on the less impacting task i am assigned or i volunteer for. Of course “sweeping the floor” is hard when i have completed my degree in hopes of becoming a full time software developer but the key is that, i would still have an opportunity and by doing a tremendous job on assigned tasks, i will be able to make a case for my skills and earn the respect of my team members.
This chapter was especially exciting to read because it encompassed many of my personal life mottos and philosophies. The author begins by talking about avoiding safe steps but instead to challenge ourself with bigger things. Growing up, my mother always motivated me to do my best and to continue to move forward. she also emphasized on seeing every task as a stepping stone to treasures that would enrich my personal repertoire of experiences and tenacity. I believe this is what the author was attempting to address in this chapter. In the absence of fear, the sky becomes the limit and everything becomes doable.
I do agree greatly with most of the authors input on the deep end pattern. I believe that in the absence of growth and challenges, we are often succumbed to mediocracy and complacency. We need to continue to learn and take-up new opportunities that challenge and cause us to fall out of our comfort zone. The feeling of accomplishment is exponentially amplified when we seek new challenges to conquer and complete each day. The life of a software developer has a starting point but no clear end point as illustrated in the previous post. To continue to remain relevant and up to par with the industry standards, we need to constantly build and elevate our skill so that nothing will take up by surprise.
Although we are advised to seek out projects and task that challenge us, biting off more than we can chew will only cause us to loose our breath and end up getting it wrong , but to avoid this, we can implement mentorships and find experienced role models who can give us good guidelines and support should our going get tough. Also we need to take educated risks by understanding what will be needed to get the task accomplished. Its one thing to blindly tackle an issue without fully comprehending its ramifications but its also an even bigger issue when you have already jumped into the task but have no source for guidance and support. “Risks are opportunities seen through the half-shut eyes of fear” as the author said but understanding what we are capable of is an even greater tool for success.