Category Archives: Week-15

Stay in The Trenches

This week I have decided to write about Stay in the trenches. This refers to deciding to program even when the craftsmen receives a an offer that would pull him away from programming. Dave mentions that the minute the craftsmen stops programming, his skills will fade.

This has certainly been the case for me. In school there were semesters that brought me away from coding. There are many classes that are non programming and when I take so many of those non coding types of courses plus working part time, it was at times hard to find the time to code. So I could only imagine what would happen if I had a job where I couldn’t code every day. Especially with family obligations. I know that my uncle and folks that I have talked to in interviews mention that they don’t code anymore and that they miss it. So I completely agree that skills atrophy when the craftsmen does not use them.

Dave recommends finding alternatives to the managerial promotion. The craftsmen needs to figure this alternative out on his own and write down these rewards. This is something that I will figure out on my own as I have more work experience. I know that these days there are lots of oppurtunities for senior software engineers so I think that if I want to stay in a coding role I am confident that I this type of oppurtunity will exist.

This specific decision is a ways a way for me. But there are similar cross roads in the earler stages of my career. There are positions for new grads that involve different levels of coding. There are Quality Assurance roles that are part of the Software Development Life Cycle but it is not a role that is strictly coding. So it just goes to show that the apprentice will need to choose programming again and again. There are many roles in software that do not involve coding, and it is important to choose programming again and again. This is an important lesson that I will take into my career as I graduate and move into my career in software development.

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

Retreat Into Competence

It happens to everyone to feel overwhelmed, confused, and realizing how little we actually know or that we’re working on a project that is actually not going well. Retreating into our competence and regain it is he solution to this problem. Sometimes, stepping on the side is a good thing because when we pull back, then it’s easier for us to launch ourselves.

In the pattern, the author Dave H. Hoover says: “An apprenticeship is a roller-coaster ride. You will experience the thrill of learning new technologies, leveraging your knowledge and creativity to deliver value to your customers. But you will also experience the heart-in-your-throat terror of perceiving just how little you know compared to the craftsmen and experts you meet along the way. It can be overwhelming, particularly when a deadline is looming or when you’re dealing with production issues.”. Wen reading this, we can understand that this is a normal and inevitable phenomenon along The Long Road. Overcoming the fear of your own incompetence is the bridge between Expose Your Ignorance and Confront Your Ignorance.

This pattern is most relevant for people who have stretched themselves far beyond their ability. If your apprenticeship has you taking reasonable-sized steps forward, taking on gradually increasing responsibilities and technical complexity, then you may not need to take shelter in this pattern. But if you are really struggling or are barely keeping your head above water in The Deep End, look for opportunities to temporarily retreat. Sometimes you need to take one step back in order to take two steps forward. From this pattern, I just understand that pressuring ourselves and feeling overwhelmed, or a project not working and feeling frustrated, stepping off and pulling back will help us go even far. I love the way the author explained and said that when we pull back, then launch forward, it is like a some from a catapult. I am pretty sure we have all seen catapult and the further back we pull, the further the stone will go forward. Same with software, when we feel like we can’t do it anymore, let’s pull back and retreat into our competence. That will be the way we will regain it.

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

The Deep End

This is one of my favorite patterns which is “The Deep End” because it talks about the importance of leaving our comfort zone and jump into the dep end. I love how this pattern explains the importance of being open minded and ready to confront anything because nothing guarantees that we will always be in a domain that matches our skill level.

Waiting until you’re ready can become a recipe for never doing a thing. Growth only happens by taking on the scary jobs and doing things that stretch you. There are opportunities that we will or may end up having, but they might be out of our comfort zone. Risks are opportunities seen through the half-shut eyes of fear. Meaning that taking that promotion or foreign assignment when it’s offered, even if the very real possibility of failure is staring you in the face. Being prepared to fail and recovering from that failure opens doors that the timid will never see.

Even though we advocate seeking out the most challenging tasks we are capable of, we still need to remember that if the water level is above our head, it means we’re drowning. Even in Enrique’s example, where he was changing his life in a big way, he was still moving to a country where he knew at least one person and could speak the national language. It is our responsibility to offset the risks of this approach by Finding Mentors and Kindred Spirits who can provide help when we need it.

