Revealing Ignorance

Hello, again fellow readers!

Today we will once again be continuing our journey into software apprenticeship patterns. From last week, we will continue on to the next pattern, Expose Your Ignorance.

This pattern is all about once you have gotten yourself onto a team where you can learn more from your fellow teammates, presumably in a job. The problem is that well… you are ignorant. You need to deliver and you have a lack of knowledge in whatever language or technology you need to be able to deliver.

The offered solution is fairly simple, ask questions and don’t be afraid to show that you are ignorant in a particular subject. You should recognize that it is human to want to appear competent and not appearing competent is not a bad thing. It is all part of the learning process. As a software craftsman, you need to know many different subjects and technologies. The pattern suggests that people who are uncomfortable with the learning process of appearing ignorant become experts instead. They seek out expertise in one particular field and never venture too far from it. Experts are important but the journey of a software craftsman is much longer and requires a broader scope of knowledge. You become an expert in one or several subjects along the way but that is not the ultimate goal. For a software craftsman, one of the most important skills is the ability to learn. To solve this problem the pattern suggests writing down a small list of thing you don’t really understand about your work and posting it in public view.

This pattern I find interesting. What I found most interesting was the distinction made between the software craftsman and the expert. The pattern admits that a software craftsman will likely become an expert in a few subjects but that is not the ultimate goal. The goal is not explained in the pattern (I’m sure it is explained at the beginning but I have forgotten it at time of writing) but the difference between the expert and the craftsman is that the expertise is not the goal. A craftsman goes further than becoming an expert and goes on to craft with the expertise of many under his belt where the expert gains expertise and then rests on his laurels. I do also appreciate the part where it states that by admitting ignorance it will increase your reputation greater than “fake it until you make it” will.

That’s it, for now, my fellow readers. Until next time!

Advertisements

Let’s Learn Some Concrete Skills

Hello, again my fellow readers!

This week we shall continue looking at Apprenticeship Patterns. I decided to skip over the Unleash Your Enthusiasm pattern and instead decided to talk about the Concrete Skills pattern this week instead.

The Concrete Skills pattern seeks to solve the problem of joining a team of craftsmen to further your learning opportunities. This could also be the all-important problem of getting a job. The problem keeps on going as you are too much of a risk as you may not be able to directly contribute anything to the team. You may not be able to even indirectly contribute.

The solution proposed is fairly self-explanatory. It’s right in the name of the pattern! Acquire concrete skills that allow you to demonstrate ability with relevant tools and technology. The pattern does suggest acquiring some skills that are geared more towards getting past HR and managers. I do like the proposed idea of “buzzword bingo” that the pattern mentions briefly. The rest of the concrete skills that you learn should be directed at showing your team that you are actually useful and that someone doesn’t need to look over your shoulder constantly to ensure you don’t mess up or break something. It goes on to make a good point. When faced with a hiring manager, they will ultimately be looking for someone who can actually contribute in some way on the first day. Having concrete skills is, as the pattern puts it, a way to meet them halfway. Then as you progress, you will have to rely on these concrete skills less and less. To learn what concrete skills to build, the pattern suggests looking at resumes of people whose skill you respect in the business. Identify some skills from the resume and work on them and of course, keep reviewing your own resume.

This is what drew me to talk about this pattern. It is directly relatable to me as I am in the job hunt as I am graduating soon. I found this entire pattern to be generally good advice for anyone in the software development field seeking a job. It also corroborates what a lot of people have given me advice for job hunting.

That’s all for this week. I wonder what pattern I will get to read about next?

Until next time readers!

 

You Must Learn To Unlearn

Hello, again my fellow readers!

Last week we took a look at the beginner pattern, Your First Language. This week we will continue along the path to the next pattern, The White Belt.

As I have said, The White Belt is the next apprentice pattern after, Your First Language. This pattern is all about what to do after you have learned your first language and can strut your stuff with it. The problem The White Belt pattern is here to solve is when learning a second language becomes tiresome and tedious. Learning one language is great but, expanding your library is a must to become a software craftsman. What can happen, however, is slowdowns and stalling in learning. The solution to this is to adopt the mindset of a white belt. To quote the book, “Wearing the white belt is based on the realization that while the black belt knows the way, the white belt has no choice but to learn the way.” In other words, while you go about learning a new language, treat it as if it was brand new to you, even if you are learning something with familiar attributes. An excellent example is you have learned Java and now you are learning JavaScript. Both are fairly similar to each other and have overlapping ideas and methodology. Using the white belt philosophy, treat learning JavaScript as if it had no relation to Java. While this may seem counterintuitive (it still does to me),  the pattern claims that it will accelerate your learning. It will also allow you to discover new possibilities, as well as your mind, is open and without preconceived notions.

