Category Archives: Week 9

Breakable Toys

Those describing the Breakable Toys apprenticeship pattern assert the importance of designating a safe-space for failure. But we must accept there is no room for failure on the job. In a professional working environment, many expect us to produce material that works every time. But as depicted in this pattern’s description, failure is necessary in order to grow.

Building breakable toy projects can be a great way to contain, evaluate, and improve upon one’s failure. The idea is to personally design something “on the side” that emulates one or more features you’re working on professionally.

I’ve somewhat already applied this pattern throughout the course of working on the AMPATH project. I’ve developed a few “breakable toys” of my own with the intention of better understanding specific Angular capabilities. My reasoning is as follows: AMPATH uses many Angular functionalities I was previously unfamiliar with. I quickly began to realize I have a whole lot of learning to do.

The concept behind the Breakable Toys pattern seems practical for any Software Developer. In fact, I wouldn’t be surprised if the majority of all programmers have created at least one breakable toy or another. I base this on my personal experience with breakable toys. They have definitely given me a better understanding of the “big picture” behind the AMPATH app. When working on a large project, breaking it down into pieces can give us a better understanding of its overall functionality. We can feel confident evaluating the features in a breakable toy through trial and error. If the toy breaks beyond recognition, its okay. Whereas breakable toys are disposable, large open source projects like AMPATH are not. It seems a lot safer to evaluate functionalities in an isolated space first.

I would also like to mention the specific action suggested by those describing the Breakable Toys pattern. Personally constructing a wiki from scratch is proposed. I feel this will be very beneficial for me in my future endeavors. Building wikis appear to be great breakable toys to experiment with; we can use them to explore fundamentals such as concurrency, HTTP, REST, and general web development. As I begin transitioning to my professional career, these are fundamentals that I certainly need to become more knowledgeable in.

I’ve recently purchased a website domain and hosting space from InMotion. I don’t have anything on it yet, but my eventual goal after I graduate is to build my own “breakable toy” wiki. I want to do this to become more familiar with web development tools and prepare for job interviews. Further, I am hoping to showcase everything I’ve learned about the AMPATH project in this proposed wiki to help others in the future.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Learn How You Fail

This week, I read the apprenticeship pattern “Learn How You Fail”. To quickly summarize, this pattern asked you to stop looking at your successes and start actively seeking your failures and weaknesses in order to learn from them. I really liked the message behind this pattern because it is different from what we are accustomed to. It is normally very easy to focus on getting better at something you are mediocre at, and even easier to focus on getting better at something you are great at, but it is really difficult to confront your shortcomings and approach what you are terrible at. My interpretation of this pattern was that it doesn’t seek to discredit the good aspects of your skills but rather putting a focus on the bad as to make you a better engineer overall.

This is another applicable pattern for me personally because I still have a few areas of weakness in my development skills, even in some of the technologies and languages that I’ve been using many years. I have caught myself opting out for a simpler but worse performing option because I didn’t want to confront an area of weakness needed to implement the better solution. The other key aspect of this pattern in accurate self assessment, asking yourself “am I really this good at X, or is there major room to improve there”. I often find that we normally give ourselves the benefit of the doubt and say “Yes we are that good”, and this closes out any potential opportunities to actually improve. What this pattern teaches is to really ask and assess deeply and even ask for an external opinion (via peer review) for areas of weakness.

I agree with this pattern and I plan on implementing this going forward in my career. This pattern should be fairly easy to apply because of its practicality. If you are weak in a skill that will no longer needed, the pattern suggests that you shouldn’t waste your time with that and focus on more important areas of weakness. The only challenge to applying this pattern will be the reluctance to do what we are not good at, but I believe that overcoming this will be much easier if we think about the benefit that will come from fixing our weakest links.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

The Beginnings of my Map

I’m typically not much of a long-term planner. While I have defined some goals and aspirations, they sometimes seem more like rambling dreams than achievable objectives. Although I may know what I want, defining actionable items for getting there is a different and far more challenging accomplishment. I like to make the most of every day, doing the best that I can and hoping that hard work and positivity will take me somewhere amazing, wherever that may be.

