Rubbing Elbows is very closely related to Kindred Spirits. The idea is to actively observe the way people around you work, and to seek out people you can learn from. Most of the pattern is centered around pair programming, and it is certainly a very good example of Rubbing Elbows. When pair programming you want to find someone more and/or differently experienced from you. This will give you the greatest opportunity to learn; if you only stick with what you know and are good at, you will never grow as a developer.

This is actually something I am very excited to do. When talking to my classmate about potential job prospects, he suggested to me that I should do a remote job. I am very against this idea. I want my first job to be one where I am physically in the office surrounded by other developers who can help me out if I need the help. Pair programming is something that really appeals to me, especially if my partner is more experienced than me.

I worked at an internship where I was the only programmer. There was one other older guy who did programming, but he was mainly an engineer. I tried my best to learn from him, but the environment was not a professional development one. Working alone, I was not able to consult other people and could not determine if what I was doing was correct.

I cannot wait to enter the workplace and learn from other people. Rubbing Elbows is a great pattern, but honestly did not do much for me. I already wanted to meet people and learn from more experienced developers. In fact, when I wasn’t able to collaborate with others was the worst feeling ever. I think that I did good work, but cannot know until other people look it over.

My biggest fear as a developer is doing things wrong. There are many ways to develop software, and there are many ways to mess it up. I need the guidance offered by others; maybe not explicit guidance, but guidance nonetheless. Having someone to consult and learn from is one of my main goals as an apprentice. I am so new that I do not know what I don’t know. Rubbing Elbows with more experienced developers will help me along my path.

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

Kindred Spirits seems like a good pattern if not taken forcefully. This pattern is all about joining a community of developers who have similar interests and/or skills to you. As an apprentice, your main goal is to learn. Working in a professional environment will not always provide this environment, and the mentors you gain along the way will have their best interests in mind – not your own. This is why it is important, as an apprentice, to seek out communities that you are drawn towards because they all have the same motives as you. The goal of these communities is to learn and experiment, and they will be the best place for you to do the same.

To be completely honest I had no intention of doing this prior to reading the pattern, and still am against it. I get why it is good, and I am not against having friends of course, but I am not sure I want to join a community. I guess the point is that you only go when you want so I could just abandon a community I don’t like. Like I have said in previous blog posts, I do not want to focus on programming as a hobby. I do enjoy it, and I am not against joining a programming community if I want to, but I am not the type of person to code for fun all the time.

That being said, I do see the benefits of Kindred Spirits. Of course it is good to have friends in the industry with similar goals, and I do plan on making friends. Having someone to talk to about something I am working on will give me a new perspective and may solve a problem, and helping someone else will test my knowledge on what I actually know. They say the best way to learn is to teach, and to have someone ask me a question I supposedly know the answer to will help me as much as it helps my friend.

Overall, I do like Kindred Spirits. Friends and community are always a benefit. I don’t like the feeling of being forced into friendship and community, but I don’t think that’s what the pattern is saying. I believe it is saying to keep yourself open to new opportunities, find people who you get along with, and use your fellow apprentices to your advantage.

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

Christian Shadis

In the apprenticeship pattern Concrete Skills, Hoover and Oshineye explore the importance of developing discrete, demonstrable skills with specific technologies. This is an important pattern to implement as a young programmer because often in the hiring process, your skills are often more surface-level, and your value lies in your potential. Developing concrete skills makes you a more valuable candidate and thus more likely to receive an offer.

This pattern makes a lot of intuitive sense. My skills (outside of specific languages) are top-level, and I do not have a lot of projects to demonstrate specific skills and value that I can immediately provide to the company/team I am joining. Currently, my appeal as a candidate lies primarily in my successful academic career and ability to quickly learn, and secondarily in the skills I already possess. In order to successfully find a job, supplementing my portfolio is necessary.

This pattern coincides well with the Breakable Toys pattern in that building those personal, low-stakes projects will allow the developer to demonstrate their skills in a discrete, specific, and demonstrable environment. The toy can then be used in the hiring process, or to develop a demonstration for the hiring process. Having that project available to demonstrate during the interview process will reassure employers that not only does the candidate have potential to contribute greatly as time passes but can also contribute immediately.

