Category Archives: Week 12

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.

The Deep End

For this week’s blog post, I have decided to talk about the chapter “The Deep End”.  The idea with this chapter is that you a software developer, feel as though you have hit a rut with your learning. To be able to feel confident you need to grow your skills, your confidence, and your portfolio of successful work. You feel the need to challenge yourself with bigger things. This may involve bigger projects, larger teams, more complex tasks, new and business domains, or new places. The solution to this problem is to jump into the deep end. The longer you wait and stir with the idea that you are in a rut the longer you will be in that rut. If an opportunity comes up when you can take a challenging job you should take it, most people learn by taking difficult jobs and expand their knowledge from the research it provides. According to Dave H. Hoover & Adewale Oshineye, the authors of the book, they say on this,

“Even though we advocate seeking out the most challenging tasks you are capable of, you still need to remember that if the water level is above your head it means you’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’s your responsibility to offset the risks of this approach by Finding Mentors and Kindred Spirits who can provide help when you need it” (Dave H. Hoover & Adewale Oshineye)

This means that if a job is too over your head, don’t take it just to prove yourself. If you need try to find a mentor that will help expand your knowledge. I found this chapter to be very interesting. I like how it talked about how if you feel as though you have reached the end, try to grab a more challenging project to expand your knowledge. I liked this because it reminds of being in school and being assigned project that I knew nothing about. By working on them and doing research I found those project to be the most fun to work on. This chapter will definitely be applied while I am out in the field as I will remember that enjoyment from school.

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

The Long Road

You should plan for the long run and not focus on short-term goals. The further out you plan for yourself the better you will be prepared for unexpected challenges. If you want to program for a very long time, then you’ll be more skilled than people who are newly coming into the field and this will benefit you. It is important that being a master at the craft is the goal and not wealth or another position. It is important to stay motivated to program and not be distracted by nonessential things.

I find it interesting that it’s possible to get distracted over time while you’re at your job. I think it makes sense that over time you lose focus of the goal. It’s easy to be tempted by money to find a different job and stop programming. I think it was a good reminder to stay focused on your passion for becoming a master of the craft. Mastering the Long Road means balancing your work life and goals to meet a long-term desire for programming.

This pattern will help me focus on keeping my motivation for programming. It’s important to have an outlook of what you want in the future rather than just focusing day-to-day. Focusing on becoming a master at programming will also make money. But if you just focus on making money then you might not become a master. Someone motivated by money is not going to have the desire to learn to program. I personally have encountered this with friends who have software engineering jobs. They dislike their job and are only there for the money. They’re always looking for different opportunities and never spend time learning to program, they spend time trying to figure out how to get a different job.

I do not have any disagreement about what is discussed in this pattern. I think it is essential to stay motivated on the task of learning programming and not be distracted by other less important motivations. I think it is possible to have the motivation to become a project manager or a CIO while also maintaining your passion for programming. However, I think this pattern is correct in that the ultimate motivation should be about programming and nothing else.

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

CS 448 Post 5

My next post is on the problem Sweep the Floor from chapter 4, which has to do with when you are getting started on a group project and want to be able to contribute to the team and grow your own skills. This problem got my interest the most in the chapter because it is a problem that I have when I am in anything that needs a group effort, usually projects, and I think this is a common problem for people. Whether it be a project for school or work, a team based sport, or other activities that involve teams, contributing to the activity and earning trust from your team are the main concerns.

I tend to worry about not doing well and holding the team back, and the solution offered matches what I usually do to prove myself. The recommended solution is to start with the “simple, unglamorous, yet necessary, tasks” and work your way through your tasks to show what you’re capable of. When it comes to contributing and earning your teams trust, the two concerns usually go together because it will be your contributions that help you earn trust, and you can improve yourself as you work and do your share of the workload. The type of tasks you do are also important because what you complete can show your capabilities, and you will want to do some of them that you may not enjoy but are necessary for the project to show you are willing to do them.

While it is important for you to contribute to the team, you want to avoid getting to the point where you end up doing more work than others, or are the only one working on the “simple” tasks that the others do not want to do. Either you are the one stuck with those tasks, or those are the only tasks you are doing and are not doing any of the higher level tasks and can’t improve yourself. It can be difficult to contribute that way, and you won’t learn that much. Team projects can be beneficial to the members working together and improving them all at a higher rate than working alone, but it can also be difficult to divide the work and for new members to the team to contribute.

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

Craft over Art

Craft over Art is a drastic change in tone from the rest of the patterns I have covered. All of the previous patterns I have read have been about how to advance myself as a developer, while this pattern is more how to act as a developer. Craft over Art stresses the importance of providing a useful product for a customer instead of a wildly experimental one that might not work. I would argue that this still is about advancing myself as a developer, but in a different, more practical way.