It’s also your responsibility to Create Feedback Loops, so that if the challenging project starts to spin out of control you can catch it and get help immediately. Applying this pattern should feel brave rather than reckless. Willing to go and confront the difficulties and being ready to swim until we finally find the way out.

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

Confront your ignorance

I was reading the pattern on “Confront Your Ignorance” and it talks about what to do when you realize that there is/are gap(s) in your skillsets that you need to work on and need for a daily work. Some people are scared to confront their ignorance because they hate thinking of themselves as ignorant and hide that side of theirs.

While reading this pattern of chapter two, confronting our ignorance is the best way to become better in what we do because we will actually improve our skills and master in what we will do. There are many ways to actually confront our ignorance: For some people, the best approach involves trying to get an overview by reading all the introductory articles and FAQs they can get hold of. Other people find that jumping straight to the construction of Breakable Toys is the most effective way to understand something. Sometimes others will be trying to acquire this skill as well, and by working together you can make better progress. At some point, with this ways, we have gained a satisfactory level of ability in this new area, and then we can decide whether it is more productive to dig deeper or turn our attention to the other gaps in our skillset.

This pattern is closely tied to Expose Your Ignorance, but implementing it is less of a challenge to your pride because it can be done in private, without anyone else ever finding out the things you did not know. We need to know that learning in public is one of the ways in which an apprentice begins the transition to journeyman. It’s a small step from learning where people can see you to teaching.

What I love about this pattern is that many times I love to challenge myself and go do thigs where I feel I need to confront my ignorance and learn. It’s a factor that everybody should have, especially software developers. This field requires a lot of practice and we need to keep in mind that it’s not everybody who knows everything in this field. We may have some skills but we also all have to confront our ignorance at some point.

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

Apprenticeship pattern: Practice, Practice, Practice

This week I decided to write on chapter five about practice. This pattern really reflects the reality of life. Everything, if we want to master or succeed, we need to practice in order to get better every day. To improve, if you routinely practice something, the likelihood of you doing better on something is higher.

This pattern is telling us the importance of practicing and that the performance of our daily programming activities does not give our room to learn by making mistakes. But taking time to practice our craft without interruptions, in an environment where you can feel comfortable making mistakes. As software developers, we need to practice in order to grow our knowledge and skills. I love how the author says: “The key to this pattern is to carve out some time to develop software in a stress-free and playful environment: no release dates, no production issues, no interruptions.

The importance of practicing is that every day, there is a new thing that we learn, do something a little bit different each time an exercise is performed. As software learners, practice is our best friends, so are curiosity and determination. We can go far and become those great craftsmen if we put up the work and are willing to make sacrifices. Then, we will master and become thos great software development.

One thing that I will always remember is that we should never forget about The Long Road. That we should be patient and accept difficulties, so we can challenge ourselves and master in what we are doing.

In reality, regular exercise for software developers can help improve our brain, memory, problem-solving skills, and overall mental agility. Things that are rarely talked about but necessary in our daily lives, especially when dealing with complex problems such as developing new components, solving bugs, or even having architectural or difficult meetings.

From the blog CS@Worcester – Gracia's Blog (Computer Science Major) by gkitenge and used with permission of the author. All other rights reserved by the author.

Retreat into Competence

Retreat into Competence is an apprenticeship pattern that focuses on the idea that when you find yourself in a situation where you are overwhelmed with new information, it is alright to withdraw back into something you are more comfortable with. By doing this you allow yourself to gain back your mental composure, and gives you the opportunity to reflect on how far you’ve come as a developer.

I believe this apprenticeship pattern is incredibly true and helpful, as I have frequently found myself in situations where I do not feel confident in my abilities and as a result I get overwhelmed and stop being productive. When I first started my internship last summer, I was expected to use Python as the primary language. Up until that point I only had limited experience with Python, so I had many moments when I felt like I was in over my head with trying to learn a new language and also meet deadlines for the projects I was working on. During those moments I would often get a pretty bad case of imposter syndrome, and start believing that I wasnt good enough for the job. What helped me push through this was a similar technique to what is taught in this apprenticeship pattern. Whenever i felt overwhelmed with a certain aspect of the project, I would go back to a part of that project I felt comfortable with and work to improve on what I already built. By doing this I was able to stop the mental block, and by working on familiar material I felt like I was making progress. This in turn helped me figure out issues I was having with other parts of the project and slowly push through them to finish everything up.

