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.

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.

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.

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.

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.

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.

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.