Looking Back on Sprint 2

The second sprint was a bit more open ended, with far fewer discrete tasks to complete than during the first sprint. This meant that rather than working independently during class to complete individual environment set up tasks, we worked as a team during class to discuss the user stories contained in the Google Doc. I feel that once again the team worked well together and everyone contributed to achieving the goals for this sprint. There are a few places where I see room for improvement, and this was discussed during our in class retrospective meeting.

One of the first tasks that I personally completed this sprint was looking at the mockup tool, Balsamiq. While I was a little unsure about this at first, seeing some of the mockups that other teams did later on in the sprint helped me to better understand the tool. I think that for the next sprint, using Balsamiq as a team to visualize our ideas will be extremely helpful.

Although I had already completed the build ng2-amrs and connect your ng2-amrs to the server tasks, these tasks remained on the sprint backlog because not everyone on the team completed them during the first sprint. By the end of sprint 2, however, all members of the team had completed both of these tasks and they were moved to the completed board. This was important because these tasks are essential to beginning actual development, which will likely occur as early as the next sprint.

Another task that was left over after the first sprint was learning how tests work in Angular. Although we were told at the end of last sprint that this task was probably not essential, we decided as a team to include it in the second sprint because the majority of the team had already completed it. Members of the team who had already looked at resources on Angular testing shared their sources with those who had not yet completed the task.

The most significant tasks for this sprint had to do with generating design ideas from the user stories shared by the AMPATH team through the Google Doc. We met as a team during class time and began by reading the user stories together as a group. Although much of the team had already read the user stories independently before class, I feel that talking them out was helpful in providing clarification. Members of the team shared their individual understanding of different parts of the document, and asked questions where understanding was lacking.

After we felt we had a general understanding of the user stories, we looked as a team to the tasks that were listed further in the document. We then brainstormed ideas in a document for the first task on the list. This is the task that addresses offline login and offline data storage. We collaborated with the group directly behind us to share our thoughts and also get a better idea of how they were planning on going about development.

I think that we as a team are becoming more comfortable collaborating with one another, and also with sharing our ideas with among the other teams. I think that in future sprints we need to continue to attempt to clearly communicate our intentions with other teams so as not to do overlapping work. Although the effects of duplicated work were not very severe during this sprint, it could result in a lot of wasted effort in the future. I am looking forward to continuing to work with my team in the third sprint and using what we have learned to work effectively and efficiently.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

Overall I feel that this sprint could have gone better, but as a silver lining, it gave us an opportunity to see what we need to improve on moving forward.  Luckily this happened early on in the project and wasn’t an issue that went unnoticed until the semester was almost over.  The important part is to reflect on the faults of this sprint in order to improve and avoid the same mistakes moving forward.  I do believe that we did start to come together as a team and work well together.  I feel that everyone on the team is willing to listen to everyone else’s opinions without passing judgment or shutting each other down even when disagreeing.

One important piece that we did not do is documenting.  We should have documented what we figured out to help us navigate what we were learning.  Looking forward I plan on taking personal notes recapping the team meetings just to keep a personal track on what we talk about.  I feel that we also need to encourage each other to start documenting what we find when working outside of team meetings, or even what we may come up with during the class time.  This will help reinforce what we learn and also allow us to more effectively share it with the rest of the team.

Another problem area was assigning tasks.  There’s an old saying that I learned years ago that if a job is assigned to everyone than it is assigned to no one.  Meaning that if it is kept general and said that “this is a team task” without specifying a role for every member, even if it is explicit for each member to complete the same task, then there is a strong chance that no one will do it and expect a different team member to do it.  There needs to be direct ownership of tasks to ensure they at least get worked on.  When there is no ownership that also means that no one can be held accountable for failing to do it.

The sprint wasn’t a complete failure though.  We read through the user stories to get a better understanding of what was going to be expected of us.  This also helped start team discussions as to which service and task we wanted to take on for the majority of the semester.  This also helped get us started on mapping out the program and services that the class will be working on improving.  We started to look at the ng2-amrs code both on our own and during the last few class periods.  We started to look at where we login to the site and walked through the code starting from the login to try and map out how the program runs and works with the REST API.  Again this would have been better to write some kind of documentation to reinforce our understanding of this mapping.

While not the most successful sprint I do believe that it was productive from the point that we learned what not to do moving forward.  My hope is that we can build on our failures and become more successful for the rest of the semester.  While it’s important not to dismiss this sprint entirely we can’t let it bring us down and lower the team’s morale.

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

Sprint 2 Retrospective

Overall, I felt that Sprint 2 went pretty well. It was the first time going through a full planning session rather than having it set up for us. I felt the planning session went pretty smoothly considering it was the first time all of us were going through it as a team. The team also continues to work well together. I can feel we are getting to know each other better day by day, including both some common personal interests to keep conversations going as well as getting a better idea for what each team member is good at/capable of. I feel that knowing these kinds of things is important for the team to work well as a whole unit rather than a bunch of individual pieces. People are getting better about attending the standups as well, which is good to see as they are important in helping keep each other informed on what is going on in between classes. This also helps prevent duplicating work. We all seem to be on the same page more and more.

