The pattern I decided to read is titled “Draw Your Own Map” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern was about taking ownership of your professional career as a software craftsman. We learned that in many jobs, you may get pigeonholed to do one particular thing when you may be passionate about learning or doing something different. This passage reassured its readers that they had options and didn’t need to feel trapped, or stuck. By spending some time reflecting  and drawing your own map, you can make career choices that feel empowering instead of limiting.

One of the most thought-provoking points that was brought up in this reading, has been mentioned before and I think I have highlighted in a previous blog post but I would like to reiterate it here because it continues to resonate with me. This pattern mentioned how sometimes it is better to “move into a less hierarchically impressive role in order to stay “on the map.””. Especially if staying on the map is, “more congruent with your goals and will lead you to greater heights in the long term.” This resonates with me because I want to make decisions that are aligned with my goals and beliefs in my professional career, even if that means making some temporary sacrifices.

As far as how this pattern has caused me to change the way I think about my profession, it has encouraged me to either make career choices that open up opportunities or help me  pick a specialization I am passionate and confident in. While my first job after graduation is likely going to be something to get my “foot in the door”, after some time in my first job, it is important for me to spend some time thinking about what the next best step is going to be. My first job is likely going to teach me a lot about what I like and don’t like and it is a place where I can see my interests developing as a software craftsman.

Lastly, I’d like to mention that there isn’t anything in this pattern that I disagree with. It has encouraged me to start thinking about my own map and it has made me peek at some new potential patterns for me to read next (e.g. Expand Your Bandwidth, Use Your Title).

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

This pattern is called “Confront Your Ignorance”. The scenario it is meant to address is when a programmer has gaps in their knowledge that interfere with their work. More specifically, they want to master skills and tools, rather than simply be adequate, yet are unsure of the first step towards that goal. Finding the first step or even admitting they need to find the first step is difficult, particularly in environments where there seems to be an expectation to just have already mastered things.

The solution provided is simple. Pick something you need to learn and then learn it. While it sounds simple, it is easier said than done.

An important skill that I have only recently started thinking about, which this pattern touches on, is the ability to know when you’ve learned enough about a subject and that it’s time to turn your attention elsewhere. Without mastering this skill, one might still go out of their way to study something on their own. In the absence of any clear goals, they may simply give up whenever they get sick of it. This is something I used to do a lot, and it led to situations where I had taken time out of my day to learn something, but the knowledge itself was too incomplete to be useful. I wouldn’t go so far as to say that it was wasted time, but I think it could definitely have been better spent.

Different people have different approaches that best suit them for filling the gaps in their knowledge. Something I think is pretty important for me is to figure out what my ideal approach is. I have some ideas. For example, I think I tend to prefer concrete examples, hands-on involvement, and at least a general understanding of how the whole system works. Figuring out what works for me in more specific terms would be a good idea also.

I tend to struggle to seek help from peers. In this pattern, the authors suggest working together to learn things, which is something I think can be fun, productive, and worth trying.

One of the core ideas here, which I will talk about in a future post, is the idea of two extremes when learning, which need to be avoided. In one, ignorance is kept totally private, creating an atmosphere where not being proficient to begin with is extremely discouraged. In the other, no attempt is made to prevent one’s ignorance from interfering with a team’s project. Straddling the line between these is another skill that I haven’t really considered before, but should probably get good at sometime soon.

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.

I think an apprentice should portray acts of enthusiasm for whatever they are aspiring to learn. I’ve found myself to have copious amounts of enthusiasm for learning how to program and becoming better at it. The issue I run into is finding ways to express that enthusiasm. I get giddy when I think about becoming a great programmer and I certainly wouldn’t want to rub anyone the wrong way because I came off as too much. My current composure and body language around others suggests that I am complacent, although I’m screaming with impatience on the inside. But I wouldn’t want to come across as apathetic for what I’m doing either. As I’ve been skimming over the different patterns in the Apprenticeship Patterns book, there have been many sections that made me feel like the authors were speaking directly to me and this pattern of enthusiasm is no exception.

The authors seemingly think that while being enthusiastic for your craft is an amazing thing, blindly expressing your enthusiasm can actually hurt an apprentice more than it can help them. With this in mind, it is important to curb your enthusiasm to an extent because you do not want to let the excitement you feel for the craft lessen because you don’t want to feel like a nuisance to others around you. As the authors put it, the excitement one feels is “a precious commodity” and I could not agree more.

