Find Mentors

For this week “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye I have chosen “Find Mentors”. It talks about finding someone to help you along the journey as a Software Developer, a mentor – a person who can teach or show you the ropes of the profession. The general state of the computer science field is young and therefore there is not many masters present, especially those that can teach us everything so one might have a lot of masters, each for a different part of the field they want to pursue. Important thing is to remember that we are all still learning about this and being a mentor does not mean they know everything.

This particular pattern is something I was a truly fortunate to have gone through in my own career. In my years of work, I have found a person who was willing to help me learn the ropes of the Motion Control field and be patient with me and my constant questions and mistakes. He is an exceptionally good teacher who will always take his time to explain concepts and work required to get things done. What I have found rather useful (and I will probably use this method in the future) is that this pattern does give us some way of potentially finding a mentor or many. It also somewhat prepares us for the possible rejection form potential mentor as unlikely it is and how the benefits can be huge.

What I have found particularly useful in this Pattern is how it tells us to “be tenacious about finding mentors to guide you”. After my own experience with this I think this is a very good advice, I for one know for sure I would not be where I am today in terms of my skills and understanding of the subject if it wasn’t for the help of my mentor. Everyone should find such a person to help them develop their skills, unless one is a genius and does not need any help, it is impossible to know things about a field without someone already experienced helping along the way. I think this cannot be stressed enough: FIND MENTORS!

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Use Your Title

For this week “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye I have chosen “Use Your Title”. It is a pattern, like the title says, about job titles and their meaning and possible impact at your work and professional life. Titles at work are very often paid attention more than they should be or the opposite, not enough. The can very misleading and make someone look more impressive than they are or the again the opposite, they can make someone experienced and impressive look like they are not worth your time. Directly quoting the book: “When you introduce yourself in a professional setting, you feel as if you have to apologize or explain away the difference between your skill level and your job description.”

This pattern is something I have been struggling with most of my professional career. I always have been stuck with titles that are so much less then what I am actually doing or capable of, all simply because I did not have a college degree, even though my experience and track record were exemplary. Again, the book states this perfectly: “the frustration that comes from a lack of recognition should remind you that our industry has a problem.” This pattern is a great showing of how something trivial as a title at work can mean so little in certain circles or it can mean everything on others. I could see this at my work a lot where I was skipped over in an email when my coworkers who had a slightly different title were not. I am sure that this is happening everywhere in the current culture of computer science and software development.

At the same time, I know and so should others that title doesn’t mean much and all that matters are skills and a fair compensation for performed services but very often it is hard to look past the title one has. It can be demanding or just scary to have a title that sounds more impressive than the work one is performing and constantly living with others expecting more from you than you are supposed to do. Titles are the most important useless things one will need at work in my opinion. Problem is many people put more attention on those then they should and that will not change any time soon.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

This past week was the end of our third and final Sprint for the Capstone class. It all went well, and in the end, we got a deployable project and we have completed most of our tasks successfully. I will write about my tasks and my overall impressions of this Sprint. In this particular sprint most of our teams efforts were focused on getting the Docker containers working together and because of that some of our task will overlap more than other times.

Tasks:                                                                                                                                                                

  1. Issue #35: Create REST API Docker container
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/35
    Just like the title says, creating a working Docker container for the REST API.
  2. Issue #47: Create MongoDb Docker Container
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/47
    Same as before, creating a working container with a MongoDB schema.
  3. Issue #37: Establish communication between All Docker Containers
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/37
    Probably the hardest part of this whole project, getting all the separately working Docker containers to talk to each other.

What worked well?
In my opinion pretty much everything our group (BZPJ’s) planned on doing ended up fine and on time, even though we were cutting it a little bit close this time. When it comes to my tasks some of them were somewhat easy and did not require a lot of time, but some were very time consuming and research heavy as well as required cooperation of the whole team to solve (yes issue 37, I am looking at you). What I am also very grateful and happy about is the way our team was able to find time and “place” to be able to work on these tasks. My busy schedule was as always, a challenge to work on things as a team, but in the end we were able to do it.

What didn’t work well?

As always: comments. Due to the difficulty of this particular sprint our team was meeting online a lot to brain storm things together, we were in constant communication and in my opinion this made us ovewrlook the need for leaving comments on this project for future teams and the work that they will be performing.

What changes could be made to improve as a team?

As I have mentioned before, as a team we should work more on our comments and notes when it comes to working on GitLab and making sure that future participants will be able to trace our decisions and thought process, I believe we are simply not there yet but with some minor adjustments it will be ok. As I have mentioned before I think we should work on our problem descriptions, we need to be more specific and detail oriented as well as maybe splitting the problems into smaller subtasks with less of a weight assigned to them so they can be worked on at a faster pace with the feeling of “getting things done”.

