Apprenticeship Patterns: Be The Worst

“Be the lions tail rather than the foxs head!”

I enjoyed doing the reading. It is protrayed well enough to understand the basic concept of how ones should emerge in the field of computer science.



Three things that I caught attention towards were: learning new skills, taking risks and surronding yourself with people who knows more then you.


There is a say that, hustle like a broke and live like a master.
What I have reviewed is that thinking that you are the weakest member of the team will make you eager to learn and work hard. In order to be the best version of yourself, you have to take risks.
There is no easy way. That is where your patience is tested.
If you fail, you learn, if you didn’t you are always one step closer.


Looking at the Software development companies. They took risks, worked hard and learned from others. That is how they are able to stand out in the Tech world.
To be a good developer you have to collaborate with great developers. It is not their time need it’s the skills that you need to learn. Surrounding yourself and being among them will give you motivation and positive energy to grow into the Software Development field.


This strategy can be applied in any field. maintain and give you the motivation to grow and not give up.



From the blog CS@Worcester – Tech a Talk -Arisha Khan by ajahan22 and used with permission of the author. All other rights reserved by the author.
					

		
		
	

							
	

				

			
						

				Reading List
			

								


				

			
For this week “Apprenticeship Pattern” I have chosen Reading List. It is a pattern about keeping up a running list or more precisely a priority queue, as the author describes it, of books that are worth reading for amassing more knowledge about a given subject. The queue will change or be reorganized many times over the course of it, but it is worth having. Another useful advice in the pattern is to ask your mentors or people more knowledgeable bout a subject about which books they recommend reading.


What I like about this pattern is simply something that I have already started doing, it is interesting to me to find out that it is not only me who had this idea. I think this will be a very useful tool in anybody’s arsenal in their professional career. What I have done is essentially described in the pattern itself. I have talked to some of my colleagues at work as well as my bosses and figured out what books they recommend, after that I have done some research and based on other reviews of the mentioned books I have made my own list.


Not all the books in my opinion need to be about your work or career, if they are helpful in some way then they are worth reading. Any knowledge is good, the best knowledge of course is the one that helps us grow as a person.


One useful thing that I have learned from this pattern is to put my past books on my list and keep them there even after I have read them. This is to help me and other to reflect on them later and to better remember the contents and lessons acquired from the book. The pattern also states that better understanding of the subject at hand will help people refine and organize the list better. I agree with that and like the author states mentors are always a good source of said understanding and any good mentor will always steer you in the right direction. I’m feeling lucky because I have been able to find such a person. Currently due to my student status my reading has stalled to a degree, but I do plan to get back to it as soon as possible.



From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.
					

		
		
	

							
	

				

			
						

				The White Belt
			

								


				

			
For this week’s blog post, I decided to write about The White Belt.  This section is in Chapter 2 which is called Emptying The Cup, and if I remember the introduction for Chapter 2 correctly, this chapter 100% belongs in this section. Like all sections in this book, it is split up into 5 sections, context, problem, solution, action, and see also. The context is a short sentence that basically explains the reader is now confident in his abilities in a certain language, and people rely on them for help. I was actually shocked to read this because typically the white belt symbolizes the beginning, and this book’s description of a white belt is knowing a language and helping people. That’s shocking to me because that just means I have no belt because I feel like I’m in no position to be helping people with the skills I have now.


The next section is the problem. This section was also very short, but it should be because it is only discussing the issue. The issue for this section is that it is difficult to learn new things, and that your “personal development may have stalled” (Oshineye, Hoover). While this isn’t an issue for me yet because I am still learning my first language, this could very much be an issue in the future for me as I also struggle with learning new things.


The solution section urges the reader to start to learn new things by unlearning the things he already knows. They use real life examples as well as some code examples to get their point across. I particularly enjoyed the code section because I liked how they showed the same process being done with two “radically different” (Oshineye, Hoover). languages. They did this to show that because you have a solution in one language, you should still learn a new language to broaden your horizons.


This section was a really easy read for me. The part where they talked about how the white belt had to learn the way while the black belt knows the way really hit me because that was how my internship was. I had to watch and learn everyday before I could even do anything, and it was actually nice to learn along the way because I realized there was so much more that I had to learn before starting my real job.



