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.
This sprint was a very important one considering what we had sought out to accomplish. In this sprint, we wanted to add many functionalities and since it was the last full sprint before the end of the semester, we wanted to address all the major functionalities we felt needed to be added before we called it a semester. Some of these tasks that was being addressed this sprint was :
- Updating Offline Track Refresh Time.
- Documentation of work that was completed
- Test Cases – UI Checkbox Test
- Backend Functionalities.
Most of the documentation was done by our team captain, since he had the most understanding of all the moving parts that was involved in the program.
What was Accomplished
Of the tasks that was set out to be completed, we were able to complete the offline track refresh time and also the backend functionalities of the program. To make things more clear, we also documented a list of classes and files that we touched / edited and also draw a diagram of how we envisioned our additions and modifications to function within the application. Backend functionalities was tricky but we were able to write modify existing methods and function and also wrote new methods that would aid in completing the requested task. All this work was again documented and revised. I believe the most challenging tasks through out the sprint was coming up with test cases that would evaluated and affirm the functioning of the proposed written code. I was personally in charge of this testing. From deciding to address testing, i was able to dig through many codes and files that we later had to review and revise. Every code we wrote needed some sort of testing module that would verify its status and would be used to troubleshoot should we find have any issues in the future.
After this sprint, i conclude that testing although may not seem like it, is one of the tedious tasks of writing code. In order to write efficient and proper test, you need to be able to understand the logic thats already being implemented in the code then reverse the thought process and develop a new way that you can verify that the task got accomplished. I realized that not only do you need to be able to read and understand code efficiently, you also need a creative edge that would be used in coming up with test cases and scenarios. This is because unlike coding, often test cases and implementations are unique and does not already have a laid out methods to get this accomplished. Coding requires pose and originality but i believe testing adds a touch of creativity to this paradigm. Overall it was a good sprint and i think we were able to communicate better and get a lot done.
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.
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.