Author Archives: Julion DeVincentis

Apprenticeship Patterns: Chapter 5

Breakable Toys

Success is often a tool used to measure how effective you are as a programmer, but this isn’t quite true. Failure is often referred to as the great teacher, as learning from mistakes that you make is great for improving yourself. The idea behind this is that if everything you make is bound to succeed every time then the process behind it might not haven hard. Things that don’t challenge you are not going to fail for you, but at the same time you are not going to learn anything from it.

This pattern is to take something, try to build it, and learn from your failure. You can be skilled and incredibly proficient in your strong suits but if you are not failing as you proceed you might not be challenging yourself. You might stagnate in your skill, and while you can be incredibly good at it, you still are not learning anything that is challenging you.

This particular pattern I agree with. Learning through adversity is often a great motivator. For some, time is an incredible motivator and through procrastination you have a literal time limit challenging you. For some, something new is an incredible motivator as it’s something utterly foreign and waiting to be explored. You should try something new to learn how your own skills are developing. Failure at first can deter you but taking this approach will teach you how failure will motivate you. You couldn’t succeed, but it doesn’t mean you cannot. You’ll find yourself thinking endlessly on that failure and seeing how others have succeeded where you failed will motivate you to think it has to be done. After all someone else has done it or likely created something like it. Take on a new library, build something that you never have before and let it break apart in your hands. Take the pieces and try building it again. In a sense you are letting yourself be broken by your broken project. Just challenging yourself will not be enough you have to learn from failure and learn how to fail. This pattern honestly should be called Breakable Self, as the learning portion isn’t the failed build, but rather using that failure to break a common mindset to succeed where you once failed.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Chapter 4 Part 2

Sweep The Floor

A common stereotype amongst movies and literature when an apprentice first begins their work, they are handed a menial task and told to perfect it. Often sweeping or “wax on, wax off” from the movie Karate Kid, the task being grueling and numbing in a sense. This task assigned to you wasn’t to demoralize you or just give you something to be distracted by, it was to get you ready and perfect a skill by practicing frequently.

As an apprentice you are nearly always going to be on the lower rung of experience and will find yourself doing work closer to your skill level. With programming the metaphorical broom might not be clear, or obvious. Instead of waiting for instruction you should take the initiative and volunteer for things. Take a task that you can complete or learn to complete and lighten the load of others.

This won’t necessarily seem like sweeping the floor but in a sense you are taking the tasks that will help yourself and the team you are aspiring to become an essential part of. I understand this aspect fairly well absorbing this concept through admittedly far more media than I should have, but I agree with this pattern pretty much wholeheartedly. Being apart of the group and not being as skilled as them is fairly demoralizing, but taking the lesser tasks can still make you a vital part of the process while you make the effort to become as skilled as your group members.

While learning and developing your skills you do have to step back and learn the basics. Focusing your skills and learning the essentials is integral and necessary. It’s also usually the tasks that most don’t want to work on. Mind numbing maintenance and formatting is one task that higher level workers dread maintaining. These tasks are necessary and vital to the projects success and someone needs to do it. You might as well put yourself into the problems you can solve and along the way you will learn things vital to improving the project and increasing your skills. To learn the basics is to master them. Sweep the broom before you place the first brick of the new structure. Stack bricks thousands of times before you can build a sturdy wall. This pattern is to take the mindset of the novice within your group and how as an apprentice you can learn while also helping out your group.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Chapter 4 Part 1

Find Mentors

When first understanding how you learn, and the general experience of how human beings learn, you’ll find yourself in a situation where you want to learn something, but you don’t know how to go about learning it. You take your first stab at it and find that you are learning some things but not learning constructively. You blunder around accumulating random knowledge and at some point, you might experience some success and get lucky. But more times than not you’ll blunder around and this effort might demoralize. The fault was not in your but your methods.

Mentor-ship and finding mentors is critical to learning something more specialized within your own skill set. This apprenticeship pattern perfectly describes an issue that I have frequently run into myself. It describes this path as exploring a blind alley, and this is an apt description. During my first sprint during my computer science capstone I made an effort to try and learn HTML. I looked over some example code and learned generally how to write it but fundamentally I didn’t understand how to structure it. I was blindly exploring the learning process and was failing.

I felt how I was failing and I knew I needed to reach out to something far more similar to a teacher. Some see the name mentor but what is a mentor but a highly skilled teacher. Yes of course there is more to teaching than just knowing the skill but they have the knowledge of learning the skill you are trying to and the path that helped them succeed. You need to find yourself a path that has been traveled by a human instead of blindly traveling that avenue.