From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.
					

		
		
	

							
	

				

			
						

				Android Activities and Fragments: Getting Them Straight
			

								


				

			
AndroidX has brought a few changes to the Android framework, but the general architecture remains the same. Likewise, the few years since I’ve first learned Android has completely changed how I feel about Android. At this point, I am developing the basic architecture of my independent study app.


There are a lot of conflicting opinions about Activities and Fragments in the Android Developer community. A few years ago with my limited Android experience, I did not completely understand. I likely don’t completely understand now. However, I have better tools and more programming experience to see how they should be used, as well as to make my own decisions on how to use them.


At first, I found myself paralyzed with confusion on how Google wants its developers to use Activities and Fragments. As an example of how programming concepts translate well to other technologies, learning Angular helped me understand the difference. Activities are a single “thing” that a user does, and can be thought of as a web page. A Fragment should be used for a modular UI component, and function as Components do in Angular.


This isn’t a perfect analogy, as the frameworks are very different, but this is a good way to proceed when deciding how to structure your app. Google’s Introduction to App Architecture guide is a great explanation, and the most important thing to remember is to maintain a separation of concerns. In the end, Activities and Fragments aren’t a significant part of your app. They contain your app. They are something your app uses to work within the Android framework, and your business logic should be elsewhere because Android will pause or stop any Fragments or Activities it needs to if, for example, memory is running low. There is no guarantee they will maintain state unless you take additional steps to ensure it does so.


In researching opinions on how to use them, some people mentioned that they’ve seen developers decide on having a single Activity, and adding all features with Fragments. This is a tempting solution, but that might result in complex logic to control navigation. Furthermore, Fragments are meant to communicate through their parent Activity. In a large app, this would likely result in many implemented interfaces and complicated callbacks. Bloated Activities a big NO.


Likewise, others mentioned only using Activities and not adding complexity with Fragments. This seems a bit more reasonable, but restricts reusability of the Fragments in the UI. Only one Activity can run at a time. The beauty of Fragments is they can easily be dropped into a layout and reused. If they are designed to interact through their parent Activity, two Fragments can be shown at the same time on a larger tablet, even if they must be shown on different screens on a phone. Creating Activities only would mean either creating new Activities with repeated code for a tablet, or reusing the phone UI at the expense of user experience.


I’ll reiterate: separation of concerns. In Android, or any framework, understand the philosophy behind a class and component before deciding to try to simplify things. It’s likely that they were designed to prevent the problems you will run into.



From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.
					

		
		
	

							
	

				

			
						

				Concrete Skills
			

								


				

			
I have furthered my reading in Chapter 2 of the Apprenticeship Patterns this time about Concrete Skills. With all the romanticism of being an Apprentice and obtaining the ability to learn quickly this chapter really tells the other side of that. It does pay to bring a level of enthusiasm for learning to a team but in order to be hired on a team you need a point of persuasion. This is when concrete skills come into play. Examples described in this chapter are things like a basic knowledge of various industry popular languages, frameworks, and a well developed understanding of your native language. Having these basic, or concrete skills, allow you to show some sort of way that you can benefit a team indirectly with basic tasks before you learn how to directly help.


This chapter addresses something I often think about. Some questions that run through my head, “What are the basic skills I need for getting my first job?”, “Am I expected to know what they are developing and how to contribute, or will they teach me?”. The truth is you can’t know about a development project before you are part of it. How things are done and what the scope is, will have to be learned as you go. Then my first question of what it is I need to know beforehand becomes more clear. My concrete skills need to be further developed, I need to explore more now at this stage in my career. 


I often feel the pull to my familiar skills when presented with a project. I need to use Java because that’s what I know, I need to use this IDE, I need to use this Database. However, it’s interesting as I read this book I see my development toward these goals presented in each chapter. The reading helps solidify my exploration into the unknown. The start of this semester I thought I would only use my most used IDE and the database I was used to using. As the semester got going I began to use a new IDE that seemed to better fit my interests after I took the step to get familiar with it. I also took the chance to learn about a new database application that better fit the needs of the project rather than catering to my familiarity. My next goal is to learn a basic understanding of a few more popular languages.


Developing these concrete skills is just as important as unleashing your enthusiasm for learning. Both are beneficial for a team but concrete skills will give you a practical use upon hiring.