Obviously I should continue to do everything else discussed in these patterns, but I feel like Craft over Art will be the most immediately useful. This pattern can be implemented day one of your first job. It also is the most important pattern for your employer, since they care about actual products. I would imagine many apprentices are very excited to enter the industry and make something amazing, but this is simply not the reality of the profession. Real customers want products that work, do not need complicated maintenance, and are industry standard.

Craft over Art then goes on to explain that when you are rushed to deliver a product you must make compromises between beauty and utility. These compromises will inevitably lead you to a mistake, and you will need to fix it. This is a good thing, the pattern argues, since only by fixing things do we realize which compromises are the correct one.

This idea is a liberating one for me. The fact that I need to mess up in order to learn means that people will expect me to mess up. I feel like this takes a weight off my shoulders. The stress of working on real products with real customers is one I think is very common.

I am glad I read this pattern for my last blog post. I did not plan it, but it was a very nice surprise. Over the course of a semester reading about how I should improve myself, it is a nice shift to learn about how to provide a useful product for my customers.

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

Stay in the Trenches

Stay in the Trenches is about how you must stay on your path and focus on learning rather than promotions. If you are offered a promotion which takes you away from what you want to do, you should reject that promotion. This of course does not mean that you should never accept promotions or advancement, but you should always remain focused on what you want to do with your career. This pattern implies that you want to program, and I do, but I can see this pattern applied to many more disciplines.

Over the course of all these patterns one thing has been emphasized more than anything else: as an apprentice, your primary goal should be to learn. This pattern spells that out more than any other. This pattern is a very tough pill to swallow, but it is very good advice. Sometimes you need to be told things you don’t want to hear, and should listen to advice from people who have made mistakes before you.

I like this pattern since I am a very promotion oriented person. I can see myself taking the quick promotion and I needed this pattern to guide me on the right path. Throughout my working career I have taken the promotion when I should not have. This is different from what Stay in the Trenches is talking about, but it shows what kind of person I am. I need to be aware of that going into the future.

One thing I wonder about is when should I take the promotion? You are always able to learn, when have I learned enough? Fortunately I don’t have to worry about this for a while, and I think that it is an easier decision than I’m thinking it is. Right now I do not have the experience to tell what I want to do, and what I’m ok with not doing.

The pattern also suggests that instead of taking the promotion you should work with your employer to find other, more advanced tasks that you can take on. I like this idea since it allows you to continue programming, but it also might not offer the same pay or benefits.

Overall I like this pattern, it is one of the better ones I have read so far. I think my favorite patterns are the ones that tell me things I don’t want to hear; things I already agree with is not really teaching me anything. It is easy to take the advice of work hard, but not so much to pass up promotions.

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

Craftsmanship Log #7 – Digging Deeper

One thing that the field of Computer Science is rather notorious for is that, for new learners, the entry level may seem incredibly low for someone who is interested in pursuing programming in any degree. Given the abundance of freely available resources for learning programming languages, this should not be that much of a surprise. It is easy for someone to find a tutorial online on how to implement inheritance in JAVA, with such tutorial presenting this concept through some oversimplified example. This, in and of itself, is not a bad thing; it is important to learn things in smaller steps. However, some software development apprentices may take to simply memorizing the knowledge they acquire and how to simply implement the tools available to them without much understanding, thus acquiring only a superficial understanding compared to a deeper, more thorough understanding, which in the future may become a habit that can interfere during the development of bigger projects. This situation is introduced as a pattern titled “Dig Deeper”.

What this pattern means for an apprentice developer is that, oftentimes, they may have found themselves in part of the development where their technical knowledge at that point in time may seem to be lacking because the superficial knowledge they have gained during the learning process was not sufficient to provide meaningful contributions in a project of a larger scale, especially in a professional environment. For example, someone who may be working on deploying a web-based application may run into this pattern. The apprentice, though they may know a bit about how REST APIs may work, they may still find themselves struggling because the project they are working on presents concepts that are impossible to cover in a simple tutorial. The apprentice may know how to implement functionality on the backend, but have neglected to get a  deeper, understanding of how such functionality may impact the frontend. Thus, when something in the frontend fails because of the backend, the apprentice may provide a solution that in the long-term does little to solve that problem. Overall, an apprentice who, regardless of their proficiency in their area of expertise, does not take the proper care to understand how such expertise may interact with other areas can hinder the long-term maintainability of a project, as well as have a negative impact on the apprentice’s own learning process.

While it is impossible to be an expert on every single concept and tool that exists ,not only within one’s area of expertise, but also for every single area that may constitute a bigger project, it is still important to take the time to gain a deeper understanding of how other areas work in conjunction to one’s expertise.

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