I sought an actual HTML course that is commonly available in YouTube format and learned in a structured manner from a person who understood it as a whole. Now this isn’t to deter you from learning something new without a mentor as you do need the ability to learn new things without help, but something completely foreign to you requires a teacher. Mastery of a subject will require a mentor. Both require a desire to learn and to realize when you should seek other’s help.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Sprint #3 Retrospective

During this sprint my previous work in getting the front ends linked to each other for testing would finally be quickly integrated for the two front ends addInventory and checkInventory.

While figuring out how to properly implement it into checkoutGuest front end, it was found to be not properly set up like the other projects and would require setting it up to be the same as the other front ends in terms of their vue formatting.

I was spending the majority of my time learning more about vue and how to set it up within an already created project and managing the new changes when I decided to take a peek at the previous branches as the way this project was currently setup didn’t match the others and I considered the possibility of something in development perhaps being left behind.

I found a branch called updatedFunctionality, and in it was a project formatting exactly like the other front ends and I knew then and there that we needed to integrate it within our current branch. My professor recommended that before we merge it into the main one to do a merge into a test branch to simulate what it would be like between the two and see what conflicting merges we would have to deal with. He also preferred that we didn’t just erase the main branch’s development as to not leave out the work created by previous students.

I successfully merged the two branches and got approval to merge the main and this branch and deal with the conflicting merges of which there was not too much. With some help from my fellow group member Fadi Akram the branch would be merged and my I would implement the changes needed to connect this front ends to the others like I did at the start of the sprint.

Afterwards I would spend my time testing and working on the user interaction portion of checkoutGuest as it involves a point in which the user of this station will be scanning or manually entering in student ID’s to record items being taken out of Thea’s Pantry. Working on previously established work from Professor Wurst, I modified the user interface to accept ID from both keypresses, scanning, and manually entry by keypress in the same format as it being scanned. I also made sure to prevent future issues by preventing negative values being submitted and locking the text box for user ID when a proper value is entered to prevent further changes if there was a mistake made. I also added a clear button should the user desire to make a change as they have entered the ID, should it not match the one they have typed.

There is still some modifications that should be made to the interface like allowing during manual entry to delete the desired values and modifying the value of the idnum variable to match. It would be just checking for the backspace or delete keypress and modifying the value, but it would require testing and I can’t say I am certain if that would work perfectly just from that idea.

Overall this was a far more productive sprint for myself than the previous ones. The efforts made in the previous ones helped me to succeed in this sprint thanks to understanding vue and html better.

During this sprint my team was primarily focused on fixing the backend and had I finished my work sooner I would have been working with them as well trying to debug it. My team did come together well to focus on that issue but our ability to work on testing the backend was limited by it not being able to startup and work.

I did struggle with some of the JavaScript coding while refactoring it a bit and that is definitely one avenue I need to take to improve on my own skills. It’s fairly similar to other languages I have used but some of the syntax did in a sense fight back against me, like how JavaScript handles operands with their weird truthy and falsey system. While creating conditional checks some would still pass through as it was still considered “truthy”.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Chapter 3 Part 3

A Different Road

You find yourself tired and bored of your work. You have some personal projects to advance your skills that keeps you busy, but you find yourself needing to take a break. To diverge from the road you are on to either just rest for a while or to just see where it goes. Your career as a software developer is not what ultimately defines you. A Different Road describes a scenario where the road you have been traveling on in your programming career is not the road you want to travel along anymore. You might wish to spend more time at home and with your family. You might desire to train for a marathon. You could buy a bit of land, build a barn and become a farmer.

The road of your software development career never truly ends until you decide to end it and even if you do, you can always start back on it again. Just like riding a bicycle you never really forget something that you practiced frequently. So, take the break that you need. Buy that farm and become a farmer. Your career is not what really defines you, and maybe whatever you try will need some kind of optimization that your skill-set can solve.

Ultimately this pattern speaks to the idea of breaking the stubborn mindset most people find themselves in. It’s this mindset of having a path and having no other choice. The path paid your bills and you enjoy it to a degree. It’s hard to accept the idea that this thing you have been spending your time on isn’t right for you. To align with the road analogy, the road you have been traveling has been well paved and barely has any traffic. As you travel further and further you might find it gets even easier and has even more lanes and less traffic. You might also find that this road has potholes and traffic has only gotten worse and worse.