Much like the story told by Desi in the Draw Your Own Map pattern in Hoover and Oshineye’s Apprenticeship Patterns, I have begun my Information Technology career in a sort of hybrid role in Systems/Application Administration. The differences between my experiences so far, thankfully, have been far different from those described by Desi. Rather than facing pressure to concentrate only on furthering the interests of others, I am encouraged to create a valuable experience for myself.

While I am well aware that it is not the responsibility of anyone else, employer, professor, or colleague, to give me a hand out, I am extremely grateful for all of the support that I have received in that regard. I feel as though I have a good sense of my career position  and potential options for the future because of the support that I’ve received and the experiences that I’ve had.

Although I see absolutely no need to consider other paths at this time, the Draw Your Own Map and the stories shared by Desi and Chris were somewhat reassuring. It is comforting to know that even if there comes a time when it may feel like it, you are never really stuck. I feel extremely grateful to currently be in a position where my goals and desires for professional advancement are not only heard and considered, but seem to be top priorities. I am in a supportive, flexible environment, where I’m encouraged to set and work to achieve goals for personal and professional growth, development, and learning. Right now, the possibilities and prospects seem to be wide open. The next step for me is to use this opportunity to discover the values that are important to me.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

SPRINT 3

Team Retrospective – Sprint 3

Overview : 

          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 ! 

 

 

 

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.

Apprenticeship Pattern – Breakable Toys

The pattern “Breakable Toys” can be found here: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch05s03.html

This pattern is a little longer than some of the other patterns I have looked over. Long story short, Breakable Toys is a pattern designed to help you learn. Kind of like Be the Worst but is more focused on you as an individual. The problem is that you are working in a company that can’t afford errors to destroy their data/program/whatever (who can afford that?).  However, the other half of the problem is that you are just learning this stuff and need a safe space to practice. You should create your own safe space project that relates to the problem you need to solve in the company, just at a smaller scale. This pattern tells you you need to build these breakable toys from the ground up to learn the insides and outs. Once you have these breakable toys, they are yours forever to use with other jobs and problems.

I thought this pattern was very useful. I was always told that if I want to learn, I have to do. That’s what this pattern is saying. You have to take the initiative and build these projects in order to learn. The best part is, failing only harms your breakable toy, which you built specifically to be broken!

The first line says “If experience is built upon failure as much as success, then you need a more or less private space where you can seek out failure.” (Oshineye, Hoover) I love this first line because it tells you that failure really is okay. That is how you learn. Being successful on the first try only teaches you what works for this situation but not for others. If you fail, you can learn a whole bunch about what doesn’t work and what does work. I don’t think you should intentionally fail, but failing will help you improve your skills and knowledge (so don’t feel too bad). The most important part about failing is getting back up and trying another approach. I could definitely see myself using this in my intended profession. I get worried all the time about breaking things that are important and this pattern gives you a way around that.

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Sustainable Motivations

I think most people would say a career in software development is a pretty damn good choice to make. The field is growing at a rapid pace and jobs within the field typically come with high paying salaries and flexible hours. Because of this, it can be easy to find yourself complacent in your current position and lacking the motivation to continue to learn new topics. You may find yourself thinking “I’m making a six-figure salary and I am very comfortable with my current position. Why would I go out of my way to learn new material?” The pattern Sustainable Motivations in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye discusses some ideas on how to prevent/get yourself out of this trap. It also discusses how to avoid some other situations that could potentially prevent you from mastering the craft.

The key to becoming a master software developer is to keep yourself motivated [AP]. As I mentioned earlier, sometimes this motivation can dwindle [AP]. The pattern suggests to keep a list of things that you are motivated by to help remind yourself of what is truly important to you [AP]. I think that this is a great idea. It allows you to keep reality in check. Everyone needs that once in a while. If being considered an expert in your field is on that list, then you should do all in your power to prevent yourself from becoming complacent. If it isn’t and you truly feel that your motivations have changed being an expert is no longer a priority than that is ok. Just don’t give yourself that false intention of wanting to be an expert when in the back of your mind you know your motives are in a different place.

