The “Record What You Learn” pattern suggests keeping a record of the lessons you’re learning during your apprenticeship in the form of a journal, a blog, or a wiki, so that you don’t have to figure something out more than once. You can also keep two records, a public version and a private version. This enables you to find other people interested in the same topics and get outside feedback, but also be honest with yourself about your progress if there are things you want to write down but would feel too embarrassed to post. The writers also advise you to go back and read what you’ve recorded periodically, so you don’t write stuff down and then forget it, rendering this pattern useless.

The action the writers suggest to start implementing this pattern is what we’ve been doing for this class this whole time: write down your thoughts about Apprenticeship Patterns and ideas it has inspired. I’ve found that in any situation, writing down what I’m learning does help to process the information. During my painful Data Structures course, I took notes from the book just to summarize the concepts and make them stick in my head. Additionally, it’s common wisdom that the best way to learn something is to teach it. If you’re making a public record, you’ll get part of the benefit of teaching it by having to put what you’ve learned into words easy for someone ignorant of the subject to understand.

I like the idea of having both a private and a public record, because I would feel hesitant to broadcast what I was learning if I was still unsure of my knowledge of it. I also like the idea of creating a breakable toy to store the lessons, because then the process of recording what you’ve learned will itself be a learning experience.

If in the future I find myself making the same mistakes over and over, I’ll know that it means I’m not writing down or reviewing what I’ve learned often enough. The time investment is worth it, because it’d waste a lot more time running into problems I’ve already solved and having to relearn their solutions.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

“The Deep End” resonated with me, not because I’ve applied the pattern before, but rather because I’ve been thrown into the deep end. When I took Data Structures at a different college over the summer, I found out the course was being taught using C, which I hadn’t yet learned. My dad accurately described the task ahead of me as, “Here’s a new [human] language. Write a novel.”

Worse, the professor was often unhelpful. The pattern, which encourages taking challenges and high-profile roles, warns that you could end up in over your head and drown in trying to apply it. I actually compared my emotional state those first couple of weeks to drowning in the middle of the ocean, because I was so out of my depth, no one could help me, and the consequences of failure were drastic. And I was failing for a while. Assignments were graded using an automated system that tended to give out 100s or 0s with no in-between, and 10 points got taken off for every day late. I fell behind and was submitting assignments late, which in turn gave me less time to work on the next one.

The Deep End identifies Find Mentors and Kindred Spirits as patterns that can be used to mitigate its risks. What eventually made me feel less like I was drowning was identifying the one tutor available for the class who seemed to know what he was doing and reaching out to him for help. He was accommodating and even offered to look at my code outside of his tutoring hours. It was, in fact, finding a mentor/kindred spirit that enabled me to salvage the situation.

Good things came of surviving the deep end. I was able to take Robotics the next semester because my knowledge of C made me feel more prepared than I would have otherwise. My Unix Systems Programming course this semester is also turning out to be much easier than it could’ve been.

The idea for action given at the end is also interesting. The writers suggest rating every project you’ve ever worked on using your own ways of measuring complexity or difficulty, and then plotting new projects that come along in a chart with the others. This seems like a good idea for making sure your career trajectory is going up and consistently challenging you instead of stagnating.

As a final note, the idea of applying this pattern by taking high-profile roles also reminded me of a principle one of my role models has: that if you’re given something you feel you don’t deserve, the answer isn’t to refuse, it’s to take it and work hard to deserve it.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

The “Confront Your Ignorance” pattern offers the next steps after you’ve followed the “Expose Your Ignorance” pattern. It’s not enough to admit that there are gaps in your knowledge; an apprentice software developer needs to be willing to do the work to fill in those gaps. The book suggests several ways to go about this. You might read introductory articles about the subject, start making a breakable toy, ask experts and peers if they’re willing to share their knowledge, or learn alongside someone else. Personally, I think learning with breakable toys would be the most effective strategy for me. I understand what’s going a lot quicker if I can try something myself and see it in action. I’ll also keep in mind asking peers and mentors. A lot of the time, I won’t be able to figure out something that’s obvious to someone who already has knowledge in a certain area on my own.