Expand Your Bandwidth

Similar to prior weeks, you have a basic set of skills, and your understanding of software development is narrow and small. Expanding your bandwidth allows you to further expand your horizons and learn more. The best step to solve this is to take in new information, but it is important to do so carefully, as it is easy to be overwhelmed in the information intake.

Some examples of ways to gather the new information is through following software development blogs, following software developers on social medias like Facebook and Twitter, and subscribing to a software development mailing list, just to name a few. There are also many hundreds of online courses and videos as well, so there is no shortage of information to be had. Following software developers can key you into new technologies before they become widely popular, which can give you a head start into the game before others. There are also national conferences that you could attend as well, and another great thing to do is to read any books some of the speakers have written in the past, so you can help get an idea of what they will be talking about and their software development history.

However, it is just as important to know when to expand your bandwidth then just how to as I explained above. It is possible to get stuck with the gathering of information, and it can easily happen where you get stuck researching and learning and never go back to creating any software. It is important to use this skill to accelerate your learning, but it is also important to not get stuck with the learning, learning is a means to an end, you must come back when you are done with the learning. Usually it is recommended to not spend more than a few months with this learning process, as that allows you to not get stuck in the learning process, as it is not too long, but it is also not short enough to the point where you do not learn much of anything at all.

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

The Deep End Pattern

For this week’s apprenticeship pattern, I did a reading on “The Deep End”. The Deep End is all about growing your skills, confidence, and your portfolio. At times you may feel as if you need to challenge yourself with bigger things such as projects or complex tasks, etc. This pattern tells you to literally jump in the deep end. For example, if you were offered a high profile job, then grasp it with both hands and take it on a ride. However, this does impose some risks because you could fail. Even if failing does happen, and be prepared if it does, recovering from a failure will opens many doors that those who are scared to take risks will never see.

My initial reaction after reading this pattern is that I can relate a lot with what this pattern has to say. I am constantly applying to jobs and some of them have requirements that seem to be out of reach with my portfolio that I have built up. Some descriptions of the jobs I see to me, makes me feel like I would have no idea what I would be doing, however I still apply to those jobs because I know I am more than capable of learning and implementing what I learn quickly and with accuracy. The reading was quite interesting and very useful. It is useful because it allows me to feel like I am not alone in these types of situations and its interesting because it talks about the many ways of how to get through it. It ties with other patterns I have talked about and mentions finding a mentor and just being brave and confidence.

The pattern has not changed the way how I view my profession because I know that many job postings will always have some sort of description to make the job sound harder than it is, and even if the job is hard, you can always learn and ask questions. I know that if I fail to get an offer, that means that I am lacking something, and it allows me to know what I need to work on. I am constantly practicing my skills and working on side projects to help myself get a good grip on how each technology work to ensure that I have the proper skill sets to tackle these types of problems when I eventually start my professional career.

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

Rest API

Rest API are a common method for integrating applications in their services to provide more reliability and to be flexible where possible. I chose to use stackoverflow.blog as my blog because they are filled with information in regards to many programming languages, AI, databases, especially Rest Api and etc. The blogs also discuss and provide certain authors that give explained details on the processes and focus on implementing, as well as common problems that may erupt with certain solutions that can lead an aid to a professional career in software development world. As this website have given me a clearer perspective while in my Software Construction architecture class along the way working on our Food pantry project.

As for Rest Api, they are a common web service used in today’s technology. Allowing the client (person making the request) to communicate with the servers (receiving the client requests) with is the Rest Api that is connected to a database. To keep in mind, when creating an API, we use always separate the client from the server to made to interact on one way because due to fact that clients can make requests but not responses, while server can make response but not requests. We use HTTP methods as an action for the client wants to make. GET Method allows the clients to request the information from the backend. POST Method is creating or listing the information. PUT Method is editing the information. DELETE Method allows the deletion of information.

JSON (JavaScript Object Notation) is a basic format to help the programmer to easily read write out code for the computer to understand and generate the output and cache the responses. API endpoints are the end of the communication, which utilizes the services or the response. For example, when making a request on the API rom the browser or an application, the response will then be received that reaching that point will be the endpoint. 

After learning about REST API in my CS-343 class and working along the course. I start to begin to gain more confidence and gain more insight on how the process works. And designing the API which gave me complications for the backend and frontend as well. Realizing even the slightest misspelled command or wrong path can leave you clueless on fixing the problem but understood why the situation erupted. This material could’ve been useful for my database course I have taken previously to implement the databases on the server to be integrated along with providing the appropriate security from the client side with restrictions, while the backend is able to store, modify if allowed. 

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.