The other thing to keep in mind if you find yourself questioning your motivations and/or if you still want to be in the software field is to simply give it some time [AP]. There are going to be bad weeks at work. There are going to be weeks where you are working nights and weekends to meet a deadline that you knew from the beginning wasn’t realistic. There are going to be weeks where you question management’s decisions. I can go on, but you get the point. Not every week at work is going to be all hunky dory. Be mindful not to make a life changing knee-jerk decision that you may regret. Give it some time and your motivation will probably return.

 

Link to pattern in book: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch03s03.html

 

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

CS@Worcester – Fun in Function 2018-03-14 19:50:39

I wasn’t sure if “Share What You Learn” would be applicable at my current level of experience for exactly the reason the writers give for why apprentices might have doubts about the pattern: I assumed this sort of thing should be left to people who know exactly what they’re doing. They brought up points I hadn’t considered in response to this. An apprentice’s minimal knowledge will make their explanations short and to the point, and they won’t make the mistake of assuming the people they’re sharing with have prior knowledge that they don’t. This makes their explanations, in some ways, more useful to other apprentices than an explanation from a journeyman or master.

The benefit to the apprentice sharing what they’ve learned is something I acknowledged in my blog on “Record What You Learn”: the best way you can learn something yourself is to teach it to someone else. The writers mention this benefit, but they also warn of several ways that applying this pattern can end up doing more harm than good which I hadn’t considered. Sharing your knowledge might get you into legal trouble if what you’re sharing is a trade secret, or sharing particular information may actually be harmful to others. You should be careful about what you choose to teach others, and if no one else seems to have explained it, you should consider why. Other concerns include that people might feel as though you’re bragging or explaining concepts in condescending ways if you’re not sharing with humility, or they might assume you have an ulterior motive. Conversely, the writers assert that it’s selfish to seek ways to better your own learning and not consider how others could benefit if you were to share what you know.

They suggest developing a habit of applying this pattern early on, but I still don’t feel like I’m ready to offer anything substantial. If in the near future I learn something I identify as significant enough to record it, I will remember to apply this pattern as well and write an introduction to the topic that others might find useful.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Post #23 – Ampath Application Development – Sprint 3 Retrospective

Our team is currently tasked with creating an offline password-encryption service for the Ampath application.  After consulting with the people at Ampath, we made the decision to devote this sprint to creating test-applications that utilize the 3 encryption-libaries we discussed with them.  Unfortunately, our meetings were interrupted again this sprint; 2 of our 4 meetings were cancelled due to snow.  The days that we did meet, we spent a majority of our time coding and discussing our progress.

I was tasked with creating a test-application that utilizes the encryption libary bcryptjs .  Bcryptjs uses salt and an adaptive function to improve security and its implementation purely in JavaScript provides resistance to brute-force attacks.  I was the team member who suggested bcryptjs, when we compiled options to discuss with the Ampath people, so it felt natural for me to be the one writing the test application.

I did run into some trouble, though –  all of the resources and APIs for bcryptjs are tailored to JavaScript, rather than TypeScript.  This has been quite an impediment for me as I am not proficient in JavaScript, so I have had to learn a bit of JavaScript at the same time as I develop this test-application.  We are using WebCharm to work on development for the application, and WebCharm has a tool to compile TypeScript to JavaScript, and I have been looking into whether it is possible to compile JavaSvcript to TypeSript.  As I mentioned earlier, 2 of our 4 meetings were cancelled due to snow and I was without power for 3 days of the sprint, so I was not able to troubeshoot and push through this problem in time.  The issue of being unfamiliar with JavaScript, as well as installation and compilation errors, has also been afflicting my teammates – nobody was able to produce a working test-application by the end of the sprint.  Spring break is coming up and, while we are not required to work toward sprint goals during break, I intend to try and get myself up to speed with Angular, JavaScript, and bcryptjs so that, upon our return to school, I will be ready to make a meaningful contribution toward meeting this goal for the Ampath organization.