I understand where this pattern is coming from. I do get that an open mind can, and most likely will, lead to new possibilities. I agree with that. I suppose that my issue is that forgetting to accelerate learning is still something I find a bit backward. Looking at it, I must admit that I have not tried this method. Typically I find that making associations to things you do know is a good memory tactic and can speed up learning. It is entirely possible that the White Belt pattern will work for me. The only thing for it is to try it. I can legitimately say it doesn’t work without trying it for myself now can I?

Looks like I have some unlearning to do in my future.

Until next time readers!

Going Back To Square One

Good my fellow readers!

Today I will be discussing an individual Apprenticeship Pattern from the book, Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. The pattern I would like to discuss today is naturally the first one, Your First Language, because where else is there to start but at the beginning?

The pattern starts by defining itself as a pattern for those who have surface knowledge of a couple of languages. It suggests that this particular pattern is for those who need to learn a language to solve a problem at work for example, or need to know a language for a job interview. It then launches into the solution, through execution of the pattern. To put it plainly the pattern is to pick a language and learn it. Having a problem to solve helps the process by giving you a goal to work towards and a drive to keep learning. It is also advised to take things slow and in small steps. It is also suggested to find a community and learn from its members as some methods or teachings may only be spread by word of mouth. It ends by reminding the reader to not get stuck with one language and to spread out into other languages.

I will admit, with this being the first pattern in the book I expected it to be for total beginners but it is aimed at just about everyone. What I find interesting about this pattern is that it seems to cater well to those who have never really picked up coding before or someone who, like myself, have had years of high school and college education in coding. I will admit that the amount I know about all the languages I have learned about is somewhat shallow. Some go deeper but many are probably not that far off from just surface knowledge. I might just try following this pattern after graduation. At first, I would have only recommended this pattern for only beginners who haven’t had formal schooling but after reconsidering, I think even those like myself who have had formal schooling can benefit from this pattern.

That’s all I have to draw from this first pattern and I hope to get more from future patterns. Until next time readers!

 

This Is It, The Final Sprint

Hello, once again my fellow readers! I say this with some sadness as it is my last retrospective for the semester. The final sprint has ended and the team is now in full presentation mode. For the sprint, some of the team decided to keep working on the product and some of the team, including myself, decided to start work on the presentation.

The part of the team that decided to continue work on the presentation worked on small improvements to the product. Small improvements to features we have already implemented and making aesthetic changes.

The rest of the team, including myself, started our presentation work by making a presentation. From here, we decided to break and each of us would start working on our own portion of the presentation. My part of the presentation consists of what happened a few weeks ago with the GitLab to GitHub transfer. You may remember that series of events from my sprint retrospective blog a couple of blogs ago. The main part of this presentation is not just to recount everything we’ve done over the semester, however.

The big part is to recount everything we have learned over the semester. To do this, I needed to go back and reread all of my blog posts. Boy, it has been an interesting ride this semester. Looking back, I have to say that I like Scrum. It took a little set-up but by the end of it all, Scrum worked out pretty well for our team. Everyone in our team was able to step up and take lead when they wanted to and no one person was ever the leader all the time. It definitely led to great teamwork and helped each and every one of us to achieve our individual and team goals. What I find interesting about Scrum, and if anyone wants to replicate Scrum successfully is that I find that Scrum works best as a team that self regulates itself. What I mean by that is, the team is able to find team members that are slacking or behind due to other reasons, and help them get back on the horse. If the team self regulates itself, the team can keep itself on track and make up for momentary weaknesses.

Another thing I learned was quite a bit about Git. When the git repository transfer had to happen as you may remember, I had to transfer our project from our GitLab repository to the min GitHub repository. This process that I went through taught me two things. The first was that we should have planned a bit further in advance when we first created our part of the project. We created our part in GitLab, without a thought. Thinking ahead, we would have definitely chosen to make it in the main GitHub branch we had created. The second thing I learned was about Git itself. During the process of moving, I thought that I could just simply copy paste our files in. That was not the case, and I had to enter in lines of code in some files, to preserve the work that other groups had done. I also had to deal with numerous merge conflicts that I had to deal with as well. I learned from that process how to better deal with those merge conflicts, and with moving files and things into a git repository.

Well, this is it, readers. That’s all I have to say on this semester and I definitely I can say that I got something out of it. This will be the last farewell as not just the semester is ending but I am graduating as well. No more blog posts for me… for now. I may return to writing blogs as they did help me reflect but we will have to see in the future whether I return. I must end sometime, so for the final time farewell my dear readers!

Another Sprint, Another Retrospective

Good day to you again, my fellow readers! Well, the time has marched on and I have once again found myself at the end of another sprint and you know what that means; time for another sprint retrospective.