What changes could be made to improve as an individual?

The only thing that I can think of after this Sprint is, I would say, my lack of time to spent on the project compared to my classmates but that is something beyond my control. Overall, I am very satisfied with what I have done this time. I have done things that were useful for the group and the state of our project. OK, maybe as I have said earlier, Comments, I should have made more of those.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

            As you may hope, or expect, this final sprint is where everything really came together, and we were firing on all cylinders. We had consistent communication when needed and otherwise had tasks we could work self-sufficiently on in the meantime. Our task board was positively stuffed with tasks that expressed the minute details of our process, and we managed to complete an incredible amount of their weight considering how many there were. Having spent the first sprint unsure of what tasks actually needed doing, and the second iterating on what we had created, I believe this was the moment all the building blocks fell in place; and it felt, at least personally, that tasks were clear and specific, comprised of all the things I wished to improve from the rough iterative process mentioned in the second sprint.

            I think having finalized our UI design, or at least cemented the layout, allowed for easier improvement of said design. In many ways, having a finalized user flow in place made so that much of the non-style code could be refactored to store and manage information more effectively. For instance, as mentioned in the note above, I began with calling REST API to log transactions in the weight entry component where the necessary information would end up: student ID and weight. After refactoring, I broke both the storage and management of guests into a service which could be more easily accessed by any component and centralized any API calls made using guest information. This worked perfectly except for a single instance, where I needed this service to call another component. Services can be easily imported by components but sending information to a specific component from a service is more complicated. As I understand, the code I used subscribes the component I needed to speak to, to the service, which then can send a signal to that component, which in turn calls one of that component’s methods.

            Regarding what did not work, it is a combination of both personal and group strategy. While we each could work effectively alone on our own independent portions, it meant that we all became intimately familiar with only one or two aspects of the project. This has especially caused problems most recently with trying to move our respective portions into Docker, as I was the only one who knew next to nothing about Docker. Therefore, I could not help my group members work on any problems my front end code may have caused. I see not keeping up with my group member’s Docker progress as a personal failing. Now both in this class and in the workforce to come, I am wishing I had this knowledge of such a powerful and seemingly common framework. Otherwise, I am very proud of the work my group members did and think given some more cross-cutting training we would be that much more of an effective team. Especially given everything that has been going on we have managed to put together a site that is nearly ready to roll out. (With the caveat, of course, that it may not be absolutely perfect but can perform all the tasks necessary).

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Expand Your Bandwidth

The Apprenticeship Pattern Expand Your Bandwidth is something that should be learned at the beginning of your career, even in schooling. This pattern is about learning the ability to learn a large amount of information about more than one subject at the same time. You must be able to retain the vast income of knowledge, you won’t have to do it for very long, but it can be overwhelming. Overcoming the overwhelming feeling and successfully learning much more information than you’re used to is the crux of this Apprenticeship Pattern. There comes a time when your focus must spread from your everyday work and onto new information.

This pattern coincides with that of Draw Your Own Map quite a bit. These two patterns are all about taking your future into your own hands. Expanding your bandwidth is a skill you have to learn to help your path become clear. If you want your map to expand then your knowledge too must expand. Sometimes when you need to take in a vast amount of information at one time it can be stressful and confusing. However, once you have retained this new information it unlocks new opportunities and new paths to be taken.

In my personal school experience I feel this skill was necessary at times, even at the very beginning of my pursuit of a Computer Science degree. I remember the knowledge jump between Intro to Programming and Data Structures was enormous, but not only larger, it moved faster too. My fellow students and I had to learn new information constantly all while applying our already new knowledge. It was that way for about the first third of the semester. We had such vast amounts of information coming in, but after that first third of the semester we had already learned most of what we would be doing. There was still more information to come of course, but it was more or less experimenting in more detail with things we had already done. We expanded our bandwidth at the beginning so that the rest of the semester we were prepared for a variety of projects. It was as if the flower had bloomed for us finally and our paths were much more open.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

How to Learn about New Tools

The second Apprenticeship Patterns pattern I looked at today is “Confront Your Ignorance”.

This pattern explains how to improve your knowledge in areas you aren’t as experienced in. The pattern also provides possible drawbacks of focusing too much on self-improvement.

The “Context” and the “Problem” sections of this pattern are relatable to me currently. I can clearly see that I have a problem with my knowledge of Angular and I need to learn more about this in order to develop frontend applications. I do somewhat disagree with the part of the problem area that says I “do not know how to begin”. I think at this point I have a decent idea of how to learn about new tools. Although maybe it is correct as I have still yet to feel like I have a good understanding of Angular after trying to learn more about it.