I hope to use this pattern throughout the next several months while trying to secure my first career position. I have identified the biggest weakness in my resume to be my lack of full projects to display my skills. I have worked on multiple programming projects that I can use, but they all seem too simple to truly impress a hiring manager. I have a great academic record, but little to concretely prove my development skills. In conjunction with the Breakable Toys pattern, I will look to develop a full-stack project over the coming months that I can add to my portfolio and increase my chances of being hired.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Emptying the Cup. In Apprenticeship patterns: Guidance for the aspiring software craftsman. O’Reilly.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

This apprenticeship pattern talks about how software developers should stay in the trenches. As software developers gain experience, they tend to gain a reputation for being exceptional at delivering software. Many organizations tend to reward with promotions in the hierarchy. However, such promotions might end up leading apprentices away from their craft. This pattern elaborates how apprentices should not confuse promotions into management with success. Being promoted might seem like a good sign that you are on the right path, however, one should understand that they will not remain a “technical” manager for long.  A craftsman who strays from their craft will have their mastery over it fade. The more time you spend not programming, the further away you are moving from being a journeyman.

If an apprentice wants to remain in the craft, then they need to draw their career map accordingly. For example, one could try to discuss with their employer the possibility of finding different mechanisms which they may find rewarding. This could come in the form of higher compensation, or it could come in the form of nontraditional technical leadership roles such as internal consultancy. In the case where the employer is inflexible, then perhaps it might be best to look at other opportunities elsewhere. This way you will remain in the craft and prevent yourself from being promoted away from it.

I personally think that this apprenticeship pattern is useful for people with a specific set of values. It is useful for anyone who values their passion for staying in software development and wants to stay active in the craft. If you are someone who loves software development and want to continue However, some people might value things like status, compensation, and greater responsibility more than remaining active in the craft, and therefore, going into management might be the right move for them. Since different values can lead to different career paths, it is important for software developers to constantly reevaluate their career map to see whether the path that they chose is aligned with their values and circumstances or if they need to consider a different path.

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

This week I would like to look at the “Confront Your Ignorance” pattern. I feel like this is always a good one to look at as despite how good of a programmer you might be, there is always something more to learn, and there is always something you don’t know.

This pattern means there are things you still need to learn/know, and some of these things are things that many others may already know, so it is expected of you to also have this knowledge.

I feel like it is always important to confront your ignorance, as there is still much to learn, even when you have seen a lot. This pattern is very similar to the “Expose Your Ignorance” pattern, but this one is about learning in private, so you do not need to hurt your pride by making others aware like in “Expose Your Ignorance”. However, it is still important to know to expose that ignorance as well, since always learning in private can have some negative side effects, like having failure be unacceptable instead of just another step of the learning process. You need to be able to learn and grow in a way that will positively affect you and those around you.

But should you choose to not learn in private, a great way to confront the ignorance is to ask questions, as many people may have already had the problem you are currently facing, and are hopefully happy to help you overcome the issue. A common cause of ignorance is focusing too heavily one one particular skill or context, which causes you to become ignorant of the other skills. One must be able to learn, and identify the areas of ignorance, and actively work towards reducing those areas.

You must also always be able to admit your faults, in this case admit that your knowledge is lacking, as how will anyone know your knowledge is lacking unless you tell them? This way, everyone can work together to achieve better learning. Of course, it may hurt your pride in the short term, but it is always better to be known for your willingness to learn more, than to know a lot about a few things.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.

The authors of the Apprenticeship Patterns book do an amazing job of capturing my attention. The opening quote that the “Practice, practice, practice” pattern starts off with demanded that I pay attention to what comes next.

“People we know as masters don’t devote themselves to their particular skill just to get better at it. The truth is, they love to practice—“

When I read this quote part of me shimmers with hope because of the proper guidance I was just given to help make it in my future, and another part of me frets because practicing can be difficult and I don’t want to struggle or face the hardship of practicing. Now my issue with practice isn’t that it can be difficult, I don’t mind taking on a challenge. My issue with practice is that I don’t want to be practicing but doing it completely wrong and then feel like I have been wasting my time. The way I picture it is like doing a bunch of push ups but the entire time you’ve been doing them your back was “U-shaped”. You don’t know any better until someone comes along and tells you that you’ve been doing it wrong the whole time. Meanwhile you’ve “mastered” the U-shaped push up but in reality there is no such thing. All the arm strength and muscle memory you built to do that unrecognized form of exercise was for naught, and that’s how I feel I might end up when practicing alone. The pattern does recommend practicing in public places, doing “kata” or finding a coding dojo to code amongst others and have these flaws pointed out as you practice. This sounds like something that would cause my nightmare scenario to never happen but there comes this slight embarrassment when thinking about asking for help or making a mistake in front of others… I suppose it’s a small price you pay while getting better. After all, its better than the former scenario. An old manager of mine once said something to me that still sticks with me today “If you ask once, you’ll only feel dumb once. But if you never ask, you’ll feel dumb forever”. Perhaps I should do more than just think about the profound words and apply them.

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.