This sprint has been a bit slower than the previous sprint was. With the trials and tribulations of relearning or learning angular (in the case of some of our group members) behind us, many members of the group were able to excel and start knocking items off the backlog. With each item off the backlog, my teammates were even able to add on extra features and improvements. Content for the left navigational bar was established and each was given an appropriate button. We then added submenu buttons, for items that belong under a certain category and not on their own. A home button was added to take the user back to the main screen, return from the left navigational bar and close it. Many aesthetic changes were made as well. Buttons were moved, spaced out more, colors were changed to make it more aesthetically appealing and less harsh on the eyes, the font size was increased for better readability, and the text that confirmed a button press was moved to be centered on the page. The latter was simply for testing purposes so that button presses could be confirmed that a button press would actually register and change to the appropriate page.

On the last day of the sprint, our manager/professor informed us that another team working on the search bar function for the AMPATH application wanted to push their work to the Github repository and we needed to push our work as well because we had made a base application in addition to making the left navigational bar.  As one could expect, there was a problem. The issue was that our group had made a repository and were not working off of the branch we had created. Now, this may not seem like a problem however, the repository we made was not on Github, but in Gitlab! Remembering the Git lessons I had just had earlier in the day, I suggested simply setting a remote upstream to the branch in the main Github repository from our Gitlab repository. We could then simply push from out Gitlab repository to the Github repository and all would be well. With approval from the professor, I made sure to pull all changes from my team members, set the remote and attempted the push. Error. Of course, things can’t be easy. The error was a permissions error that would not allow the push if I remember correctly. After conferring with the professor again, he determined that the best course forward would be to simply copy over the needed files and make changes where needed to other files and push those changes to the branch. Then request a merge with the master branch to make the changes available to the teams that needed them. This was not terribly fun as while some files could be copy-pasted in, there were many files that I had to manually edit and add in lines that we had added. Before attempting a push, I made sure that the application actually ran, which it did after installing npm. After pulling all changes and completing the manual edits, I attempted to push the changes. Error.  I was missing files from the master branch. I pulled from master and tried again; same error. I wasn’t sure what was going on as I had just pulled and there were no updates. I pulled again to receive a no changes message. This had stumped me. This left me with only one option, sleep on it. After waking up, I came back to the issue and had a random thought to pull from the branch, and it worked. When I went and attempted the push, I had one more error, but that was because I forgot to check the master for updates. One final pull from master and I had done it. I was able to successfully push to the branch. To end this saga, I made a pull request to merge our branch into the master branch. That saga was great practice with Git and solving its many errors.

That’s it, readers. Another sprint comes to a close. We have only about one or two more sprints left so the time we have left is quickly coming to a close.  Until next time readers!

Let’s Sprint, Into This Retrospective

Good day my fellow readers! Welcome back to another sprint retrospective. This is the fourth sprint in the AMPATH project. With things kicking off last week, we are into the thick of things working on the project.

With the new sprint, and a new goal in mind, the group decided to tackle the side navigation bar in pieces. As a group, we all sat down and discussed what are the components of a navigational side bar and, what components we should prioritize. As a group, we decided to prioritize the skeleton, button tasks, design, scaling, content, and web view. This, of course, lead to more learning about Angular. The sprint continued on with the group working off of a dummy app that one of the members had made. This is a concept where one makes a dummy or a toy of sorts. This dummy or toy serves no purpose to the project but, acts an environment to learn and mess around in. This way, one can learn in depth about say, for example, an Angular app, without impacting the real and important app in a negative way. You can make mistakes on the dummy or toy, and learn what not to do when working with the real thing. This was quite helpful to everyone on the team. Thanks to the dummy, by the end of the sprint, we had a working side navigation bar with working buttons. We had even worked out a nice design for the side navigation bar. While I was researching scaling, a fellow team member brought up that scaling might not be an issue that we need to tackle at the current moment. Taking time to look at his opinion I came around and began to agree with them. At the stage we were in development, we were developing for one kind of screen, our computer screen. However, we did not realize this until the end of the sprint. During the sprint review in class, we decided to look at the side navigation bar in the current state that we had it. Looking at the side navigation bar, the group started discussing on what devices the app would be used. Doing some quick changes to the side navigation bar, we quickly found that if we wanted to have the side navigation bar used on multiple varied devices, we would need to have the side navigation bar adapt to the screen size of the device. I will admit that after discussing how needless scaling was earlier in the sprint, now finding out made me a little embarrassed. For about half of the sprint I was doing a little less work than I should have been, thinking that my assignment was not useful and I would not need to learn this. This has left me with egg on my face and a bit of catch up work to do.

At the end of the sprint I have come out learning two important things. The first is that while it may not contribute to the project directly, making a dummy to learn about a component is a great learning method. The second is that even if something seems, useless in the current sprint, it is best to continue working on it, as it may be useful later on in the sprint.

That brings us to the end of another sprint review. See you next time readers!