I do like and use both of the suggested methods for learning about new tools. Usually I like to read documentation and introduction guides on a tool’s website, but I also like to follow along with example projects. Additionally, I have found that watching a video tutorial series (mainly on YouTube) on a particular topic can help a lot with learning about something new. This is how I learned about a lot of the backend tools my team used this semester and I am especially a fan of the YouTube channel one of my teammates found. This suggestion is something that I feel should be included in this pattern as I have found this method to be one of the most valuable ways of learning about new tools, especially if there isn’t much documentation for it.

If I had to pick only one thing to learn more about it would be Angular. This is something I have consistently been trying to learn about for a while, ever since I first learned about it, and it has been something I’ve tried to improve on this semester but I am still not satisfied with my knowledge with this tool.

I did find the provided downsides to be the more intriguing part of this pattern as these are points I wouldn’t have thought to be in a pattern about how to learn new skills, but they do make sense after reading about them.

I do think that this pattern provides some good general information about learning about new topics, but for me I wish it was a bit more specific as I find that I was familiar with most of the information provided in this pattern about learning about new tools.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

The Value of Asking Questions

This morning’s pattern in Apprenticeship Patterns is “Expose Your Ignorance”.

This pattern helps explain to early developers how to get over their initial lack of knowledge in the field by asking questions and seeking out knowledge and the importance of doing this instead of pretending to know everything.

To me this pattern and especially the “Problem” area feels very relatable right now with where I am this semester, especially with another attempt at learning how Angular works.

I do find that this pattern provides me with some valuable reassurance, and it is more comforting to know that this problem happens to other people.

Lately with my work this semester I have apparently been following the advice this pattern gives and trying to ask others in my group for help when I don’t understand something that I have been trying to do. This is important in our group, especially as different team members in our group have their own areas of knowledge from what they’ve learned this semester. Reflecting back on this more I wish that I asked more questions (especially during meetings) and focused more about how something works instead of just the solution as this would have had a far greater benefit in increasing my knowledge.

I agree with the idea that answering questions helps to understand the problem better. I can think of many times this semester where I either asked questions that helped find errors in something or when answering someone else’s question made me think more about it.

I do like the idea that the “Action” section presents, although it does feel somewhat exposing to visibly have on display things I don’t know. I am trying to think of a good digital place to put something like this, perhaps on my GitLab account. As I’ve probably alluded to in my posts so far, I think my top items (although this isn’t five items as the pattern suggest, these are things that are particularly holding me back) with my current work would currently be: Angular (and specifically forms), HTML, and Jasmine (this is especially a rather new one for me). I would like to refine this list some more and pick more specific topics to work on learning in each one of these broader items.

This pattern provides helpful knowledge and helps explain the importance of learning from others. Again, as I said before in my previous post, I wish I read this pattern earlier as the ideas presented in this pattern would have improved my learning this semester.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Reflection on Independent Study

With this year’s independent study presentation complete and the semester’s coming to a close, I have a project that is working. Naturally, there’s a lot more I wish I could have done. But I’ve learned a lot not only about individual technologies, but also how to plan a large project and schedule tasks.

Setting deadlines for certain portions of the project was helpful, but I did deviate from the schedule a bit in order to get more-important parts done, or prerequisite issues that were unexpectedly necessary. Some flexibility is certainly required when entering into a project without a working knowledge of the technologies at hand.

I love throwing myself into things that I know will be difficult, and that’s kind of what I was going for in this project. Turning big problems into smaller, manageable problems is one of the main reasons I enjoy software. But it’s a balancing act, because I was essentially throwing myself into 3 big problems: Learn signal processing; learn machine learning; implement a mobile application. There were a few weeks of struggling with new technologies for more hours than I had planned, and knowing that I was barely scratching the surface of only one of these big problems caused considerable stress. At times, I thought there would be no way I could get a single portion done, let alone all three.

But somehow each week I got over a new learning hump just in time to implement my goal for the week, while concurrently doing the same for my capstone sprints. Deadlines are a beautiful thing. I did a speech in my public speaking class in my first year that discussed Parkinson’s law, which says work will expand to fill the time available for its completion. This idea has followed me ever since and has proven to be true.

In preparing my presentation in the last couple of weeks, I found a couple of issues and had a couple realizations on how I could do things differently (read: better). I added some of them as I went along, and I was tempted to completely revamp the machine learning model before my presentation. Instead of the inevitable all-nighter it would have required, I managed to restrain myself and save it for the future. But this shows the importance of presenting your work as you go along, as one does in a Scrum work environment. Writing about and reflecting on issues and solutions in a simple way forced me to re-conceptualize things, both in my blog posts as I went through the semester, and in my final presentation.