The writers emphasize that this pattern needs to be used with “Expose Your Ignorance.” Confronting your ignorance without exposing it means fostering a culture where failure and being seen learning are shameful and must occur in secret. It will also probably be more difficult and time-consuming if you don’t ask for guidance when you’re stuck. Exposing your ignorance without confronting it means you won’t be able to solve any problems outside of your particular niche, and others won’t appreciate it when the gaps in your knowledge prevent you from fulfilling your responsibilities.

This is also the first time the writers have mentioned a situation in which you should prioritize the job over the apprenticeship. It’s possible to be so caught up in your drive to learn more that it gets in the way of delivering the product. You might also be tempted to go about solving problems in a way that helps you learn what you’re trying to learn, but is impractical for others. You should be striving to improve your craft, but not at the expense of your team and your duties. Part of being an apprentice is putting the needs of your community before yourself. These guidelines provide a good balance between the greater goal and what’s more immediate.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

The “Expose Your Ignorance” pattern encourages software apprentices not to feign competence when they don’t know how to do something, but instead to nurture and showcase their ability to learn by admitting that they don’t. According to the writers, the problem is most likely to come up when your managers or team members assume or want confirmation that you know something. You can still reassure people in these situations, but with your capacity to learn instead of by being dishonest about your abilities. In this way you can build trust by showing you can be counted on to figure out how to do what’s needed, even if you can’t do it yet.

Exposing your ignorance doesn’t seem like such a difficult thing if there are no expectations of your knowledge level beforehand, but letting someone know you don’t understand something they thought you did seems almost unbearable, especially in a situation where your ability to do your job depends on understanding it. I hadn’t considered that I might be put under pressure to project an image of having knowledge in an area I don’t, so I’m glad to have some ideas of how to respond to it before it becomes an issue.

Another thing I hadn’t considered was the idea that becoming an expert is something to be avoided, or at least not the main goal. The authors explain that to be a software craftsman, you can’t become confined to a specific domain or skill. This is what naturally happens if you’re too afraid of exposing your ignorance to learn new things. Here too, the idea of having a greater goal to pursue is helpful to me. I would rather be a software craftsman than an expert in one area, because it would help me to keep my options open. Being good at only one thing also means you run the risk that the skill will one day become obsolete.

The advice to publicly post a list of things you don’t understand about your work surprised me. It seems like it would be a painful thing to do, but it does also seem like it would help you get used to putting this pattern into practice. It might end up something I try in the future.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

The “Unleash Your Enthusiasm” pattern from Chapter 2 of Apprenticeship Patterns was interesting to me, because I hadn’t previously thought about what an apprentice might be able to add to a team. I didn’t even really consider that there were things an apprentice could add to the team, apart from the promise of future skills acquired during their time as an apprentice. But according to this pattern, the enthusiasm of the beginner software developer is a valuable asset, as it sparks the enthusiasm of the more experienced developers on the team. The authors encourage you not to suppress it in an effort to blend into the status quo, and in fact assert that it’s an apprentice’s duty to bring their enthusiasm to the work. Moreover, apprentices are comparatively blank slates who are more likely to suggest creative new ideas that developers with more entrenched habits wouldn’t think of. These should be shared instead of held back out of fear.

I did disagree a little bit with their statements about unwelcoming environments, which seemed to undermine their overall point. The last thing someone who’s unsure about sharing their excitement needs is to have it suggested that they’ll be secretly looked down on for it. Even in groups that don’t seem hospitable to a newcomer’s enthusiasm, there might be more inconspicuous ways of introducing it. Maybe enthusiasm can be shared with individual team members that seem open to it. The group’s status quo could be slowly altered from more private morale boosts, but even if it isn’t, you’ve still shared your excitement with someone. And maybe that’s a bad idea for reasons that aren’t obvious to me yet, but as an apprentice with no preconceptions, it’s my responsibility to share maybe-bad ideas.

