Author Archives: Ryan Marcelonis

Post #30 – Reflection on the “Sweep the Floor” Pattern

This week, I will be writing a reflection on the “Sweep the Floor” pattern.  This pattern addresses apprentice software developers that are unsure of their place on a new team but want to contribute to the team’s work and earn their trust.  I chose this pattern mainly because the title caught my eye, but also because I think it could come in handy for when I begin my internship, working on a small development team, in June.  Oshineye and Hoover provide solid advice on how to make meaningful contributions to a team by volunteering to perform simple yet necessary tasks.

Some tasks you can complete to promote the early success of the team might be maintaining the build system, setting up the project wiki, updating documentation, code reviews, etc.  They describe these tasks as residing in the “edges” of the project where there is less of a risk of damaging causing damage to it.  The reason that this pattern is called “Sweeping the Floor” is because it refers to the fact that, while sweeping the floor might seem like a mundane and tedious task, it is necessary to the upkeep of any building – and somebody has to do it.  Simple and/or tedious tasks benefit not only the team but also you as an apprentice, because “chores” are often overlooked in academia but doing them fills the gaps in developers’ knowledge.  Oshineye and Hoover raise an interesting point by saying that education means less than college-graduates might think, because everybody starts at square one when they join a new team and, as a developer on square one, taking on mundane tasks is very helpful.

They go on to explain some of the negative consequences that could occur when applying this pattern in the field.  The first negative consequence could be that you might become the team’s “gopher”, the go-to person for mundane tasks, for the duration spent working on the project.  A second negative consequence that could result could be that you no longer feel confident tackling tasks that aren’t like your regular “sweeping the floor” tasks.  There is also the possible negative consequence that you don’t develop an appreciation for the bigger picture while “sweeping the floor” because you aren’t gaining a wider coherence.  Oshineye and Hoover recommend that developers facing any of these negative consequences refer to the “Nurture Your Passion” and “Unleash Your Enthusiasm” patterns.

To implement this pattern, Oshineye and Hoover advise apprentice developers, who are new to a team, to tackle the tasks that everybody else would complain about.  Not only should apprentice developers tackle those tasks, but they should also approach them with creative solutions to exceed their team’s expectations and make the situation fun and rewarding.  I think this pattern will be a useful reference in my repertoire and I hope to implement it in the field, this summer.

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

Post #28 – Reflection on the “Practice, Practice, Practice” Pattern

This week, I will be writing a reflection on the “Practice, Practice, Practice” pattern.  This pattern addresses developers who want to get better at programming and to expand your diversity of concrete skills.  I chose to reflect on this pattern because I recently accepted an offer for a summer internship and I intend to put in quite a bit of practice before I begin working in June.   Oshineye and Hoover provide solid advice on how to exercise programming skills for those in the ideal situation of having a mentor and those who are left to their own devices.

They begin by saying “Take the time to practice your craft without interruptions, in an environment where you can feel comfortable making mistakes”.  I think environment is a very important element in getting the most out of practice.  The environment in which you practice should allow you to focus completely on the skill you are trying to improve.  Ideally, this environment would also include a mentor that can help guide your practicing and gauge your progress.  Personally, I think an ideal environment could also include peers who are also developing their programming skills because it would provide more outlets for each individual to discuss their work and mentor one another.

They go on to say that the key to this pattern is finding time to develop software in a stress-free environment with no due dates production issues, or interruptions.  This pattern, like the “Breakable Toys” pattern, also stresses the importance of short feedback loops in practice sessions.  Short feedback loops refer to the cycle of completing exercises and quickly receiving feedback on your performance for the purpose of gauging a person’s progress toward a goal.  Short feedback loops can be found in the form of feedback from a mentor or in your own incremental completion of progressively more difficult tasks.