While I had guidance from my advisor on how to approach and complete the project, planning and implementation was on me. There were definitely pros compared to my capstone’s team project. For example, I knew every change that was made and I had to understand all the working parts. Getting things done was mostly efficient because I only had to coordinate my own tasks. However, in my capstone I was able to bounce ideas off of team members who could provide a different perspective when we both understood the language or framework at hand. Delegating tasks also made it easier to completely understand the subtle details that allows for efficient use of a technology. Both of these experiences taught me transferable skills which I’ll be able to use in the future in solo and team projects.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

Concrete Skills

I have no professional developer experience yet, and that can make starting a career difficult. To make up for the lack of experience, I will need to procure and maintain some concrete skills. Concrete skills demonstrate the ability to utilize knowledge. The apprentice pattern “Concrete Skills” from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, by Dave Hoover and Adewale Oshineye, addresses the usefulness of concrete skills when seeking a career.

“If we hire you today, what can you do on Monday morning that will benefit us?”

This question from the pattern makes clear what a concrete skill is. Businesses are not looking for someone with just knowledge, they are looking for someone who can do the job. It is important to practice some concrete skills with current technologies and frameworks so I can hit the ground running when I start a job. The pattern lists several examples of skills to explore: basic web design, JavaScript, open source frameworks, build files, and a language’s standard libraries.

The pattern suggests collecting CVs, Curriculum Vitae, for respected developers to find out what kind of skills to practice. The CVs will contain the concrete skills of those developers. With this knowledge, I would only need to choose which skills that would be immediately useful for my desired career path. The pattern then suggests creating toy implementations of the chosen skills for practice, which then can be used as examples in interviews.

 “Concrete Skills” advises going through one’s own CV and find all the discrete skills. These skills are the only information many hiring managers will look at, according to “Concrete Skills.” This makes having demonstrable skills a necessity when looking for a job.

The pattern, “Concrete Skills,” seems like common sense, but I think it is an important point that needs to be stated. It is easy to lose yourself in the studying of development techniques and forget to polish the skills you already possess. The lesson this pattern is trying to teach is summed up nicely by a quote from Pete McBreen’s Software Craftmanship: The New Imperative:

“Having knowledge is not the same as having the skill and practical ability to apply that knowledge to create software applications. This is where craftsmanship comes in.”

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

LibreFoodPantry Sprint 3 Retrospective: All Things Come to an End

Here is what I worked on during Sprint 3:

Sprint reflection:

In my personal opinion, this sprint was truly when my team and I started to get into the flow of collaboration. For this sprint, rather than each working on a separate service, such as the API or front-end we all collaborated on a single front-end. What I noticed with this was we had a lot more discussion and it really felt that we were working together towards the goal of getting all of our issues we started the sprint with done. Unfortunately, this was the last sprint of the semester, but it was good to feel that we were all working collaboratively and using discord and GitLab to communicate any issues and roadblocks that were stopping us from achieving. As I talked about in my last retrospective blog, the transition to fully remote was a pretty tough one since we are a relatively new team and haven’t really had the time to form the communicative skills that a seasoned team would have. It felt at times like the fully remote nature felt made it more difficult than it was previously to reach out for help while working. Maybe it was the quickly approaching deadline that made the difference, but I think we all worked really well together on this last sprint. All members of the team used discord messaging extensively and we had our fair share of discord calls to talk about implementation and problems. As for things that could be improved, as there always will be, I felt like work wasn’t being pushed to GitLab as frequently as it should have been. This made helping with implementation a pretty slow process. There is really nothing that we can do to help collaborate if we don’t have that code up on GitLab. I also feel like we still had the issue of keeping way too many things in the needs review column of our Kanban board. This also slowed down implementation greatly because there were many times where I couldn’t start working on another component until a feature was merged and sometimes it would take days for that to happen. In the end, we implemented a lot more than I originally thought we would have and we did it as a team. We even got to working with Docker on the Dawn of the final day and while it was a scramble I learned a lot about containerization and Docker implementation.

Going Forward:

It did take my team a fair amount of time to gel together and feel comfortable collaborating, but I feel like we pulled through in the end. This project has been a huge learning experience. Not only did I learn a ton about how developing on an Agile team feels, but I also got a feel for being a Scrum master. I know that this experience is one that I will look back to throughout my software engineering career. There were failures and frustration, but it was extremely informative to be part of this project from the idea phase all the way through to the implementation, albeit not a finished implementation. Having the experience of transitioning to working fully remote is an experience that has already helped me in my professional career. If any of my team members read this, thank you guys for sticking it out with me and I know you will all succeed in life.

From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.