After reading about this pattern, I have no doubt that it will come to mind in situations where I feel self-conscious about my enthusiasm and suggestions. I’ll have the ability to recognize now that it’s one of the few commodities I can offer my teammates, and that it won’t last forever, so I ought to use it while I can instead of restraining myself for the sake of pride.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

The blog post this is written about can be found here.

This week I decided to look into software frameworks, and I picked this blog post because of its concise explanation and because it included advantages and disadvantages to using them.

Software frameworks provide developers with ways to create applications without starting from scratch. Instead of writing every piece of functionality, you only have to write the pieces that are unique to your application. Like a framework for a building under construction, they’re bare-bone essentials for the type of project you want to create. Using a framework allows software to be developed more quickly and with higher quality, as software frameworks are pre-tested. With less to worry about coding and testing themselves, developers can focus on fulfilling their specific requirements instead of reinventing the wheel.

Software frameworks adhere to the inversion of control design principle, in which the general framework instantiates and invokes the objects and methods specific to your application. This contrasts with using a software library, in which a custom application instantiates and invokes the objects and methods that belong to the library.

Some other advantages to using software frameworks, as the blogger writes, are that they can encourage better programming practices and appropriate use of design patterns. Upgrades to the framework can also provide benefits to the framework users without them having to do additional coding of their own. Lastly, software frameworks are by definition extensible.

Among the downsides are that if you wish to create your own software framework, it’s more difficult and time-consuming to create the first application that utilizes it than it would be without the framework. However, if well-made, the development and testing effort will be reduced in all future projects that utilize it.

Another disadvantage is that frameworks can be difficult to learn. This can negate the advantages of the framework for the first project a developer uses it for similarly to how they’re negated for the first project that utilizes a brand new framework. Finally, frameworks can grow increasingly complex over time with updates and additions.

Though they certainly have their disadvantages, software frameworks seem like an intuitive solution to me. If I’m tasked with doing something a hundred times with slight variations, after a while, it only makes sense to find the commonality between all the instances and use that as a base to add the variations to. Additionally, in the future, I will keep an eye out for whether software frameworks are available for the type of project I’m trying to create and use them if the benefits outweigh the effort needed to learn them.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

The article this blog post is written about can be found here.

This article gives an overview of web application testing, which has several aspects unique to it compared with other software testing. I chose the article from a few sources on web testing because it was easily understandable while providing enough detail to get a feel for what’s involved.

One of the forms of testing highlighted in this article is usability testing. This includes verifying that there’s a consistent look and feel throughout the site, the application is easy to navigate, and it’s clear to users what options they have available to them. The article also makes note of the 1998 amendment to section 508 of the Rehabilitation Act, which outlines accessibility requirements for people with disabilities on information technology systems belonging to the US federal government. Section 508 compliance isn’t necessary for any non-federal website, but making sure to include accessibility features opens your web application up to a wider audience. The article gives the example of what your application should do if a user fails to enter a required field: simply changing the field title’s color to something noticeable like red, as is commonplace, wouldn’t be useful for someone who has trouble distinguishing colors. Another visual cue like an asterisk would be useful in this situation.

HTML verification is another form of testing for web applications. Testing for correct syntax is the obvious form, but it also includes testing the way your application displays across different internet browsers, OSes, screen resolutions, and device types. Your application may be usable and look great in one context, but break in another.

Load testing must also be done on applications that are intended to be accessed through the internet. They have to be able to function during times of high traffic, and testing of this sort can be used to find bottlenecks. In addition, performance tuning is prudent. All pages of your application should load quickly – the article suggests within 15 seconds.

User acceptance testing is used to determine whether your application does what it set out to do and makes something easier for the user instead of harder. One way this can be done is with a beta release.

Finally, of extreme importance in web applications is security testing, which should be done by qualified security specialists. The damage that can be done if this is neglected is immense.

This article gave me a good introduction to the additional testing required for web applications. Of all the details, I found adherence to section 508 especially interesting. It might not be a legal requirement for anything I design in the future, but if I ever do design a web application destined for the real internet, I will definitely want to make it accessible.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.