Since I have used this apprenticeship pattern in the past with success, I am almost certain to use it again in the future. Since I just graduated and am about to start my new career, I am sure plenty of situations will pop up where I again feel overwhelmed. When those situations arise, I now have a strategy I know will work, and I can rely on it to help me get through whatever issues might come my way.

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

Familiar Tools

Any project that doesn’t retread at least some old ground for you is one where you can’t effectively gauge how long it will take. This is the problem the authors identify in this pattern. The solution offered is essentially to have a set of tools you’ve already mastered and to get at least one of them in whenever working on something unfamiliar.

One pitfall the authors mention is the possibility of your tools becoming obsolete. If you’ve mastered something, it can be pretty uncomfortable to give it up, especially when the new alternative is something completely unfamiliar. This is why I think it’s always a good idea to be on the lookout for things to add to your toolbox.

Speaking of, I want to actually come up with a proper response to the action section in this one, for a change. The authors basically just ask you to reflect on what your toolbox is. I have a specific project in mind, which is a small game I’ve wanted to make for a few months now, but haven’t been able to with school.

Here are the relevant tools I’m familiar with:

  • The JavaScript programming language
  • The OpenGL standard (kinda)
  • Krita (an art program)
  • LMMS (a DAW)

The authors suggest five tools, but I can’t really think of another one that makes sense for this project. I think coming up with this list was clarifying in that it made me realize that I’m not entirely comfortable with most of the tools I want to use for this project. The project, for reference, will be a short narrative-focused game where a character walks around and talks to people. It will be embedded in a web page, which is why I’m using JavaScript.

JavaScript is probably the thing I’m the most comfortable with on that list, although only because I feel pretty good about procedural and object oriented programming in general. The other three things I’ve mostly only really dabbled in, particularly LMMS.

Something else I noticed writing this list is that there’s quite a lot that’s going into this project that isn’t covered by a straightforward list of tools, even if I were to take away all the non-programming parts of it. I think it highlights the fact that just learning the tools, while necessary to get things done, isn’t sufficient. You also need to apply them creatively.

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

Apprenticeship Patterns: Retreat to Competence

                Today marks the last blogpost I will make about “Apprenticeship Patterns” by  Dave Hoover and Adewale Oshineye. To finish off this series of posts over the past few months brings us into the unknown, of what is yet to come and may not even be revealed until the last second. Many of us reasonably fear the unknown, anything that cannot be controlled in our lives is unpredictable and may at time overwhelm us. This is exactly what this book has been attempting to get the reader to reconcile with and it is evident in the pattern “Retreat into Competence” that they realize just how overwhelming it is to venture into the unknown. Having a place to return to and gather yourself before venturing once more unto the breach is an important tool but should not be a crutch for your lack of knowledge in other areas.

                One might be an experienced Java developer and comfortable with the language and its many quirks and features, however they will one day be met with another language or toolset that is completely foreign such as REST APIs or C++ and C code. This is the rollercoaster of apprenticeship where the thrill of learning and the terrors of facing your vast ignorance coalesce. This however is all part of “Walking The Long Road” As described by Hoover and Oshineye. This vast ignorance is something you must expose and confront if you are to grow as a craftsman. (You can read more about exposing your ignorance here)  

                One of the most important things to overcome as a software developer is the fear of the unknown and sometimes one can benefit from retreating to something they know and returning with a fresh pair of eyes to their previous roadblock. Taking a break to refactor some Java code can be beneficial if the REST API portion is stumping you. However it is important to note that this tool must be used responsibly and not as a reason to avoid exploring new avenues that reveal your ignorance. Becoming an expert in something you already know is tempting however there is a risk associated with such expertise as the industry will eventually leave that technology behind for bigger and better things. Once this has happened you will find yourself in a situation where you know nothing about other technologies being used and even worse, have nothing to fall back on to recompose yourself should you being to feel overwhelmed.

                With this in mind, I would like to challenge the readers of this post to explore a new avenue of software development. Explore a toolset that you either have not used or, even better, have little experience with due to being overwhelmed the first time around. If possible attempt to either adapt a piece of software you created in another toolset or take a tutorial and create something new out of it. Learn its intricacies and, if necessary, take a break and return with a fresh pair of eyes after working with a more familiar tool for a while. Even if it is a small program, it will deepen your understanding and help to thin the overwhelming veil of ignorance that makes learning something new so daunting.