Recognizing when that road isn’t worth traveling on is easy to think about, but harder to act on even when it’s right in front of you. But unlike the road analogy, your skills and motivation are not a car. You can’t sell it and lose it, it can’t be stolen from you, and even if you don’t use it for a while it doesn’t mean it can’t start back up again. The thing to take to heart is do what you want to do, but also stop doing the thing you don’t want to do just because it’s your career.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Chapter

Stay in the Trenches

As you progress in your skills and your career as a software developer, you’ll find yourself in the position of advancing your career due to your successes. You’ll take on a managing position or even a position and find yourself coding quite bit less. You’ll see your path as improving but it’s advancing your career in that company and not in your abilities as a software developer.

It’s imperative that regardless of all duties at the company, you try to stay in the trenches. Keep building your skill-set and training yourself around software development. Your company might not need that manager role in the future, your company could go bankrupt if it fails, you might be put into an even higher position that pulls you even further and further from any actual coding. The path of the software developer doesn’t have to diverge from your career path.

I found this one interesting as it makes sense. I have thought, what do managers of programming teams do in their spare time? I only figured they would take up coding something related to the company or even just taking up spare coding work from other teams. It never occurred to me that someone in that position might take the ramp off the long road of software development and instead focus their career on gaining a higher position in the company that they work in. This in of itself is a perfectly fine choice to make for their career, but the desire to code is likely how they ended up here and I find myself wondering why they might give that up.

It could be a little tempting if I am being honest. It’s kind of strange to me at least that those higher up in the company still end up getting paid far more than those who do the actual work to make the project physical and marketable. At the same time the actual workforce you need to get a project like that built requires several people and if all of them were getting the highest tier of payment then the company probably wouldn’t be profitable. Money in modern days is very tempting as those who have experienced hard physical labor understand how tempting it is to earn a six-figure salary and in essence get paid to attend meetings, write emails, and manage a team of programmers. I don’t imagine myself taking one of those positions though. If I’m not actively doing something while working, physically or mentally, I find myself incredibly bored and frustrated. I don’t think I’ll have many issues if I end up in a higher position. I likely would have followed this principle without even knowing about it.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Chapter 3

Sustainable Motivations

At some point while developing your skills while working on a project or a job, you’ll find yourself primarily focused on your current skills or focused on your work. During this you might find yourself in a bit of a rut and a lack of desire to continue working on those projects. Though you might want to take a break and try something new, you find that the project you are working on is paying the bills or giving you the validation of your skills. The conundrum comes down to do you keep at it even though your work is draining you, or do you strike out on something new to hone your craft.

Now obviously you need to continue your work, but you don’t need to be trapped by it. You can always on your own build something that you want to rather than something that you have to. In your job you may find that its not improving yourself and become monotonous. Nothing is stopping you at home from taking up a personal side project to grow yourself.

The thing I primarily learned from this pattern is the concept of the golden lock. It never really struck me before. The idea that my own motivation to work would be the one to lock me in place and prevent me from progressing. When thinking further, it does make sense. You have a motivation to work because it provides you with income or a status on showing your skill. Simply placing yourself into that mindset will lock you into that position and you’ll never make the time to improve yourself. That little golden latch holding you in place because this is what’s advancing your career. Your career is more of a side note to your progression as a software developer, its not the primary driving force. Your job is a job, but there might be something else out there that you can hone as a fine skill that barely anyone else can and could even lead to a new field you never considered for your career. Your passion for learning programming cannot be tied to motivations to complete your work.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Chapter 2 Part 2

The Deep End

As the title describes the deep end is like the deep end of the pool when you are first learning to swim. While of course you need to learn the basics before you reach the deep end, the question then becomes do you make that jump when you have the necessary skills?

The answer is yes of course, and like the deep end of the pool as a young child it can be scary sometimes. I remember when I was younger and had learned how to swim in the deep end as well. I came to another kind of deep end at a local beach by a pond. Just swimming out into the deep wasn’t enough there was a fairly high tower that you could only jump off of if you could swim in the deep end. The only way to advance further was to take that leap. I unfortunately hit my arm on the way down and had it gotten stuck it definitely would have been broken. Luckily I made it just fine with a scrape, but the fear of taking the jump again was gone. I had made a mistake that I wouldn’t make again.

This particular pattern is one that I should really utilize, often you can get to a point where you may not really know where to go next or what even to do when you jump. Placing yourself into a situation that is more difficult than you have been before is critical for improvement and certainly applies to software development. With software development though you can know what you are likely going to face when taking on a new project to grow and adapt yourself. With any problem there is the general assumption to be made about what the solution is. The real challenge is in how you’ll solve it when you arrive at problems that present themselves while you have no solution.