The sense of discovery can be extraordinarily exciting. It is probable that individuals in well established teams are used to their routines, making discovery likely, but not exactly exciting. The authors mention that this sort of thing is predictable. Developers are always looking for better ways to getting “painful” work done more efficiently. This sounds more like searching for a sigh of relief rather than completing an exciting endeavor, and having with a hyper-passionate apprentice around probably makes tasks like these more grueling.

Finding a team that encourages your enthusiasm is important. An apprentice should be able to recognize a teams dynamic and see where appropriate to show their enthusiasm. If the team doesn’t seem like they would appreciate their apprentice’s ignorance, the authors recommend finding different strategies to nurture your need so that it does not jeopardize your opportunity to learn. However, if the team is open to bright and new fantasy driven ideas, the apprentice may offer new life to the team and boost morale.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

This week, I decided to take a look at the “Concrete Skills” apprenticeship pattern in chapter 2. This pattern describes the problem of potentially joining a team, with the expectation that you will learn more than you already know, and the team not wanting to take the risk on someone who may not be able to contribute to the workload. It is important to acquire and develop “concrete skills.” Concrete skills serve as proof of your competence, as it more so demonstrates your ability to apply the knowledge that you have. The pattern suggested that one should always acquire more concrete skills than just the bare minimum required in an interview. It is always beneficial to have examples on hand as proof of what you can offer to the team. The examples of concrete skills provided include writing build files in various languages and having knowledge of popular open-source frameworks. And so, concrete skills help reassure your future teammates that you are capable of contributing without the need for “day care.”

My immediate reaction to the pattern was that I can see myself in this specific situation. The pattern starts with a quote from Pete McBreen, where he states, “Having knowledge is not the same as having the skill and practical ability to apply that knowledge to create software applications.” That quote stuck with me because we can spend years studying a certain topic, but your expertise shows when you apply the knowledge. And reading through this pattern encouraged me to take a deeper look at the concrete skills I have developed thus far.

For the most part, I think this pattern gives some useful tips on how to build an impressive resume and come off as a capable job candidate. The question: “If we hire you today, what can you do on Monday morning that will benefit us?” is something that I will keep in mind since I will need to evaluate myself before even applying for jobs. I do think this pattern gave me a bit more insight into my intended profession. I never really thought about the fact that teams are more likely to hire someone that can be an immediate help rather than someone they would have to teach. So I think this is more encouragement to further acquire concrete skills. Perhaps I will spend more time with frameworks, especially ones we are working with in class such as Vue.

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

The White Belt

This Apprenticeship pattern was about unlearning what you already know in order to learn something new. It is important to do this because, especially with programming languages, what might be a good habit or convention within one language may be inefficient or bad practice within another. I could personally relate to this Apprenticeship pattern a lot because in high school I took an intro to programming class in which we learned the basics of python. I found python to be really confusing at first, but over the course of the school year I became very familiar with it and began to really like the syntax and structure of the language. While this class was very useful and helpful for learning programming, it made it more difficult for me being a computer science major in college.

In college, most of the programming we do is in java. Transitioning from python to java was very difficult for me because they are two very different languages, with different syntax and structure, and different coding conventions. In my experience, it is very difficult to translate from python to java, but somewhat easier to translate from java to python. Although you can translate from java to python, the way of going about things in java is very different from in python, and the direct translation from java to python is likely very inefficient, whereas code written from scratch in python is likely much more efficient in python. This means that in order to learn java, I had to unlearn what I already knew from python. Even things that I felt were general coding practice felt completely different in java than it did in python, which made it really hard to learn java. So, in order to properly learn java, I had to think about the concepts completely independently of similar concepts I knew from python. Even though this was very difficult to do, I find that it actually fortified my understanding of both languages, and helped me to think about them independently of one another.

I couldn’t find anything I disagreed with about this pattern. I think that this is sound advice in general, even outside of software craftsmanship. You can’t be afraid to fail when learning a new skill, because only through failure will you learn to improve. As the Apprenticeship Pattern mentions, this could mean that you will get worse before you get better, as you’d be much less proficient using whatever new skills you’re learning than you were with your old skills. However, the point it’s making is that it’s worth it to see it through, as only then will you expand upon your skillset.

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

