Category Archives: CS448

Apprenticeship Pattern – Expose Your Ignorance

The apprenticeship pattern “Expose Your Ignorance” refers to the scenario in which you’re assigned a project but you are unfamiliar with some of the technologies that are required. Under the expectations of your colleagues, you may feel pressured to hide your ignorance so as not to seem incompetent as a developer. The best course of action, however, is to tell people the truth.

I can see why people might be uncomfortable with the idea of exposing their ignorance. However, I think that anyone who is more interested in actually becoming a better developer rather than focusing on what kind of developer they’re perceived as would be able to agree with this pattern. Sure, you could choose to pretend that you have the knowledge to complete any task already and then try to learn those technologies on your own, but there’s no guarantee that you’ll be successful. If you promise to deliver something and then later have to admit that you’re less knowledgeable than you initially let on, then you’re going to end up worse off. By admitting that you’re inexperienced with certain required technologies and asking questions, you’re able to show that you’re capable of learning while also being able to learn much faster with the assistance. One common phrase that I see commonly used is to “fake it till you make it”. I don’t doubt that there are some people who will look down on you for exposing your ignorance, but as long as you continue to focus on learning as effectively as you can, then you’ll be much better off in the long run.

One of the things I found interesting in the excerpt was to write down five things that you really don’t understand about your work and to put it where others can see it. This is definitely an extreme way of exposing your ignorance, but if people who see it are able to answer your questions and cross off an item on the list, then you’ll improve far faster than if you were to try to do the research alone. I’m not saying that you shouldn’t try to solve problems on your own, but it’s in everyone’s best interest to seek advice whenever they feel like they lack knowledge.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Your First Language

The apprenticeship pattern “Your First Language” is a pattern that specifically focuses on people who are just starting out and only have a shallow understanding of one of two programming languages. For people in this situation who don’t feel like they have very in-depth knowledge in any particular language, the solution is simply to pick a language and become fluent in it. However, what language should you choose?

I think that this pattern pretty interesting and still somewhat relevant even to people who are comfortable in a specific language. For me, even though I feel that I’m pretty comfortable with writing in Java, I can say without a doubt that I’m still very inexperienced and will run into problems that I’ve never encountered before. According the the pattern, one of the most fundamental ways of improving your experience with a language is the solve an actual problem with it. Being able to encounter roadblocks naturally and discovering a solution to it is something that you won’t be able to effectively recreate through learning from small, self-contained examples in learning resources.

One thing that stood out to me in this pattern was what was considered the most important factor in choosing your first language. It states that you should choose a language that someone around you is an expert in. By having someone with that expertise within reach, you are able to learn at a much faster rate than if you were trying to learn it by yourself. Preferably, you would be able to work on a project with them using the language regularly, but as long as you can get feedback from them, it will still be immensely helpful. While I think that this should definitely be the major factor in your decision, I’m sure many people may not know an expert of a language that they would feel comfortable enough working with or seeking feedback from. For those people, it’s important to seek out those opportunities and expand your network, but I suppose that’s easier said than done.

Overall, I feel that for those in that situation, this pattern is something that should definitely be followed if you want to learn as quickly and effectively as you can.

Source: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch02.html#your_first_language

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns

After reading Chapter 1 and the introductions for Chapters 2 through 6 of Dave Hoovers and Adewale Oshineye’s Apprenticeship Patterns, I feel that I was really fascinated about some of the topics and ideas that I saw.

Entering the industry following the ideas of being an apprentice (not necessarily in the literal sense or an actual apprenticeship program) is something that I think is really interesting as well as being a good mindset to have regardless of where you are in your career. As was stated in the reading, many of the patterns many not apply as much to you depending on your experience, but I think having the mentality to constantly seek to improve yourself is something that really applies to every part of life.

The story about the Zen master and the young philosopher in the introduction to Chapter 2 was really interesting because the idea of “emptying your cup” in order to open yourself up to different approaches is something that would be difficult to do without a strong self-awareness. I think that for many people, reading this could be the first step in reaching a point where you’re able to put down your pride and your past experiences/habits and just listen. If you were to act like the philosopher in the story, you’re not as likely to have more experienced colleagues want to continue to teach you. I imagine most people aren’t as patient as a Zen master.

