The Deep End

This apprenticeship pattern talks about how software developers should jump into the deep end. Many developers take small, safe steps in their career, and this sometimes leaves them unsatisfied. This dissatisfaction could leave developers feeling like they are in a rut, and not just a plateau. When someone is on a plateau, they are consolidating their skills through hard practice in order to reach the next level. However, when a software developer is in a rut, their bland competence eventually decays into mediocrity. To avoid being in a rut or staying in one, a software developer needs to grow their skills, confidence, and portfolio. They need to take on more responsibility, do bigger projects, tackle more challenging tasks, work in larger teams, or try new places.

This apprenticeship pattern discusses how developers should do just that, they should jump right into the deep end. What software developers should not do is sit around and wait until they are ready, that’s a recipe for not doing anything. Instead, when software developers are faced with a challenging role or position, they should grasp it with both hands. This is because growth only happens by doing things that push you out of your comfort zone. If you only do what you are comfortable with, then you are not pushing yourself hard enough.

Of course, doing something like this comes with great risk. If bite off more than you could chew, then things could backfire. This apprenticeship pattern specifically mentions that jumping into the deep end does not mean lying about your qualifications to take a job that you can’t do or doing tasks without adequate preparation. Instead, it means taking on the promotions or the foreign assignments that you were offered. The key is that when taking on a new opportunity, you should assess the risk and difficulty to make sure that your head is above water.

Personally, I think this pattern is something that all apprentices are going to need. Everybody in our craft needs growth to stay on top, and growth doesn’t come without trying new and challenging things. It’s important to take that leap forward if you feel like you’re in a rut. However, when considering new opportunities, it is vital to evaluate the risk. If you find yourself with your head underwater then that means you took on too much risk and you’re drowning. To offset some of the risks, it would be wise to find mentors and kindred spirits who would give you advice and help when needed. It would also be wise to create feedback loops.

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

Apprenticeship Pattern “Retreat Into Competence”

This apprenticeship pattern describes how we should approach difficulties that we encounter along our way of being an apprentice. There will be times when we are working on projects and are faced with difficult challenges that we don’t know if we can overcome, and there are ways to get around this. In the future we will try and expose our ignorance to learn new things, but in doing so we might take on more than we can handle. In doing so, it is okay to take a step and work on something else. Sometimes taking some time away from what you’re struggling on will help you in the long term. It is important that once you take that step back that you then take two steps forward and use that momentum to better yourself. Taking a step back might feel as though you are retreating into failure, but when you work on something you’re comfortable it also adds to your expertise in that area. This then leads to needing to grow as a software engineer and having to learn new things. What we must also remember is to seek support from our mentors and use them to help us become better equipped with handling these situations.

What I’ve taken from this pattern is that taking a step back from what we’re uncomfortable with okay. Sometimes it is okay to go backwards in order for us look back at what we’ve preciously done, then use that to our advantage of progressing forward with our skills. Growth can be looked at from many different views and that’s what we can take from this apprenticeship pattern. There is nothing wrong with facing failure head on, but it’s about how we bounce back that will make us better software engineers.

This pattern has reminded me of experiences I have had in my life. There have been times where I have been put into situations at work where I was required to do work I was unfamiliar with. In doing so, I reverted back to completing work I knew I could do, and once that was done I was then forced to work the things I was not too sure about. In this situation, I then reached out to engineers and other people who could assist me in my work. This then helped me to better understand how to approach this new situation and helped me gain knowledge and experience in completing it later on without the assistance of others.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Craft Over Art

For this week’s blog post, I took a look at the ‘Craft Over Art’ pattern. Now shifting from how to improve your skills as a developer, this pattern describes using your skills to make something that is useful for a customer. The pattern encourages us as craftsmen to mainly prioritize function over form. As stated in the pattern, “The things we build for customers can be beautiful but must be useful,” meaning one should try to maintain a balance between the two. Customers will usually value a quality working product over something impressive but unusable, so it is important to not put personal interests before a customer’s request. A good mindset to have is to be able to sacrifice beauty in favor of utility.

For the most part, I think that this pattern makes sense. Reflecting on myself, I am usually the type to write code to meet specifications as opposed to writing extraneous code that only does the same thing. The pattern mentions the tradeoff between beauty and utility. There will be times when you make the wrong decision and will need to go back and fix the mistake. As mentioned in the pattern, “fixing that mistake by rewriting the system from scratch may not be in the customer’s best interest. In those situations you will need to develop the ability to refactor and repair.” On the other hand, if you cut corners, you will end up with a subpar product by trying to dish out a program in as little time as possible. With the little experience I have in this profession, I can say that customers expect high-quality code and a fast turnaround time. Making such mistakes can be stressful especially when deadlines are involved.

When writing a piece of software that is useful, it is important to maintain the level of quality it should have. One of the ways I can think of that makes code higher quality is to utilize the principles of clean code. In doing so, I end up writing higher quality code that is arguably better to have than having something beautiful. Having clean code will be beneficial in the long run when I will eventually have to refactor my code. As I continue down this path to become a software craftsman, I want to culminate the skills that it takes to consistently produce high-quality code for customers.

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

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.

My First Programming Language (Blog 8)

In 1980, I attended a 3-month course at the Center for Computer Education in Lynnfield and was taught “Structured COBOL programming”. I then worked for the Commonwealth of Massachusetts Department of Welfare for 4 years, using COBOL as my first programming language. I had no real mentors here but did make a number of long-term friends. The lack of a mentor made it hard for me to progress as much as I did later in my career, where I had the advantage of working with some really smart people, so it is good that I learned to love computers early on at this job. I was pretty self-directed. Towards the end of my time at this job, I was able to work with some PL/I consultants who showed me what a “real” programming language was like. With this new knowledge, I was able to change jobs, and to double my salary first at MGH, and then at SEI corporation.

Around this time, I attended a course in PASCAL at UMASS Boston, and a PL/I course at Boston University. These jobs had people who were able to teach me some new tricks, but I also was able to return the favor to them. This lack of mentorship in my early years I look back on as a benefit. I was really “thrown into the deep end” in many places, which really helped me to keep learning as much as I could on my own. If I hadn’t continued to love computing, I would have certainly left my career in its early years.

I really didn’t get “Mentored” until I became a consultant, taught myself C and the Windows 3.1 SDK, and went to work at MIT. Through my consulting years, I worked at 10 to 15 companies, doing Windows UI development and SQL database work. These positions were both enterprise-level and desktop-level. There were about a half dozen people I considered mentors at these assignments, and I also sometimes acted in a mentor role to more junior employees.

I think it was fortunate that I was able to work at so many diverse organizations, because I became familiar with many new programming languages and software products, as well as obtaining a broad view of many diverse industries.

So, starting with COBOL, which I look back on and realize was a terrible language, I entered a journey which would continue to get more and more interesting as time went on. I have programmed in C, C++, C#.NET, PL/I, SQL, and a few others, but didn’t really feel I had found “The Language” for me until I started developing with Java which allowed me to convert to mobile Android development.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.