To implement this pattern, Oshineye and Hoover advise developers to find exercises or create their own, and ensure that those exercises will challenge them to at least some degree higher than what they know they are capable of.  They also advise that you should solve and resolve the same issue over some period of time, so that you can see how your solutions change and progress.  I have been motivated by this pattern and I intend to implement it in the coming weeks as I prepare for my internship.

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

Post #27 – Reflection on the “Dig Deeper” Pattern

This week, I will be writing a reflection on the “Dig Deeper” pattern.  This pattern addresses developers who feel that feel that they only possess a superficial knowledge of some of the technologies, tools, and techniques utilized at their workplace.  The problem that arises, in this scenario, is that the developer begins having trouble with maintenance of his or her code because it was written with only superficial knowledge that is likely to be forgotten.  I chose to reflect on this pattern because I really like the advise that Oshineye and Hoover provide about how to truly immerse yourself into the learning process and transform your superficial knowledge to deep knowledge.  I also agree that having a deeper understanding of the everyday things in your life can be incredibly beneficial in a number of ways.

The primary importance of deep knowledge is that allows you to explain the inner workings of systems you work on, which will distinguish you from colleagues that are unable to do so and show others that you are more proficient in working with that system.  I recently had an interview for an internship and many of the questions I was asked were related to my contribution to and understanding of past projects.  The recruiter got back to me a short time after the interview and informed me that I ‘knocked the interview out of the park’ and I was offered the position – I accepted!  Oshineye and Hoover explain that deep knowledge can also act as a safety net in that you can refer back to how you gained your deep understanding in that area to gain confidence about learning something new.

They recommend that developers ‘dig deep’ into the tools and technologies involved in the project they’re working on, until they have a deep understanding of how those tools and technologies work and why they are being used.  One of the ways somebody can dig deep into something is by getting their information from primary sources.  Primary sources understand the problems they were trying to solve.  Another way somebody can dig deep is by looking at tutorials and guides regarding the thing(s) they want to learn, and asking themselves if there are underlying computer science concepts behind what you they are learning.

I think this pattern will prove to be a useful piece of knowledge in my repertoire.  I will try to apply it regularly in my career and I strive to become a person who truly understands the tools and technology utilized in the software I am working on.  I have used this pattern and seen it work, first hand, and I hope it will lead me to more success in the future.

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

Post #26 – Ampath Application Development – Sprint 4 Retrospective

Last sprint, we were tasked with creating test-applications that utilized a few different encryption libaries, so we could get an idea which library would be the best to use for the implementation of offline-encryption.  We didn’t really finish doing that by the time this sprint began, so we decided to keep some of those tasks on the sprint backlog to continue working on them this sprint.  I spent the first half of this sprint researching and implementing encryption using the bcryptjs encryption library.  This sprint was divided by spring break, during which I mostly took a break from school work.  I did, however, do some refreshing of programming in JavaScript.  This refresher made me feel much more comfortable coming back from spring break.  I expressed my confidence in bcryptjs to my teammates, and presented them with a mock encryption service that I wrote.

The test-application that I made demonstrated bcryptjs’s usefullness in encrypting passwords, but my teammates were curious how the library would handle encrypting other kinds of data that we may experience within the Ampath application.  We came to the realization that bcryptjs is useful and easy-to-use for password encryption, but lacks functionality for encrypting other kinds of data.  We decided that this would be problematic, effectively eliminating it from our choices.  We communicated well and discussed our remaining options with a sense of direction we hadn’t had in the previous sprints.  After further research, we came to the agreement that we would run with the encryption library crypto-js. We began looking at resources for crypto-js and wanted to begin testing some implementation.  We also discussed potential strategies for dividing the work that we must do among our team members.  We do not have a solid plan in place right now, because we were unsure if it would even be necessary to divid the task among all member of the team.  During our next sprint-planning meeting, we intend to talk more about the division of labor and how we intend to move forward with implementation and avoiding compilation issues.  Unfortunately, when me, Erik, and Oren tried to run our application on the last day of the sprint, we all had the same compilation errors, despite having not changed any code since the week we worked on it.  We spent the remaining day of the sprint troubleshooting this issue, to no avail.  Shane and Caleb, members of the ‘Everyone Else’ team, recommended that we try running the command ‘npm rebuild’ in the WebStorm terminal, which is what he and his team members did when they encountered this issue.  I have not tried this solution out yet, but I intend to in the next sprint.