Bibliography:

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Crafts over art

Summary:

Craft over art pattern makes an important point about quality over beauty. Pattern points out the ugly truth that “For a craftsman to starve is a failure; he’s supposed to earn a living at his craft.” A scenario like this can happen when the craftsman is not skilled but mostly occurs when craftsman decide to prioritize art over their craft. Craftsman should build a software based on the product owner’s need and not just indulge their desires. It is a craftsman’s responsibility to develop a software that is beautiful. However, this should not be done by sacrificing the utility and productivity of the software. The pattern provides a solution which uses a fifty-fifty line. The craftsman should develop a software which is aesthetically pleasing and feature rich. Creating something that is beautiful and has no use is not craftsmanship, it is a waste of craftsman’s skill and time.

Another aspect the pattern covers is that as craftsman, we need to prioritize product owner’s needs over our own. As craftsman we cannot make excuses of not being in an ideal artistic environment; we need to create a quality product that satisfies the product owner in the provided time frame.

However, craftsman should not do merely do what is expedient. The pattern states us to adhere to our standards even under high pressure. The pattern further explains that based on the product owner’s requirements, sometimes we will need to switch priorities between productivity and cosmetics. To understand, achieve and maintain all our standards, we as craftsman need to understand craft and art are not mutually exclusive but interdependent.  

Why this pattern?

As someone who just graduated and is joining the work force as a software developer, craft over art pattern can be used as a moral compass. Programming is without a doubt a form of art especially if I am working on frontend or User interface. I have been hired by a friend to create a website of his family’s construction company. They wanted a simple website with description of their work, prices, and contact information. I spent hours looking into themes, designs, photos, and live photos and barely any looking into features. After reading this pattern I was able to reorganize my thoughts and let my friend know all sorts of features I would be able to add into his website. He was pleasantly surprised with my suggestions and his family even offered a raise. The pattern helped me stay true to the programming and not get lost in the aesthetics of it all.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

CS 448 Post #8

I wanted my last post to be about a pattern from chapter 6, and I chose Dig Deeper, which is about dealing with complex problems and to learning as much as you should. It builds upon previous chapters by talking about how you can run into issues by learning just enough to handle some problems but not others, and having just “superficial knowledge of a thousand tools”. At this level where some people will be at, there is much more that they can learn, and as the name of the pattern says, they need to dig deeper into the technology and tools that are out there. This sounds like retreading previous patterns about growth and learning more, but this pattern specifies the difference between the learning that has been talked about before, and going deeper into the knowledge that we have growing. Instead of just learning how to solve problems and read designs, this pattern is about understanding how these are created and why they are the way they are. The pattern put it best when it stated “depth means understanding the forces that led to a design rather than just the details of a design”.

I selected this pattern in particular not just because it adds on the idea of going deeper into what we are learning, but because the pattern goes in depth on this idea. It talks a lot about how this can be beneficial to you and how you can dive deeper into what you already know and having a full understanding of what you are working with, both what you are working with and how they came to be. In recent years I have been trying to use something similar to this method when it comes to other topics, trying to understand why something is the way it is, like with psychology and seeing how people act but wanting to know why someone may act a certain way.

Knowing the how and why of something is the key to understanding it. You can see and recognize that something exists and can deal with it without fully understanding it, but trying to understand it can not only help you learn more about what you are dealing with, but it can help you come up with an alternative and possibly better way to deal with it.

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.