We accomplished pretty much everything we wanted to accomplish this sprint. Everyone had a chance to check out Balsamiq. To me it seems like a useful, easy to use, intuitive tool. Hopefully we will get a chance to actually put it to good use at some point later on down the line. We also continued to research angular testing. There is a lot of information out there on it, so I feel this will be a continual activity throughout the semester whenever we have some spare time. Overall, the tests don’t seem overly challenging to write. There was also a continued effort to get eveyone’s ng2-amrs running and connecting to their servers. I believe everyone is up and running on that front.

The big task this week was coming up with design ideas based off of AMPATH’s Google Doc. The document was a bit overwhelming at first as it was a bit of an information overload. There are a lot of good goals/ideas in there, so we decided that it would be best if we focused on one of the goals they had. Otherwise we felt we would be spreading ourselves too thin. The goal of choice was to add the capability to login offline and store data offline. We chose this one because it seems to use that it would be the most useful feature considering the environment/places they work in at times. We ended up making a document with some basic things that we know need to be done in order to accomplish this goal. Some of these included finding a way to encrypt patient data and user passwords. We will have to coordinate with other teams on this as we are aware that another team has already started to look at this. We also know we will need a way to communicate with the main platform and have a way to automatically update their database once the tablet is back online. Those were just a few of them. The whole document can be found on our team’s slack page if you are interested in seeing all of them.

I feel if we continue to work together like we did this sprint we will be in a good place come the end of the semester. I don’t see any major changes that need to be made to the team at this point in time. I look forward to continue to work with my teammates come sprint 3.

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Software Development as an Art

Hoover and Oshineye make some excellent points that I strongly agree with in the Craft Over Art design pattern in Apprenticeship Patterns. Although I had never thought about software development in terms of art, I found their discussion of art versus fine art to be interesting and well supported. While it is relatively simple to argue that software development is a craft, I would imagine that claiming that it is art would generate a bit more controversy. In my opinion, Hoover and Oshineye do an excellent job of supporting their claims that software development, by nature of being a craft, is also an art – but not a fine art. The distinction that they make between craft and fine art has to do with purpose. Because software development’s purpose is to make a useful product for customers, it can be seen as utilitarian in a sense. The purpose of producing fine art is purely for beauty.

The important caveat that Hoover and Oshineye introduce in the Craft Over Art pattern is that the craft of software development may produce something beautiful, but it must produce something useful. This may mean that craftsmen must choose utility over beauty when it is necessary. Considering the interests of the customer over personal interests and balancing conflicting demands is important in building and maintaining strong relationships with the customer.

This pattern applies in a couple of ways to my current undertakings. The importance of creating software that addresses real problems for real people is something that is somewhat new to me. Writing code for AMPATH Informatics is exciting because of the real-world significance that my contributions have. The other place where this pattern applies is in my independent study web development project for Massachusetts HOSA. While the customer-development relationship is a bit different in both of these cases, many of the same tips from the Craft Over Art pattern apply. While I may not be paid for my services, I still have expectations placed on me by the instructors and organizations involved in these projects. Understanding and carefully considering my responsibility to deliver a product that is first and foremost useful will help me to foster strong relationships with the collaborators on these projects.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Emptying the Cup: The Deep End

In this Apprenticeship pattern “Emptying the Cup: The Deep End”, it explains on how you as a developer can further your development skills by taking on challenges that may or may not involve risks. Even though there may not be risks that can affect your career as a software developer, it may cause you to fail the challenge or objective you are trying to accomplish. Of course in any industry of work that you may wish to advance or climb the ladder in, you have to tackle on bigger tasks to show that you have the skills and mindset to be in a bigger and better position than the one you are currently in. However, failure can result in the process. The Apprenticeship pattern “The Deep End”, highlights that failure is normal when taking on challenges.

“This has risks. If you get it wrong and end up over your head you could drown. Thankfully there are many places in IT where you can take risks without destroying your career if you fail. Risks are opportunities seen through the half-shut eyes of fear. This doesn’t mean lying on your resume to get a job you can’t do, nor does it mean tackling challenges without adequate preparation. Instead, it means taking that promotion or foreign assignment when it’s offered, even if the very real possibility of failure is staring you in the face. Being prepared to fail and recovering from that failure opens doors that the timid will never see.”

Drowning in this context means failure and I completely agree with this idea because as an individual, I learn best by failing and making mistakes. At times, I can be scared to fail but I know deep down it is the best way for me to learn. This pattern also reminded me that feeling fear is okay when you I think failure is staring me right in the face because the after effects of failure is more of a gain for me when taking on a challenge than being successful on a smaller, simple task. After I fail a challenge, I reevaluate what I did wrong so I can approach it differently the next time I take that same challenge head on. This concept of taking on “The Deep End” isn’t only important in Software Development but it can be applied in any workplace.

 

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

