“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.

Advertisements

Sprint Retrospective 1

The focus of the first sprint was cloning and building AMPATH’s existing code on our own systems in order to get us in a position to begin adding the desired functionality. Additionally, we set up our team’s Trello scrum board and our team GitHub organization, and we began learning about both Angular testing and the JIRA project tracker. We ran into problems most significantly when we couldn’t build ng2-amrs due to compiler errors, but by the end of the sprint we were all in a position to successfully build it.

I downloaded Visual Studio Code and an add-on for TypeScript to use as my editor for this project, since WebStorm runs so slowly it’s impossible to use on my laptop. This is the first editor listed in the recommendations in AMPATH’s readme file, and so far it runs smoothly for me.

To start off the sprint, I created our GitHub organization and invited all team members and Professor Wurst. George forked the repository from AMPATH. Everyone cloned the repository, and we began going through the readme file. We installed the required dependencies and began attempting to build ng2-amrs, at which point we began encountering errors. Matt figured out that some references to ladda.min.css and ladda.directive.js were producing the errors and implemented a fix that resolved the errors. He created a list of instructions for fixing the errors and shared it. Members of other teams (Oren and Rick) made corrections to these instructions. I and others on my team made the outlined changes, after which we were able to successfully build ng2-amrs.

After this, we learned about doing scrum on JIRA, and some of us went on to learn how tests work in Angular. Matt and George were able to connect ng2-amrs to the server.

For JIRA, I consulted Atlassian: https://www.atlassian.com/agile/tutorials/how-to-do-scrum-with-jira-software. To learn about Angular testing, I began reading the official Angular testing guide: https://angular.io/guide/testing.

Our team worked closely in the beginning, but then began to work more independently when installing the required dependencies took varying amounts of time for all of us. We shared Matt’s fix to the ladda compilation errors and aided each other in implementing the changes as team members became ready. Our team had difficulty showing up in full to the stand-ups. We haven’t yet decided as a team any specifics as to how we will proceed differently, but I hope to get from everybody a reliable way of contacting them so we can increase our team’s communication and so I can provide reminders if that’s something other team members would appreciate. I think our team will do better if we can close the gaps in the progress we’re making as individuals.

As this sprint consisted mostly of set-up tasks, I didn’t learn much that could be applied to future situations apart from the way our team functions. In light of this, I would strive to keep us on the same page and updating each other on our progress.

To do the same work we did, someone could fork and clone ng2-amrs and follow the most recent set of instructions to fix the ladda errors. Better yet, they might be able to proceed without having to fix anything, as the pull request containing the necessary changes was approved and merged into the course repository’s master branch.

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.

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.

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.

The first chapter of Apprenticeship Patterns introduces the main concepts used throughout the book and outlines the book’s purpose. Software development is treated like the kind of craft practiced in medieval guilds, where there’s an apprentice stage, a journeyman stage, and a master stage. The book is a pattern language meant to serve as a guide for navigating a software apprenticeship, consisting of solutions to common problems people encounter in the apprentice stage. A software apprenticeship is defined as a stage where you, as a new software developer, are working to find better ways of doing things; as well as people, jobs, and situations that force you to learn those ways. It’s a period composed mostly of focus on yourself and your growth (as opposed to responsibilities to others) and continuous learning.

Before reading this, it hadn’t occurred to me to treat specific jobs as opportunities to learn and improve the craft, rather than the learning of the craft being a prerequisite for getting a job. The mindset demonstrated in this introduction seems to emphasize valuing software development as a craft in a way similar to the way I’ve seen artists talk about valuing art for the sake of art. It’s an attitude I didn’t really expect to see in a STEM field, but it’s one I’m very open to, since I’ve found that believing in the inherent value of the work you’re doing (instead of being motivated only by outside factors) is one of the best ways to maintain passion. It also would’ve never crossed my mind to think of a career in software development in terms of medieval craft guilds, but the roles outlined in the book made me want to fail a lot in the beginning so that I can learn from it and not fail when I have greater responsibilities later on.

The idea that you’re not supposed to know how to do everything at this stage is one I found comforting. Reading Dave’s story made me feel less insecure about my own late start in this field of study and my ignorance, which I think was partially the point.

The prospect of having to carve out your own apprenticeship because the industry isn’t currently structured to support it is somewhat intimidating, but I’m also intrigued by the idea and think this approach could be fun. Pursuing a goal beyond and bigger than meeting the requirements of a certain job or just plain advancement naturally seems more enjoyable.

I expect this book will be useful to me because I need challenge in order to be happy, and it promises advice on how to avoid pitfalls that will lead to me losing the challenge that made me choose this major in the first place. I’d be interested in reading this book even outside the context of this class because I’m unsure about basically all aspects of trying to start a career, and having some ideas of how to navigate it will be helpful.