The idea of perpetual learning brought up in the introduction to Chapter 5, while a good mindset to have throughout your entire career, is something that is really important for people who will soon enter the industry (or even before that). To someone about the start their career, if you begin your journey following this path, then you’re sure to be able improve and find yourself in a much better position that if you didn’t. If you don’t focus on improving yourself early on, you might end up stagnating and finding that after years in the industry that you’ve been standing still the whole time.

Overall, these readings have been immensely useful in improving my mindset. I can see why this was assigned at a critical point in the Computer Science curriculum. I can also see why people would end up reading the whole thing, because I’m sure that learning about many of the patterns found in this book will continue to help me in the future. Once someone finishes up their degree, there will no longer be any external force pushing them to continue learning, so being able to continue to seek out knowledge is something that you’ll have to do on your own. Finding topics to study that interest you and will help to improve yourself is something that shouldn’t be overlooked.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Be The Worst

The apprenticeship pattern “Be The Worst” refers to the situation where you’ve outgrown your team and possibly your entire development organization and now you’re no longer learning at a rate that is acceptable to you. The solution to this is the find another group made up of developers where you are the weakest member so you have more room to grow. The quote used in the article to represent this is “Be the lion’s tail rather than the fox’s head!” Another quote that emphasizes this idea is “If you’re the smartest person in the room, you’re in the wrong room.”

I think that while it’s true that being surrounded by developers who are smarter or more experienced than you will definitely accelerate your growth or learning, if everyone followed this idea then the “junior” team members wouldn’t have anyone above their experience level to learn from because they would have already moved on to greener pastures. That being said, everyone doesn’t follow this pattern. There are likely many experienced developers who are happy with the level that they’re at and have no interest in switching teams giving less experienced members of their team a mentor to learn from.

Reading this pattern hasn’t really changed my mindset, as it bears some similarities how I had already thought about my intended profession, albeit a little more extreme. While I agree with the pattern as it refers to switching teams when you feel like you’re no longer growing, I feel that it can potentially be an unhealthy mindset to have. I think a better mindset would to start looking for new opportunities once you’re no longer satisfied with your work. The wording here is very similar to the original pattern, however it also takes into account those who enjoy their jobs, even if they might not be learning as fast as they could be had they joined a new team.

Overall, while I’d say that following this pattern would likely accelerate your growth, I don’t think it’s the be-all and end-all solution to a successful and rewarding career. Being the “smartest” person in the room doesn’t mean you have nothing to learn, especially when it comes to learning how to be a good mentor.

Source: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch04.html#be_the_worst

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

CS-448 Introductory Blog Post

This is my introductory blog post for CS-448-02 Software Development Capstone.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Sprint 5 Retrospective

From the blog CS@Worcester – BenLag's Blog by benlagblog and used with permission of the author. All other rights reserved by the author.

Sprint 4 Retrospective

Highlights

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.

Looking Forward

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. 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

PATTERN : Sustainable Motivations

Sustainable Motivations

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.

Personal Reflection

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 !.

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

Intro – CS 448

Hello Everyone in Cs-448  !

My name is Kwame ofori and i am really looking forward to this class and getting some real world experiences. I believe experience is the best teacher so i am ready to learn !

 

 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

The Software Craftsman Ch. 7 and Ch. 8

Chapter seven, entitled “Technical Practices,” covers the topics of ideal programming practices and why they should be utilized in the field.  Of course by best practices I’m speaking of TDD, CI, paired programming, etc.  These are the topics that have been covered at length in The Clean Coder and my related blogs.  I found it interesting that Mancuso has a separate section for refactoring outside of TDD.  For those who are unaware, refactoring is a step within test driven development.  Therefore, if TDD has been utilized, then there is no need to explicitly describe refactoring.

Chapter eight, entitled “The Long Road,” is an interesting chapter about career choices. We all know that money is a motivating factor when making career choices, but taking money out of the equation leaves you with the following three factors:

Autonomy: It is when we are in control of what we do, how we do it, and when we do it. That should always be the case in a true Agile context.

Mastery: It is when we are constantly learning and evolving—becoming bet- ter professionals and better human beings.

Purpose: It is when we feel that our job is important and we are contributing to make things better—instead of just doing what we are told without under- standing why.

Once we get a grasp on where we want our careers to go, and what factors motivate us, it is easier to find the right jobs.  This doesn’t just happen, it requires a lot of work and effort in order to “craft” our careers.  Mancuso thinks it is important to differentiate between a career and a career within a company.  Your career is more important than a career within a company.  I think that your career and your career within a company are equally as important, and should more often than not align, but then again I have not worked in the field.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.