Surprise, you probably wont. Lets back up a step first though and talk about what that acronym actually means. YAGNI stands for “You Aren’t Gonna Need It” and is an important acronym to consider for software development applications. I heard about YAGNI from our class, and I wanted to know more about what exactly it consists of, and what its purpose is. Thats where I found a good article by scaleyourapp.com, which did a good job explaining it. In its essence, YAGNI means that you shouldn’t create something until its actually necessary for your application. After all why would you want to waste time on things that might not ever be needed. As many people who have written code know, we often write a function/class expecting to need it in the future, only to never actually use it. This in turn leads to wasted space in the program, wasted time writing the unneeded code, and now you have to think about whether you should bother keeping it or just dump it to save space. I have plenty of personal experience with this in my own projects and work. One particular example that comes to mind is that during a 36 hour hackathon last spring, my teammate and I spent many hours trying to figure out a good way to incorporate a login/user tracking system into the app we were writing. While this feature would EVENTUALLY be needed, for the sake of creating a basic proof of concept app it was far from crucial. Because we didn’t use YAGNI principles we wasted time that could have been spent doing any of the other myriad of tasks we had to do for the rest of the app. These several wasted hours resulted in us not being able to add other needed features, and as such the app was not as complete as it could have been given the time constraints. Even before hearing about YAGNI as an idea, that experience left my partner and I with a realization that there are much more efficient ways to approach writing code than what we attempted. Since then I have been much better about not writing useless code until its needed; however I still have instances where I create a function or class that realistically doesnt need to exist. It can be difficult sometimes to figure out what is needed and what isnt, especially at the beginning of a project. I always assume I am going to need one feature or another, so I begin write it; only to find out a little while later that its not really that important at the moment. While I still started writing it, I have gotten better at stopping before I go too far and waste too much time. That way I can spend more time and energy focusing on more important aspects of the program I am writing.

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.

This week I decided to dive more into APIs in general, not just RESTFUL APIs. So let us start at the beginning. API stands for Application Programming Interface, and it is an interface with a set(s) of functions. These functions allow programmers to use specific features or data of an application. A web API is an API that is accessed over the web, like through the HTTP protocol. The web API is a framework that assists in creating and developing HTTP based services.

An API usually works as follows, the client application initiates an API call, usually to retrieve information. This call is also known as a request. This request is then processed from the application to a web server using the API’s Uniform Resource Identifier, and usually has a request verb, like GET or POST, for example, headers, and a request body. After receiving a valid request from the application, the API makes a call to the web server. The server then responds to the API with the requested information, and the API then transfers the data to the initial requesting application.

APIs are often used for many reasons. This includes, but is not limited to, improving collaboration, offering easier innovation, data monetization (as money makes the world go round), and added security. APIs enable integration such that platforms and other applications can easily communicate with each other, allowing easier automation, therefore improving collaboration. They also offer flexibility, allowing connections to new businesses and reaching new markets, offering easier innovation. APIs are also often offered for free, usually initially, to allow the developers audience to grow so they can build relationships with their audience of developers around their brand for the future, securing future business partners, thus offering data monetization. Lastly, APIs create an added layer of security between your data and a server. Developers can also choose to add further security measures like tokens, signatures, and Transport Layer Security encryption, just to name a few.

There are also many types of APIs, some of which include, but are not limited to, SOAP, or Simple Object Access Protocol, XML-RPC, which is a protocol that relies on XML to transfer data, JSON-RPC, which uses JSON instead of XML for its work, and REST, which we have covered in prior weeks blog posts.

Source:

IBM

I decided to use the above source for this weeks blog post because they provided a ton of good information about APIs in general, and IBM is also a very well known company and therefore also a good reputable information source.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.