From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.
					

		
		
	

							
	

				

			
						

				Craft Over Art: or how I learned to stop worrying and love my ugly UI
			

								


				

			
As I mentioned last week, I have a tendency to try to make products out of projects; meaning I can’t just have something to tinker with for fun, it needs to essentially be a rough draft for the actual project I have to work on. In the same vein, I have another hang-up on wanting things to be clean and pretty to start. Now, of course, one should strive for well formatted code following best practices, but specifically for those projects with a user interface I try to go straight to a finished product from the start. As a result, the Craft Over Art Pattern was illuminating, bringing into focus where my priorities should lie especially in contrast to where they are currently.


In sum, this pattern emphasizes that you have been charged with creating a functioning product, not necessarily a pretty one. The line, “the things we build for customers can be beautiful, but must be useful” says it all. I realize in constantly polishing a project before its feature complete, I end up throwing away a lot of work spent on “dolling up” features or elements of the user interface that may change or not even be used. I even caught myself making the same mistake even on a personal project using a different web application language, where I did not even attempt to make any forms or methods that communicated to the backend, instead spending time adding libraries for user interface elements that look nice and animate well. While there is certainly a place for those things, this pattern helps one understand that is when you have all of the parts of your application finalized.


I should have learned this lesson last semester with my final project. I spent so much time fiddling with the color palette and page animations, that the content on those pages was barren, or poorly formatted. It is nice, I think, that my webpage looks and animates nicely, but when pages break upon reloading then it hardly matters. If there is constantly some expectation of failure with a project, then the font you choose is hardly relevant. I think that is what this pattern helped me realize most about this weakness of mine; utility is the most important aspect of software, everything else is so much fluff.



From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.
					

		
		
	

							
	

				

			
						

				Apprenticeship Pattern Review 2: The Deep End
			

								


				

			
“The Deep End” is another extremely useful pattern taken from Apprenticeship Patterns. This pattern is best used when you feel as though you are stuck in a rut and not much progress is being made to further your software development career. In order to save yourself from a career of mediocrity something must be done. “The Deep End” prescribes the developer to set aside fear and jump into a project greater than anything they’ve done before. While this could end in failure, even failure is a better outcome than never starting in the first place since so much knowledge will be gained in the process. More often than not, it seems as though jumping into a project that seems too complex or too large when compared to previous work tends to be the best way to supercharge your learning.


I agree with this pattern wholeheartedly. I have already acquired countless examples in my relatively short career of software development where forgoing my fears and jumping into a project that I didn’t know I could complete helped me get out of a rut. One of the hardest things for me to remember is to keep jumping into “the deep end” whenever I can instead of getting into ruts of self doubt and fear. I also agree with Hoover and Oshineye that while this notion of “the deep end” is a key to becoming a software craftsman, one can not blindly jump into a project that is way beyond their comprehension and expect to swim. It is extremely important to take into consideration the prep work and skills at your disposal when deciding if an opportunity is right for you. While I do think the idea of recording the size of projects you have worked on could help when utilizing this pattern, I don’t think its necessary. Instead of getting bogged down by wondering if the project you want to work on is bigger or more complex than the last I think the most important thing is that you take the leap and start working on the projects that can propel your career forward.


This pattern will stick with me because I’ve seen it work in my own career previously, yet I’ve never had a concrete pattern to remind me of it. It will come in handy when I’m working on my capstone project. It’s imperative that I never let fear get the best of me and I instead choose to continue working through problems that I think there’s a possibility I fail at. I will keep this pattern close at all times and whenever I feel like declining an opportunity because of fear I will remind myself of “The Deep End”.


 



From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.
					

		
		
	

							
	

				

			
						

				Confront Your Ignorance
			

								


				

			
This week, I’d like to discuss the next step from last week’s apprenticeship pattern. Once you’ve exposed your ignorance to others and realized it yourself, you have to own it and fix it. If others can’t help you, you’re on your own.


This pattern can be used in isolation, without showing others. This is helpful if it’s something very basic which would be embarrassing to admit to, or something you lied about knowing, which is never a good idea. The downside to learning on your own is an isolationist mindset. In a team where everyone is working on their own, this could create a culture where ignorance is frowned upon.