CS@Worcester – Fun in Function 2018-02-25 23:45:05

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.

Thoughts on the Breakable Toys pattern

The Breakable Toys pattern addresses the issue of learning by making mistakes in an environment where failure is not an option.  This can mean that learning substantially more difficult.  The solution that they propose is to build yourself an environment in which failure is allowed to happen.  The apprentice does this by creating a pet project (even if it’s reinventing the wheel) and just trying things until something works or something sticks.

This pattern really resonates with me and the way I learn.  I can’t just pick things up by reading code or manuals, or copying premade solutions.  I need to get my hands dirty and build things.  Sometimes I’ll “sketch out” programs first by building a skeleton of files I know I want and adjusting as I go.  Sometimes I implement the core of code and let the rest of the program grow around it.  Neither approach is necessarily suitable for a professional environment where expectations may be high, but it helps me learn.

I also think that the Breakable Toys pattern can be applied in a more limited way to a more pressured setting.  While you might not be able to just declare failure when tasked with writing a section of code, you could take a couple of runs at it if the logic or the language involved are unfamiliar.  The main difference between this and Breakable Toys (maybe this is Partially-Breakable Toys?  Scratchable Toys?) is that you still need to deliver a working end-product in reasonable time.  The toy can’t be the whole assignment or program, but maybe it can be part of it.  This approach, however, doesn’t have the longevity implied by the authors.

I really appreciate that this pattern is in the book.  Playing with problems, writing code, failing, and then finding ways to do what I want to do is how I learn things.  It’s also a big part of what I love about software development.  Reading about something like the way I prefer to learn in a book like this makes me feel validated about my learning methods, like I’m on the right track.

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

Practice, Practice, Practice

Problem

The performance of your daily programming activities does not give you room to learn by making mistakes. It’s as if you’re always on stage.

Solution

The book suggests taking the time to practice your craft somewhere without interruptions, in an environment where you can feel comfortable making mistakes. Ideally we would use the technique “deliberate practice”, described in K. Anders Ericsson’s research: a mentor would assign you exercise based on their knowledge of your strengths and weaknesses. The mentor would help you evaluate your work and then you would work together to create the next exercise. The mentor would then use the experience of working with other students to create more challenging exercises that add small chunks of abstract knowledge that allows you to hone your strengths and correct weaknesses. Unfortunately we do not live in an ideal world and a lot of our practice on the job. The first example the text mentions is called “code kata”, which is essentially a practice session that some companies are starting to utilize for their teams. The text mentions another pattern, Breakable Toys, the ability to work on a piece of software in a stress free environment where you have control of everything. Finding new challenges and working on problems that are harder than you’re used to can help keep you master your craft.

The pattern had good advice and good information. The idea of having “code katas” seems like a good way to practice your skill and see what other people are working on. I think most developers do this already but the textbook mentioned the Breakable Toys pattern, where you take time to develop software in a stress-free and playful environment. I think it’s important to get periodic feedback, the text mentioned if you aren’t getting periodic feedback you could be developing bad habits. I think it’s important to always practice and find more challenging problems. I think having unique experiences with developing keeps an interest in the subject and avoids created burn out from seeing the same language or pattern you’re used to working with. Reading about this pattern has reminded me to try to always keep an interest in the subject by creating unique challenges,  practicing, and seeking feedback.

The post Practice, Practice, Practice appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Confront Your Ignorance

This week I read the apprenticeship pattern “Confront Your Ignorance”, I chose this one because I thought it would be very relevant to me due to the fact that I am in a new role where many things are new to me. This pattern suggests that you do exactly what the name says, come face to face with the things that you do not know. Thus far, I think that this is one of the most valuable pattern mostly because nowadays, since the industry is constantly changing if you are not actively trying to fill in the gaps in your knowledge you WILL fall behind.

To relate this to my own personal work experience, I am currently trying to fill in the Spring gap in my knowledge. I have in a sense been “lucky” for a while since I have been able to avoid any tasks involving those tools, but my team uses Spring so much that my luck will eventually run out. If I do not confront my ignorance when it comes to Spring, then when I am assigned a task involving it I will harm my team. The other great benefit to this pattern is that, if applied, will make you an invaluable member of your team, nowadays there are so many technologies and components to learn that it is almost impossible to know them all so if you are constantly trying to learn more of them, then your value is constantly increasing.

Though this all sounds good on paper, in the real world I don’t think this pattern is applied because it is intimidating. We are comfortable with what we know, and we don’t like being thrown into a situation where everything is new, never-mind doing that intentionally! Also, I think another major hindrance is time, often times you are working on a major project that is taking up nearly all of your time making it difficult to find the time needed to learn something new. A solution that this pattern provides is starting small, you don’t have to do a very deep dive, you can start with an overview and simply learning the basics and that is what is the most promising for me. By learning the basic of Spring in the spare time that I do have, it will massively decrease my ramp-up time when I have to use it. In conclusion this is a very useful pattern that I will 100% try to apply in my software career.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: The Deep End

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