If you haven’t noticed already, there seems to be a trend of various coding practices that I tend to agree with. This is not merely a case of “kissing up” to the professionals, but rather it is the fact that I know I have been taught from the ground up by well-respected individuals. Many of the practice patterns found in “Apprenticeship Patterns” are ones that I have already been aware of, or still agree with despite their novelty. An additional agreement to add to this repertoire is the importance of “Your First Language”.

For me, this “first language” was C. To be honest, I don’t feel like there is a better option to select. C is an excellent, “mid-level” language that follows many of the practices found within my studies. For example, in “Apprenticeship Practices”, the book warns of becoming stuck within your “native tongue”; I feel as though this is negated (or at least parried) by many of the practices in C. C works closely with hardware, and involves skills found in assembly language, but can also be used to emulate higher level languages such as Java.

When it comes to my professional career, “my first language” is a philosophy that has given me a greater appreciation for the diverse landscape of large-scale projects. The C language has elements similar to Python, such as arrays. While data structures are not an impressive connection (they can be implemented among pretty much any language), it does make crossing the gap easier. Once at Python, I can learn about dictionaries, “key: value” pairs that can have an ideological equivalent found in .yaml files and JSON, and so on.

Interestingly enough, despite the emphasis on programming diversity, the pattern stresses finding a first language and staying strictly to its community. I feel mixed emotions about this philosophy: on one hand, it sounds as though “bridging gaps” found between languages should be avoided. On the other hand, constant practice is the best way to learn a first language, and that practice can be boosted by feedback from a desired community around that language.

Overall, I have an appreciation for the idea that beginner programmers should stick to one language when starting out. However, if I were to make a suggestion for that first language, I would suggest C. While challenging to learn, its connections to other languages and diverse applications can make powerful programmers.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

For the longest time Java has been an Object Oriented programming language first and foremost however it was never purely Object Oriented in its design. There exists some objects which are immutable and cannot be changed under any circumstances. String is an example of this and works by having a new object instance created whenever changes need to be made rather than altering the object itself. This is a hallmark of Functional Programming and part of the greater trend of java being pushed to be more akin to Functional Programming languages such as C.

This is something that Ian Darwin reviewed in his Java Magazine article going over the changes Java has seen over time. In this article he asks the question “Why is Java making so many things immutable?”. Put simply the answer is a matter of security and performance with immutable objects being more resilient to attacks and better for performance. Darwin provides examples with the String object which has been immutable since the very beginning. Along with this the Date and time API  has been moved to an immutable package since Java 8.

In the early days of Java there existed Java beans which Darwin describes in the article by the original spec which states: “A Java Bean is a reusable software component tat can be manipulated visually in a builder tool”. What does this mean? It means that Java Beans are more or less Java objects with a set of requirements to be classified as such. There include having set and get methods, expecting to be serialized and implementing the Serializable Java package, and it must provide support for design-time customization. The main takeaway is that these were always mutable and ever since then Java has moved away from this as its language has overtaken servers and enterprises alike.

Why has Java attempted to move to a Functional Programming paradigm? In today’s world many businesses and enterprises utilize Java on a large scale and in general and any way to gain more security or performance in a programming language will do a lot for a language as ubiquitous as Java. The creators understood the need for security with the String class as it has been immutable from the start. We can see below an example thread by Ian Darwin that could take advantage of and break Java’s entire security model if Strings could be modified.

Good Thread: Open File xyz.
InputStream Constructor; call security manager.
Security manager – Read file xyz – Permission is OK.
Bad Thread wakes up at just this moment.
Changes file name string from ‘xyz’ to ‘/etc/passwd’
Yields the CPU
Good Thread
InputStream Constructor: pass /etc/passwd to operating system open syscall
Bad Thread examines memory buffer for useful information to steal

Beyond the security benefits that these immutable objects pose there is also a matter of being able to increase performance of Java. Java is constantly being improved and as it’s performance increases it has become apparent that it is faster to create new objects than it is to modify the properties of old ones. Java lacks the ability to use pointers like C and because of this any extra baggage that can be removed to free up resources helps in a language like Java. If you compare Java at release and Java today, you can see that a myriad of new immutable APIs are scattered across the language as it has grown and evolved. This will likely continue so long as Java is a dominant language in the programming field.

Bibliography

Darwin, Ian. “Why Is Java Making so Many Things Immutable?” Blogs.oracle.com, https://blogs.oracle.com/javamagazine/post/java-immutable-objects-strings-date-time-records.

https://blogs.oracle.com/javamagazine/post/java-immutable-objects-strings-date-time-records

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.