Author Archives: Pawel Stypulkowski

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.

Breakable Toys

The pattern form “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye that I have chosen for this week is called “Breakable Toys”. It talks about being on a job that does not allow mistakes or failure, but without falling there is not room to learn or grow. How is one supposed to learn and fill in their gaps in knowledge if something needs to be right the first time. Simple solution is to create a “simple toys” on your own and play with them, fail with them and break them in order to fix them and learn from those mistakes, that will be unrelated to the project but an opportunity to learn and grow for it.

This pattern is something that I have used myself many times, what helped me a lot in this regard is also fact that I was going to school and was learning or “playing” with new programs and ideas all the time. Many people or managers, in my opinion do not understand how much learning or failing needs to happen before a good program will take shape, many times even just a working software, not perfect or good, is a major learning task for employees. To be able to do so safely and without repercussions from a work environment is a key in staying ahead in your career.

In my own experience I have done similar things described in this pattern and have even done so while at work, but only in thanks to a very understanding leader and mentor who was not afraid to let me take some time to familiarize myself with something new we were going to do. I am aware that not everybody has the same luck as I did and that is where this pattern is very much right. All people in our field should be able to play with the new software, new language and be able to just break it, to be able to later fix it and learn from the mistakes made, the only way that I can see the absolutely everybody can do it is on our own time, at home. It might not be something we will be paid for but it will let us develop decent skills and be familiar enough with a given concept to pass in the environment that does not allow failure.

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.

Concrete Skills

The pattern form “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye that I have chosen for this week is called “Concrete Skills”. It talks about being a “newbie” in a workforce and looking for opportunities in the advanced teams that exists in computer science field. The pattern describes how not many companies and employers are willing to hire somebody fresh without years of experience and already developed skills. It also tell us how to try and convince the potential employer to “take a leap of faith” and higher you or somebody else by making sure that you have a set of skills that can be used to help the team out even if it is just manual work or automation of simpler tasks.

I believe that this pattern is somewhat correct but not completely. What I agree is that having the “concrete skills” will definitely help with finding a job and being better at it, but the flip side of that is that it all depends on what employer is looking for, certain skill will be very specialized and not everybody needs those, or they are obsolete to begin with and some new way of going about a task is more popular now. The pattern describes how those “filler” skills might just be enough to get people through the HR or certain managers and allow next step in the hiring process.

This pattern made me think about how the current workforce is a lot of smoke and screens to make people either think that a company X is more advanced than they actually are or how potential employees need to fill in the resume in order to just somewhat be considered for a position no matter that most of those supposed skills will never be used. All this is infuriating. From my personal experience I know that a lot of companies, half the time, don’t know what is posted for the job requirements or nobody on the team even has those skills and they are “required” simply because some other A-list company had them on their job posting.

Overall, in my opinion this is a very mixed feeling pattern for me. Yes, it is good to have a wide pallet of skills to help with the job search but at the same time a lot of the same jobs do not actually use those skills at all and they just become a filler to make the potential employee search easier.

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 2 Retrospective

This past week was the end of our second Sprint for the Capstone class. It all went well, and I think we completed all out tasks successfully. I will write about my tasks and my overall impressions of this Sprint.

Tasks:                                                                                                                                                                

  1. Issue #25: Connection between Database and Rest API Backend
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/25
    Creating a Rest API backend that talks to the Mongo Database with specified queries and retrieves total weight.
  2. Issue #2: Fix CI Setup
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/CheckoutService/-/issues/2
    As the name implies, fixing the CI/CD setup for GitLab pipelines, after copying from master it no longer worked.

What worked well?
This time around the Sprint and our lives in general were drastically changed due to ongoing COVID-19 outbreak and the implementations of federal emergency and stay at home orders. It all began normally we started this Sprint like we have before with everyone working on our tasks and meeting once a week for a group session to tackle the problems together. After the outbreak what worked well was very little. In my case finding time and just organizing anything due to my work switching to a “work from home” situation was extremely challenging. One thing that might be working in our favor is that due to most people not working we can call in an online meeting a lot easier since we are all at home. There will still be some time constraints of course.

What didn’t work well?

The social distancing order is a little challenging to work as a small group like this on a project. Before we were able to meet and collectively challenge some of the problems we were having. Scheduling some of the meetings got easier but the actual work time got drastically reduced and in my case just being able to perform some tasks is rather challenging.

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 and Corona Virus outbreak made that so much more challenging than before. We also should work on our problem descriptions, we need to be more specific and detail oriented, in my opinion we have only used more generic wording. We probably should have broken the bigger tasks into smaller sub-tasks to make them more approachable as a whole.

What changes could be made to improve as an individual?

During this sprint I have again felt that I have not contributed enough to the team, the tasks I have performed were not as hard as they seemed originally, only working on the API connection to the database took a significant time. As an individual I also think that I should work on my free time management and schedule conflicts. I work full time and often I have only certain time frames to work on school projects and homework and with the temporary adjustments to our living conditions that has gotten even worse. This time will be a real test for all of us, test of our self-control and patience.

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 1 Retrospective

This past week was the end of our first Sprint for the Capstone class. It all went well, and I think we completed all out tasks successfully. I will write about my tasks and my overall impressions of this Sprint.

Tasks:                                                                                                                                                                

  1. Issue #21: Define Database Schema
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/issues/21#
    Creating a small UML diagram of possible database schema, open for further revisions later.
  2. Issue #6: Create UML Diagram for REST API Structure
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/issues/6
    As the name implies, creating a UML diagram for REST API structure for our project, open for further revisions later.
  3. Setup production Database
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/issues/11
    After deciding what our team will use as a database for the project we have made some preparations to make sure it is working correctly and we can do necessary operations with it.