I don’t find myself disagreeing with anything in particular about this pattern, unlike the previous one. It summarizes a problem and gives a solution that is a common theme in life. Sometimes to improve you need to take on a bigger task or place yourself in competition against those who you know are far better than you.

As for applying it towards my career as a software developer, there really is only one thing to do. Find a deep end and go for a swim. Worst case scenario is I’ll not achieve my task, which is only another opportunity to try it again.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Sprint #2 Retrospective

With reflection on the previous sprint we had a more clear vision of what we could modify and change about the front end systems and possibly some work to be done about the back end system. We also as a group decided to reach out to the IAM and AWS teams to see if we could integrate their work with ours. I also had not finished my previous tasks so it was an issue that I personally needed to address and focus on during this sprint.

I still had the two previous issues from the last sprint on my hands but I did take the responsibility of communicating with the other teams and start working on understanding their work to help integrate it with our team.

On this sprint the majority of my time was working learning html and CSS, but in a manner that was constructive and effective as my previous sprint learning session did not go well. In this sprint I had a far more effective learning period by following a six hour html and CSS course which helped me greatly []. A major portion of my time was watching this, pausing to test out the things I learned and working on the html pages for the Worcester state styled formatting. This would all have been added to their necessary repositories, but I noticed something both funny and disappointing at the same time that changed all the work that I needed to complete.

While I was nearing the end of the sprint I felt as if the pages I did have were ready for testing and possibly creating a branch for and wanted to test it in one of the front ends. I tried running the front end docker containers on my desktop, but I never could get the local host page to run. It would load forever and never show me anything. I also tried separate front ends to see if it was just one front end’s issues, but I still had the same issue. It wasn’t until I tried running two front ends at the same time and had to change one of the ports to discover that it was just local host 8080 that was having a hard time. I tried connecting to it without any containers running on those ports and a page I had not seen in a while showed. It turns out somewhere on my mac laptop Jenkins was running []. This was preventing me from running and I had to do a deep dive through my laptop to find it and stop it completely which had taken far more time than I wanted to. With it disabled I ran the containers and connected to the local host page. It was there that I found that a front end landing page had already been made and implemented and I had unnecessarily wasted my time on trying to create pages for the front end systems. Now I don’t feel as if my time learning on html was wasted but the app.vue already had the needed formatting and style that was appropriate for the landing pages.

Right at the weekend before the end of the sprint was around the time that the IAM team contacted me and provided information on how to set up the keycloak system and I had spent a little bit of time that weekend looking it over. That same weekend was when I had made the discovery about Jenkins. The href task was easy enough to implement and I had tested it and it worked. I just did not have the time at the end to create my own separate branch for each front end as I felt like it needed to be split into separate and specific issues for documentation reasons. The next sprint will have those two fully solved and I’ll probably be focusing the majority of my time on integrating the IAM teams work and testing out their work with ours, but at least I understand html fairly well now!

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Chapter 2

Confront Your Ignorance

This pattern specifically covers an area of your skill-set or knowledge that you are not well-versed in. It challenges you to take the thing you are ignorant of that is relevant to your work or perhaps relevant to future work and invest your time to master it. The roundabout way of doing so is, as it describes, to pick the skill-set or technique and fill those gaps.

Seems simple enough but I felt as if this pattern is missing a bit of useful advice. Your personal growth when confronting your ignorance is more than organizational as the actions describes. It’s a matter of personal reflection and recognition. It’s definitely easier to say, “hey I know nothing about network communication”, and harder to recognize your own competency in network communication. The pattern does cover a bit of this, but it seems to focus far more in directly confronting easier problems.

I picked this specific pattern as it directly impacted how I worked during this semester’s sprints. In specific I applied this pattern unknowingly when I was thinking about working on a specific issue that related to using html. I have seen html code and references to it plenty of times during my college career but have never really used it before. I also overhead fellow classmates speak about it on rare occasions and mention building a custom resume styled website using html and other tools. I have had plenty of introductions and chances to learn something that is common in computer science, yet I have never taken the chance to learn it. At the start of the first sprint, I finally confronted my own ignorance around html and put myself into a situation where I would have to learn it in order to complete the issue. While I could have done this at any time it seemed prudent to place myself in a position to succeed at and implement to help motivate me to fill my gap in knowledge. This is why I felt like this pattern should describe learning how to identify your weaknesses a bit more as just knowing your weakness is quite different as confronting it is. One is merely a slight acknowledgement and the other lets you learn how to continually find your gaps.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.