It definitely felt like all the teams had much more direction during this sprint.  We have begun implementation and feel more familiar with the application itself.  Our team has been using our in-class meetings more efficiently and I think we all have more of an idea of each other’s working-pace.  I feel a bit worried about the fact that my teammates and I feel unsure of ourselves within JavaScript, because I think it will be hard for us to have to learn JavaScript at the same time as we work on the Ampath application.  I’m hoping that Spring break will allow us to gather ourselves and come back more productive than ever.  I have still enjoyed working on the application, so far, and I hope that we can make some sort of meaningful contribution(s).

From the blog CS@Worcester – by Ryan Marcelonis and used with permission of the author. All other rights reserved by the author.

Thoughts on “Learn How You Fail”

The “Learn How You Fail” blog pattern is about finding the ways in which you tend to fail or make mistakes.  The solution does not claim to save a programmer from ever failing (that’s not possible), but is instead about learning what tends to lead you to failure.  It’s part of drawing accurate boundaries around yourself as a learner: figuring out where you can grow and improve, what tends to throw you off track, and what may not be worth the effort of improvement.  The authors have a very concrete action step to help: using only a text editor, write an implementation of a simple algorithm, write all of the tests, refine the algorithm until you’re sure it will compile and pass the tests, then actually try to compile and test it to see where you failed.

Learning my weak points, where I tend to make mistakes, is a big part of my life as a gamer.  I try to improve my performance (whether that’s technical gameplay, strategy, tactical decision-making, etc.) with every game.  A very important aspect of that is determining what kinds of mistakes I tend to make.  Where do I overthink?  Where do I underthink?  What can I take away from losses, and when is it worthwhile to acknowledge but let go of a weakness (at least for a while) to focus on something else?

This apprenticeship pattern also resonates with me for a different reason.  I struggled through much of middle and high school with a mild nonverbal learning disability.  It took years of practice and tutoring for me to really be able to work through it.  An important part of that (or, I think, any therapeutic process) was finding points of failure.  I struggled to express myself in writing, especially meeting word counts for papers.  I had (and still have) difficulty breaking focus or task-switching.  Recognizing these things was the first step to improving them.

I think that learning how you fail is not just a skill that’s important for software apprenticeship and craft.  It’s an important life skill; at least, it has been for me.

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

Sustainable Motivations

Problem

Working in the trenches of real-world projects is rigorous, sometimes tedious, sometimes exhausting, often frustrating, and frequently overly chaotic or constraining.

Solution

The text suggests ensuring your “motivations for craftsmanship will adapt and survive through the trials and tribulations of The Long Road.” You must develop your technical skills because you will often find yourself working with “ambiguously specified projects with customers with shifting and conflicting demands.” There are times when you’ll love your job but there may be days, weeks, or months when you may question you motivation to the craft. Your job will present you with tedious, vague defined, and needlessly complex problems and you may have to deal with bureaucracy, difficult personalities, and spotty leadership.

…there is not much overlap between the kind of software that makes money and the kind of software that’s interesting to write…. If you want to make money, you tend to be forced to work on problems that are too nasty for anyone to solve for free.

—Paul Graham, Hackers & Painters

In More Secrets of Consulting, Dorset House, Jerry Weinberg describes this phenomenon as the Golden Lock: “I’d like to learn something new, but what I already know pays too well.” The risk of the Golden Lock highlights the importance of The Long Road, which requires ambition to attain mastery.

I think this pattern has good insight on maintaining motivation to become a software craftsman. It had some interesting examples explaining why you should avoid getting stuck in the Golden Lock, where you may find yourself not enjoying what you do but may stay there because you are making good money. It’s important to keep balance your passion and other aspects of your life, this ties into the “Nurture Your Passion” pattern. Another good tip from the pattern is the importance of developing your skill because you will be working with a variety of people who may not understand things at the same level or might make your job harder. I believe this pattern will help me in my professional career, it’s a good reminder to learn new things, work with different people, and to sustain my motivation to avoid burnout or Golden Lock.

 

The post Sustainable Motivations appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.