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.
Team Retrospective – Sprint 3
This was a very pivotal sprint period for us as a team and class because we each began to work on the tasks and duties that we decided to contribute to this project. It seemed like it took forever for us to build traction on this project as a team but once we began to figure out which direction we wanted to go, everything began to speed up and move very quickly. We took upon the task of ensuring an offline service exist within the Ampath application where you would be able to log on and work even if you are offline. After many brainstorming moment and code reviews, realized that we cant even focus on building an up and running module before we try to collaborate with other teams because all are work and tasks have external dependencies on other teams tasks and involved factors that were beyond our control.
What Got Done
As a team, we were able to accomplish many tasks that we set out to do. Initially, we all wanted to understand the code enough to be able to ring about ideas and how to approach our offline login task. we were able to create an overall architecture/design of offline login feature using Balsamiq. This was a task that was handled and led by George and Mathew. Another thing we decided to do was also look into the bridge designer pattern as it helped us understand and decide which approach we want to take our design’s architecture and functions. After extensive code review we decided finding out which servers handled the current logon process and the methods would be key in our development of the offline logon process. Once we understand how they have it working , we could implement their methods and get ours up and running.
Conflicts/Issues Moving Forward
As of right now, we as a team have a few issues that need to be addressed in order for us to continue making progress. We realized that we would need to implement a database to be able to test and ensure that what we came up with works. The issue is that one of the teams in the class is also building a database for the project so we are at a point where we feel that we need to amplify communications between the two teams. We did decide to use a mock/test database to aid us in building what we need and design the UI also and then after that, we would collaborate with the team to make sure that the specs and methods line up so that merging the two modular designs would be easy and compatible. Through this process, i have learned that to build a software that involves multiple components, you need to communicate with the other teams working on the other components so that in the end, bring the software pieces together does not become too tedious.
Looking ahead, i feel as though we have a good grasp of the direction that we want to take our project but need to continue to collaborate and talk with the Ampath team and see if they see eye to eye with our approaches and designs. The next few weeks should be very interesting !
Chapter 3. Walking the Long Road
In this chapter, Adewale Oshineye and Dave Hoover bring light to the life long journey of becoming a master in programming. One cannot expect to become a great programmer after a specific number of years because the concept of mastery in it self is subjective in programing. Its subjective because the better you get, the more you begin to understand how much you actually don’t know.
The author begins by acknowledging the fact that being exceptional in your group just means you need to find new competing and other sources of motivation because like everything in life, there is always someone who will be better at it than you. I agree with the author when it comes to the longitivtiy of programing. I have always known and understood that there will never be a time where i didn’t have anything else to learn in programing, in-fact after taking the software testing class, i realized that far beyond great programing skills is a whole plethora of development that deals with software testing and designing softwares that can be properly tested. The concept of mastery in programing should be facetiously understood as a hoax because no such thing exists. Everyday new technology emerges and with each new technology comes new knowledge and techniques that needs to be learned and implemented. So you can be a very familiar with something today but tomorrows technology will bounce you down from you mastery pedestal. The key to staying relevant is to dedicate yourself to a lifetime of learning and with each step, grow a more yearning character that is always ready to receive and learn new things.
Finally, there was a section in the reading that i don’t think i fully agreed with. It talked about passing up new opportunities to move up into management and elaborated on staying in your path to maximize growth but i disagree with this. There is a saying that goes like “in the land of the blind, the one eyed man is the king”. I don’t understand how it makes sense for a dedicated apprentice programmer to pass up an opportunity to oversee and mentor other programmers just so someone else who is trying to exit the programing world ,take the position to criticize and give instructions on how code should be written.
Team Retrospective – Sprint 2
I think this was another important sprint. Most of my group members were all new to the technology we are learning so this sprint kind of gave us an opportunity to read more about the programs api’s and how they worked and functioned. We also had a few tasks that could not be completed in the first sprint so we carried them over. For the first sprint we were to complete building the application and setting up the environment. Some of our members were also able to connect the application to the server but that was officially a task of sprint number 2.
What was done this Sprint
We spent a lot of time reading many documentations as a team to properly understand the programs architecture. we all connect to the server this sprint. Some of the other tasks that we were also to accomplished this sprint included checking out balsamiq and coming up with design ideas to implement. The design idea was no simple task because almost everything we thought of was too abstract for our current knowledge or not enough to contribute to the current repo so after sometime of going back and forth with ideas, we realized that on our Trello board, we had various tasks and features that were advertised and needed to be built and implemented in the application. After much discussions, we as a team were able to agree on one task that we felt could be accomplished and completed by us based on our current knowledge as a team. we picked the “offline login and Offline data storage” as the task we wanted to get done.
Design Implementation and Looking Forward !
Personally, i have not created any “login” applications but i believe i have the skills and tenacity to learn all that i would need in order to be able to contribute my fair share to the team. After deciding to go this route , we realized that we needed help from other teams depending on what they had selected as their tasks to complete. Since we wanted to do the users offline sign in and data storage, we needed to store the user’s passwords and usernames locally on the device that will be accessed. But since log in credentials are sensitive and needs to be secured, we realized that we needed to implement a decoding and encoding encryption system. This way, all data saved on the local system could not be accessed by anyone who would come in contact with it. Again the patients data would also have to model the same architectural pattern because patients information are private and thereby needs to be kept safe and secure also. With all these thoughts and approaches in mind, we reached out to a team that was next to us and luckily, they agreed to handle the encryption and decryption side of the design. This brought us to an ease because it split up the overall tasks that needed to be completed by us but on the flip side, it puts a dependency on their team. We would have to know how the encryption works so that we can code to implement it. This to some extent makes me worry a little bit because it almost seems as though if the other team encounters issues they are not able to resolve, we will be stuck but again, i know we can use dummy variables to get at least the concept aspect completed. Looking forward to the new sprint. !
PATTERN 5: THE WHITE BELT
I think this was a very informational chapter in the pattern lists. This chapter opened my eyes to the realization of my current situation. We are moving on to angular development for our capstone experience and its seems to be taking me longer to understand and grasp the concept. I had been using mostly java for most of my college programming years and have grown accustomed to the ways and norms of how things are done. But with this new angular task I realized that I had to learn and try to understand more things and even though I am a pretty quick at picking up new technology and understanding them, angular was just taking me long. But after reading this pattern, I understand that developing the deep knowledge and tricks in java and getting accustomed to being able to maneuver around in that specific language caused me to slow down my skill picking ability. Since I didn’t have to pick up much but instead implement and use what I had acquired.
I believe and agree with the author of the book to some extent. I cannot just forget all I have learned and start from scratch but I can create a new array mentally that is to be filled with new technologies and languages and also try not to bring up what I already know when learning the new materials. But doing this, I will yearn a humble and fertile mind that will be able to grasp and understand anything that will be thrown at it. Also according to the author, unlearning what you have learnt and forcing yourself to believe in your novice status exponentially accelerates the new learning process and makes it easy to develop new insight and possibilities. I believe that its very important for me to understand that I have to give the new technology time and energy to allow my mind to digest it. And after that I will be able to combine it with my prior acquired knowledge, it is at that point that I can call my self a good programmer. Knowing one technology is good but being able to learn multiple and train your mind to utilize what you have learnt makes you a special programmer!
I found this chapter (pattern) to be another intriguingly good read. It addressed an issue I had questioned a fellow programmer about. I asked him about all these great programmers that have written many prestigious codes and programs. They didn’t have access to these Google sources we are able to consult for help to aid us in figuring out issues and problems. What did they look up when they had issues? Imagine a programing world where you couldn’t Google or look at other great programing works to model out a solution. No open source API’s and frameworks to work with. It would be very difficult to get things done. As the author said, “if you don’t look at the works of other that are better than you, you are doomed to continue making your own mistakes and carry on your bad habits”. We often forget that we are a generation that strives to continually move forward and the key to doing this is by learning from others mistakes and building upon it so we don’t have to make the same mistakes by so doing, we maximize our time spent on moving forward.
i strongly believe that the development of my programming abilities did not take a day’s work but instead a life time journey involving many years of learning, reading and absorbing varieties of programing techniques and their proper applications. Yearning to learn at every opportunity i get and through that, i believe i will begin to develop a keen sense for what is proper and practical. i will also learn to understand the decisions and thought processes that goes into all the good programming works. Programming remains an art that needs to mastered and the more i feel i am exposed to others exhibits and what the experts think about them, the more i will be able to learn, see and inspire my own artistic sense. Although not to be confused with mimicking, One needs to understand that everyone has their own niche that they will have to carve but this will result from being exposed to many programing’s forms and finding the one that works for you.