What worked well?
In my opinion pretty much everything our group (BZPJ’s) planned on doing ended up fine and on time, when it comes to my tasks they were somewhat easy for now and not necessarily required a lot of time, in my opinion being able to use some of the knowledge from previously taken classes was a very good example that what we learn is useful in the “field” application. What I am also very grateful and happy about is the way our team was able to find time and place to meet regularly to be able to work on these tasks. With my busy schedule it was always challenging to have a team able to work within my time constraints.

What didn’t work well?

Comments. I think as a team we were not quite there yet when it came to work on this big group project that others will take over eventually. I also believe that some of my contributions to the team could be more, after this Sprint I’m not sure I have done enough.

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. We also should work on our problem descriptions, we need to be more specific and detail oriented, in my opinion we have only used more generic wording.

What changes could be made to improve as an individual?

During this sprint I have felt that I have not contributed enough to the team, what I had to make were some diagrams, only the work on the database was somewhat challenging, even though most of it was handled by my teammate and I only helped with some of the parts. As an individual I also think that I should work on my free time management and schedule conflicts. I work full time and often I have only certain time frames to work on school projects and homework, but to be honest I also waste some of that time. Another thing I should probably work on more is to do more research on topics assigned to me, not only finding enough to get my portion completed. As my previous post said I need to Dig Deeper.

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.

Dig Deeper

This pattern form “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye is probably the scariest thing I read in this book so far. It describes how in order to be a good “craftsman” in software development one should be able to dig deeper into the knowledge about the problems they are working on. It shows you how one must try and be able to find more information about things in order not to be just a person who puts some code together and is what the book calls “programming by coincidence”.

This is a very interesting and intriguing pattern in my opinion but at the same time makes me feel as one of the people who just happened to code but do not know what they are talking about. It might just be my own feeling at the moment but nevertheless it is there. In my professional work I have always worked on very custom project and not very often things were reused which lead, at least in my case, to constantly only gaining surface knowledge of certain subjects. It is not easy to admit that I am probably not as knowledgeable as some of my colleagues, but I think this pattern is showing me how I might be able to fix this problem.

I am very much in agreement with what this pattern is describing, and in my own opinion a living example, even though I am constantly reading some new materials about my chosen field I still feel it is not enough and I should dig deeper to be able to stand out . Knowledge about a subject is always precious but just like the pattern describes if it is not deep enough it will not be really useful, and it might become a problem later on. One thing I definitely understand from this pattern and I like to think that I’m doing right is reading of the documentation and specifications, even though it might not be enough I think that this at least is somewhat redeeming for me.

This pattern is also somewhat problematic for reasons that sometimes getting more knowledge about subject is just plain boring and monotone, I know it sounds as an excuse, but I never heard about anybody excited to read some standards and specifications. Yes, it has to be done and it should be, but it is definitely not enjoyable.

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.

Expose Your Ignorance

Just like the title says this week I have read the pattern “Expose Your Ignorance” from “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This pattern describes how any aspiring developer should put aside their ego and be able to tell other about not knowing something and ask questions. It is about being able to admit that we do not know something and to start learning even if it means showing others your “ignorance”.

As always with this book and its chapters this hits close to home when it come to me and my work experience, as well as school in that matter. I found it interesting because it really shows me that it is not only me who can struggle with this particular pattern. My boss always tells me and my teammates during any meeting or code review: “you owe me at least two questions”, and this is the part that is described well in this chapter as well. The author says: “The most obvious way to expose your ignorance is to ask questions.”. I agree wholeheartedly with this statement, we have to be able to ask questions even if it shows our ignorance on the subject, but the sooner something like that is out there the sooner we can work and fixing the problem as well as better working with the team, since they will know that we might need some help.

The only part of this pattern that I do not agree with all the way is the same one I just mentioned. In my opinion there is a place and time to ask questions to expose one’s ignorance, but there are also times when holding them back until later is the right decision. One such time is when working directly with a customer, a particularly tough or difficult one. Or when having a meeting with a lot of higher ups at a company and your development team. Question on the subject are usually good but ignorant questions can have some unforeseen consequences in these situations. Overall, I agree with this pattern and the idea about having a list of things you do not understand and to update it periodically is in my opinion a very good idea.

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.

Reading List

For this week “Apprenticeship Pattern” I have chosen Reading List. It is a pattern about keeping up a running list or more precisely a priority queue, as the author describes it, of books that are worth reading for amassing more knowledge about a given subject. The queue will change or be reorganized many times over the course of it, but it is worth having. Another useful advice in the pattern is to ask your mentors or people more knowledgeable bout a subject about which books they recommend reading.

What I like about this pattern is simply something that I have already started doing, it is interesting to me to find out that it is not only me who had this idea. I think this will be a very useful tool in anybody’s arsenal in their professional career. What I have done is essentially described in the pattern itself. I have talked to some of my colleagues at work as well as my bosses and figured out what books they recommend, after that I have done some research and based on other reviews of the mentioned books I have made my own list.

Not all the books in my opinion need to be about your work or career, if they are helpful in some way then they are worth reading. Any knowledge is good, the best knowledge of course is the one that helps us grow as a person.

One useful thing that I have learned from this pattern is to put my past books on my list and keep them there even after I have read them. This is to help me and other to reflect on them later and to better remember the contents and lessons acquired from the book. The pattern also states that better understanding of the subject at hand will help people refine and organize the list better. I agree with that and like the author states mentors are always a good source of said understanding and any good mentor will always steer you in the right direction. I’m feeling lucky because I have been able to find such a person. Currently due to my student status my reading has stalled to a degree, but I do plan to get back to it as soon as possible.

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.