I feel that we made some real progress this week.  We were able to successfully agree upon the best-fit library for our task, and we began troubleshooting errors so that we can get back on track to implementing offline-encryption.  I feel much more comfortable with our strategy than I have been feeling in the previous weeks, and I feel very motivated moving forward.

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

Post # 25 – Reflection on the “Your First Language” Pattern

This week, I will be writing a reflection on the “Your First Language” pattern.  This pattern addresses those are seeking a job in software development but obtaining said job requires a proficiency in a specific language and/or developers who feel comfortable in one or two languages but are expected to maintain the same standard of quality as their teammates/coworkers.  I chose to reflect on this pattern because I am currently trying to obtain a software development internship and most, if not all, of them require proficiency in at least one or two languages.  I do feel as though I am proficient in Java and C, but I am unsure how my skills compare to those that I might work with in one of the internships I am applying for.  I found this pattern particularly helpful in my current situation.

To deal with this problem, Oshineye and Hoover recommend picking one language and becoming a master of it.  They advise developers to spend a few years solving problems in a single language while honing their abilities.  I found this to be useful because I have had the idea, for the past few years, that employers would look for a diverse skillset in novice developers, but Oshineye and Hoover believe that being a master of one language is more useful than being sufficient in many.

To help improve your experience while learning your first language, Oshineye and Hoover believe that it is incredibly helpful to have an actual problem to solve.  I was at this point last year, which is when I decided to join a website that offers free coding challenges that deal with both real world issues and the type of work you might do in school like programming functions in a specific data structure.  They go on to suggest that, in addition to spending a lot of your own time practicing a language, novice developers should find also experienced mentors to aid in their learning.

Oshineye and Hoover conclude the pattern by describing ways to create short feedback loops and use testing frameworks so that novice software developers can easily track their progress as they learn a language.  This pattern has inspired me to ‘master’ a language, find a mentor, and begin creating feedback loops (such as testing) to track my progress.  I think all of these things will give me a sturdier foundation when I enter the field.

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

Post #24 – Reflection on the “Stay in the Trenches” Pattern

This week, I will be writing a reflection on the “Stay in the Trenches” pattern.  This pattern addresses developers who have been offered a promotion to a non-programming position.  I chose to reflect on this pattern because it is a scenario that I have actually seen other people face in the real world and that I believe I may face some day.  At this point in my career as an apprentice software developer, I am still very passionate about coding but I wonder if I will ever consider taking a position that pulls me away from it.

The advice provided by Oshineye and Hoover is helpful and aligns perfectly with my views toward my field.  They refer to 2 of their other patterns in saying that a promotion of this kind will test whether a person is willing to walk The Long Road and/or has Sustainable Motivations – the passion that I feel about programming, now, leads me to believe that I am a person that is willing to walk The Long Road and does have Sustainable Motivations.  They warn that taking a promotion is not necessarily a step down the right path, and that mastery fades when skills are not practiced.  Because I am an apprentice still on my way to becoming a journeyman, I need to practice programming as much as I can and not consider any other course of action.  Oshineye and Hoover’s advice to those who experience this problem is to negotiate with employers to find other ways of being rewarded.

By staying “in the trenches” and having the desire to continue working on implementation is a direct way to “Nurture Your Passion”, which is another pattern I have written a reflective blog post about and feel aligns very well with my way of thinking.  After reading about this pattern, I think I am somebody who does wish to stay in the trenches and nurture my passion, rather than take a promotion just for increased compensation.  I found this pattern pertinent and useful and I will carry it with me as I move forward as a developer.





From the blog CS@Worcester – by Ryan Marcelonis 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.