I generally agree with the ideas in this pattern. It is good to keep its downsides in mind, especially since I know I generally prefer to learn on my own. Sometimes, it is simply more efficient. In college, I’ve saved about 2 semesters’ worth of time (and money) by taking CLEP exams, learning the material on my own. For some subjects, it’s simply much more efficient to create my own study guide, find the gaps in my knowledge, and fill them in.


The result of doing so has been much clearer, broader, and more detailed understanding of the subject matter as a whole than I would have otherwise had taking a class. Taking a single exam held me more accountable than a class generally does, which is broken up into smaller assignments with the goal of preparing you for the final exam.


This would never be the case for learning to work on a software team, as we are in our software development capstone. Reading about Agile won’t make you an expert in Agile. Collaboration is a practice.


While not always ideal, I think this pattern can be extrapolated to professional applications. If you’re learning a technology on your own, you don’t know what someone might ask of you. The pressure is on to learn as much as you possibly can. If your goal is to appear as knowledgeable in a subject as possible, this pattern might be the way to go.


The warning against taking this pattern to the extreme is valid in cases of working with a team. It is important to use discretion when choosing between exposing ignorance to others, or confronting it on your own. I plan to lean toward exposing ignorance and asking for help in the future.



From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.
					

		
		
	

							
	

				

			
						

				Craft over Art
			

								


				

			
For this week’s pattern I have chosen “Craft over Art”. It describes of the pattern where you are given a problem and you are solving it for a customer. You can do it the simple and tested way or create a new solution that will let you express yourself as a programming artist and will look nice on the resume. It describes the conundrum of making something simple and useful right away or making something beautiful and complicated and not usable right away.


I have chosen this pattern because I have struggled with it many times before in my professional career. Many times have I been given a problem to solve for a customer and I had to decide to make it the quick and easy way that I already know will work, or should I do it some new, more complex way that can possibly save some time in the long run. The way that the “Apprenticeship Patterns” describes it should be done with a mix of both solutions, make it somewhat easy but tested way but with possible improvements. I think this is a good approach but there is a catch to it in my opinion, what is acceptable to the customer? Can they wait for a different, nicer way or quick, not totally efficient way will suffice? I think in the moments like that it is up to a Project Manager or the customer to decide and anybody working on this should act accordingly.


We as programmers and developers are in the end a service providers, unless we work for ourselves and do not have any hard deadlines, we need to stick to timelines and or project deadlines. What works and is tested very often is the right solution because time spent on implementing new solution can be something that ultimately may cause a project to fail and nobody wants that. The book also says that we as craftsmen need to provide at leas a minimal level of quality, and I think that if something is well defined and tested and works has that kind of quality. Why go for a new fancy way that might now work 100% of the time, or it requires a lot of time to be understood by somebody else. My boss likes to remind me that “if it is not broken do not fix it, because you will only cause more headaches to yourself and somebody who will work with my code later”.



From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.
					

		
		
	

							
	

				

			
						

				Pratice makes permanent
			

								


				

			


Apprenticeship Patterns is a really interesting book to read and I actually learned a lot from it. For this week, I read about the pattern “Practice, Practice, Practice” and there are a few interesting things I found about it. The pattern starts with a quote by George Leonard saying that masters they don’t just get better by devoting in a particular skill, but they practice getting better and the it gets more enjoyable to perform basic moves over again once they are better. I can definitely agree on this as I think we all have been through a rough beginning of doing something, but when we are better, we would think back how easy it is to do those basic task and we would do those rather than more complex problems that we have to face later on during the process of mastering a skill.




Then the author went on to talk about practice is a long process and it has to be done without interruption, and in a comfortable environment of making mistake. At this part, it is interesting to learn that practice in software development can be in a stress-free and playful environment. For me, I always think that the best way to practice is to join a group project, and there would be one or another thing that would stress me out so easily like if I work in a small group or alone even on a small size project, at some point we would be overwhelm with the amount of work that we have to deal with, or too much concern about security, features, accessibility, etc. and after reading this chapter, it makes me question about my priority on different aspect of the program and maybe I should change in order to get better. 




The author also brings up another interesting point is to try to do a bit different for each time we practice and choosing the right thing to practice is very important. In my opinion, I think that should be the most optimize way to discover new things and not to miss out any important things while we are still on the basic level.





From the blog #Khoa'sCSBlog by  and used with permission of the author. All other rights reserved by the author.