Category Archives: Week-14

Expose Your Ignorance

The apprenticeship pattern Expose Your Ignorance is like climbing a mountain taller than you may have climbed before. It seems so difficult and intimidating but once you are at the top, you realize how the hard part is over and it will now be easier moving forward. You may feel great pressure if your team has a task and they all seem to understand while you have some questions or are unfamiliar with the material. It seems as though exposing to them your ignorance will ruin their confidence in you or hurt your pride. However, exposing your ignorance does just the opposite! Your team members will see that your ability to learn is your strong suit and their confidence in you will be even greater. You will not be a master in one specific field but a master at obtaining skill and knowledge in any field you are presented with.

In my own experience, exposing your ignorance can be a great ice breaker at the beginning of a project. Just because your whole team may seem more knowledgeable than you on the material does not mean that they don’t need a refresher or are just putting on an act of confidence before they do research on their own to catch up. The most direct and fastest route to the knowledge is to ask your team member who has immediate knowledge. Perhaps the situation is vice versa and you have more knowledge than your team, asking revealing questions even if they are just for review can open the conversation for people to expose their ignorance and then learn the fastest way possible. It can be hard to swallow pride and fear judgment but if you remember that the most important thing is the project then your own pride becomes secondary. It is also better to have someone ask the questions they need than to put on an act and slow things down by learning as they go when the time could have been taken to spread knowledge amongst the whole team simultaneously. Now while you still may have to learn as you go after having exposed your ignorance, at least your team is aware and can now take proper steps to aid you until you have obtained the necessary knowledge.

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

Jumping Off the Deep End

The pattern “The Deep End” is all about taking on challenges and hard tasks to further your progress in learning and avoid plateauing. The pattern also talks about how it will help build your portfolio and give you more experience in different areas and fields of computer science. There is also a risk for this pattern which is that you may feel like you are drowning when you are unable to complete or work on the task because it is too difficult. According to the pattern, you should write down the biggest project you worked on was and the biggest code base you have made and look for projects of similar dimensions and attempt to work on those as well. The best way to grow is to challenge yourself and take on bigger and bigger tasks to both show your progress and what you can achieve. I relate to this pattern since I believe that its the best way to grow and learn when it comes to everything else so it makes sense that it applies here as well. There will always be a ability to fail, but it takes a strong person to look at that possibility and still push forward. I feel that this pattern made me think of how I will be doing a fair amount of work outside of any job that I employed to do because I will want to and need to learn and experience more to grow.
I feel that this pattern is helpful and useful information for anyone in any profession since it can be applied in different ways. The pattern talks about keeping your head above water, but I feel that at times you need to really go down under water to get stronger. I think it’s important to be reasonable with what you can handle, but I don’t think that means you need to be afraid of being really challenged by a task or project that pushes you “under water”. By taking calculated risks and challenges, we can achieve greater heights of what we are able to do. I feel like this pattern pushed me to want to take on greater challenges and work on larger projects to build up my portfolio and learn new things that I will be able to use in future professions/projects.

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.

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.

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.

Capstone Sprint 3 Retrospective

The third sprint in my capstone was a race to presenting a working project. This sprint brought new difficulties in coordinating the team and getting work done in a logical order. The issue wasn’t our team work, but rather trying to work around the pressure of getting the work done. Many issues took longer to resolve than expected, meaning we had to put a pause on some issues to help each other get prerequisite issues done.

My contributions

Set up CI for Angular to automate testing and prevent failed pipeline merges

Create Angular Service to update backend

Create Docker container for Spring Boot

Create Docker container for Angular

Establish communication between all 3 docker containers (MongoDB included)

Retrospective

I was really happy this sprint with how our team dropped what they were doing for a team meeting. We all had snags with almost ALL of our issues, and the order in which we had planned to do things was not possible. For example, while setting up the CI, I decided to explore Docker a bit more in detail so we could potentially use the same Docker image for the CI as we used in our project. This meant that we as a team had to focus on Docker sooner than expected.

At the same time, there were some problems while working on different issues synchronously. The biggest problem came from a couple incidents of copying and pasting code from other branches to get it to work in their code, instead of waiting for the code to be merged. If someone else’s issue is blocking you from working, the team should try to resolve the issue as soon as possible first, then get the updated master branch. While copy+paste might seem easier in the short term, it has a potential to cause issues as people try to merge their own requests. For example, code was copied from one of my branches because a feature was required for another issue. These changes were then merged from a different feature branch. My merge request was never approved because the changes were already on master. When it came time to merge one of my requests, it looked like I had made no changes compared to master, because my changes had erroneously already been committed in another branch. It was especially confusing, since change had been made to my original code since then.

This could have been solved if I had blocked other issues from being merged before my issue was merged, which is a feature of GitLab. However, there were also a couple cases where certain features stopped working because code was merged to master without consulting other team members while resolving conflicts. This led to some of the work from my issues being completely erased. Luckily it was easy to add back in thanks to version control, but the extra effort could have easily been prevented. Checking the git diff more carefully while merging would help in this effort.

Branch names were also confusing in a couple cases. “Working_branch” followed by initials is not a useful name, although I understand wanting to signal to your teammates that it is your branch. Appending initials to a name describing the feature would be more useful for everyone. Even better, GitLab has options to prevent modification to a certain branch except for merge requests. You can name the branch after a feature, anyone can help you, and then you can accept changes only if you want. This makes it easier to find a branch when helping your team members with issues.

These problems did teach us about features in GitLab we were missing out on. Our team could improve by following the GitLab workflow and maintaining consistent software development processes. Deviating from this workflow hurts productivity because other members have a certain expectation on how things are being done, and for example, shouldn’t have to check to make sure a past bug fix is still on the master branch.

Despite these issues we got a lot of work done, even though it came down to finishing the night before because of all of our snags. I had a great time with this team and although we’ll no longer be working on this project on a sprint team, I’d like to continue working with any of them who will continue to contribute to this project. We’ve all learned a lot about GitLab and the technologies we’ve used and have adapted well to the new workflow.

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.

Dig Deeper

We live in a world where various complicated software projects have different time frames and require a variety of tools to complete tasks. Employers are also reluctant to employ so many professionals to fill all their positions. The problem is that developers learn only what they need to get the job done, and they are not thinking of tomorrow. Sometimes they have to make decisions without even understanding what the issue is and copy some toy examples that would help them solve the issue. In a short time, they become part of the new technology, but they don’t know anything else other than that part of the technology. Moreover, they tend to have trouble keeping the code in good shape, even though the instructions they use cut corners and simplify complicated things in particular. It means that they are constantly wallowing in a perfect way of studying a thousand instruments or something that needs deep knowledge. People sometimes criticize the developers for getting a poor CV, but they forget that developers can learn so little unless they get put under serious tests.

This pattern made me realize that I need to dig deeper into tools, technologies, and techniques. Resources that developers need to be familiar with include debuggers that allow them to see wire-level debuggers that display network traffic and readability. When you can read all descriptions and coding, nothing can hold the process of learning and continuing to work. One method of using this prototype is to collect knowledge from primary sources. Many fake posts can lead you to the wrong path. Do not just take the opinion of someone, figure out who came up with the ideas first, and understand the problems they were trying to solve. Furthermore, as an apprentice, you shouldn’t look for code to copy but you should be focusing on gaining new knowledge from reading different tutorials. Gaining deep knowledge is hard, but by applying this pattern regularly, you will be one of the people who know exactly how everything works. It is better to succeed than to fail…

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