Category Archives: cs-wsu

Chapter 3: Walking the Long Road

                The chapter starts off with Dave recognizing that the people who are miles ahead of him are on the same road. I really homed in on this. One of my weaknesses is that I can be very critical towards myself. Which is fine until I start comparing myself to others. When my colleagues and I are both presented with a new challenge, it can feel daunting if my classmates are gripping understanding of the intense concepts at quicker rate than I. I was faced with many challenges like so before I read this book. The reason why I didn’t give up, was because I somehow recognized this “Long Road” concept. Rather than thinking I was too far behind, I thought that if I could keep up a pace I would catch up. And eventually I did. Once I caught up, I was able to keep progressing and even pass some of my colleagues. I didn’t recognize this situation the same way the book did. But I had a similar mindset when it came to me continuously pushing forward.

                When the chapter starts breaking into the concept of planning for the “long term” my attention is further grasped. Everyone as a Software Developer is reaching to obtain mastery level understanding. Of course, we are all seeking ways to stop having to research and ask questions. In a perfect world, we could write any software we wanted at the pace of writing an essay. But the world is far from perfect. And as an apprentice, we are far from being at that level of coding. We need to plan our own journey in a way that allows us to continue progressing. And we need to understand that the journey is going to be long. With this recognition, we can begin planning to accomplish whatever we want. No options are closed for us, and we have all the time in the world to catch up to someone who is ahead of us.

                Many basic concepts were stated regarding keeping your passion during the hard times. It is clear, that there is no way around the struggle. It is guaranteed to come with it. And it will be a unique and different experience every time you hit a tall obstacle. If you digest in a route that automatically interests you, these painful moments won’t be so painful. And it will give you a stronger ability to keep pushing through it.  It’s all about carefully setting yourself up on a path to success. We are given the tools to do so. It is up to the programmer to choose which tools they want to spend their lives mastering.

From the blog CS-WSU – Andrew Sychtysz Software Developer by Andrew Sychtysz and used with permission of the author. All other rights reserved by the author.

Learning Pattern Nurture your Passion

The main idea for this pattern is to help one maintain his level of excitement for the field. The author presents warnings of moments where one’s career can be the culprit of discouragement and discontent. He presents a few ways to remediate the situation some by which one could steer their environment to a better place. He doesn’t stop short of recommending leaving a toxic environment if nothing works. The drastic measure is something I would like to avoid because the reason I return to school was the result of it.

This pattern is linked to a lot of other very good patterns, and I am not surprised so many fit well with it. Nurturing one’s passion is the best way to achieve excellence in any filed. Particularly I feel that “Draw your Own Map” is very descriptive of I what plan for myself. I haven’t read this pattern yet, but I think it will be my next one. This support pattern, as explained within “Nurture your Passion”, states that one should know what it wants and pursue it. I like this idea because it removes the self-pity victim mentality away from the equation. This mentality can induce a state of paralysis that is not healthy and hinder you from accomplishing what you want.

My goal after school is to try to find something I am really excited about and maybe even sacrificing pay or title for it. The field of software technology offers the opportunity for a lifelong learning experience. It is so broad, intersects so many fields and industries that it allows for a vast array of choice in which anyone can find something they are passionate about. It also offers the opportunity to trade your convictions and passions for financial gain and we should be careful about that. Some of the things I hear the author talk about I think relate well to what I hear from the gaming industry where is said that they work long stressful hours, and their pay is not up to par to other types of developers. This is a good cautionary tale because most people probably go into this subfield for passion, but passion can become obsession, and that can be very unhealthy.

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

The long Road learning pattern

The long road learning pattern sets its premises on favoring rather than quick results cumulative progress. I believe that working towards a 4-year college degree and the tradeoff that comes with it puts us in that category. We all know that even after the switch from student to paid professional the road doesn’t end. In fact, one of the reasons, I decided to pursue a career in technology was the promise of perpetual learning that the field offers.

The author mentions the constant change in technology and a deeper intrinsic knowledge we developed over time to deal with them. In a sense I believe, he meant that as we acquire experience, we become more sensitive to patterns.  These patterns can help us become more agile in adapting to new tech as well as seeing projections of how they would unfold ahead of their full development. Regardless of how far we get we must not give into the ego and assume things with certainty we can’t guarantee.

We must watch for hardening during the long road. The author doesn’t offer any cautionary warning for this pattern, but I believe it warrants one. In many professions I see how the long road can become a trap to steer you away from self-development. It is extremely easy as you gather knowledge along the road to become a know-it-all. To me there are 2 versions of the know-it-all; the flexible version where one knows a lot but is open to change; the hardened version where one knows a lot and cannot change. I think it has a lot to do with egos, the flexible one is probably perceived by others as knowledgeable but does not care about the title itself so it makes it easier in the long run to reshape knowledge; and the hardened one sees itself as knowledgeable, the title is important so no exterior knowledge that conflicts with its own can be accepted. The hardened one should be avoided; professional life is about social interactions and the hardened one will become isolated or be avoided by others while the flexible one will flourish in a social environment and grow with it.

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

Sprint #1 Retrospective

Regardless of this being our first sprint I believe we were successful at laying out the groundwork and finding each other’s rhythm and perspective. I do think that our team could mature from the information we generated while working on processing what we needed to do. It was interesting to work with gathering the information we needed and not jump into the work itself. At times I as well as others started on tasks that were not planned or even required out of eagerness to see concrete completion. I am a big fan of lists and found it refreshing that the solution to an organized workflow was just to stick with it. Software development is most definitely not work for the anxious and it offers some lively wrestling with the meaning of the word done.

Issues I was Assigned to:

Building a container, was an issue that I assigned myself to because I thought that I could use the experience I had researching it for software architecture as well as other tasks that were closely related. I used the docker files from previous projects of similar scopes to produce development environments suitable to each of the tasks we needed them for.

Contact the I AM team to determine security key format, in this issue we had to gather information on a fellow team’s project. After communicating with them we reiterated what we thought would be the case. Their project required acquiring knowledge on a technology they had no previous experience with, so we thought it would be best to wait until their second sprint when our fellow team would mature the use of this new technology so they could give us an educated use guideline.     

List dev environment tools, this issue was a collaboration by all. It required us to think about certain tools that we like working with and decide whether to set them as default tools to the docker containers in all projects. I personally think this issue was important to have us feel each other’s work antics and to have a hands-on direct collaborative first encounter and produce a list that we were all invited to read, change, discuss and concretize its idea by cross-referencing this issue with the building a container issue.

Clone the API project we constructed last semester into the new API repository, this issue required us to search on previous work and define the scaffold by which we would build our design. APIs are something new to me and I believe to most members of the team, but I think this can also be an advantage because it hasn’t been that long since we looked at it. The sample API is for reference only and should be removed as the actual API is written.

Determine .yaml files for methods; break down into smaller issues, this issue started with a different name and is a good example on how we evolved as work started getting under way. Some of the issues we had with naming issues was that we did not have matured the idea of the project’s purpose enough to be more succinct in setting our actions. Some issues had very broad names which the lack of description rendered their completion troublesome. We decided that a study should be done to break this issue into tasks with a set definition of done. I believe this issue helped us forecasting work for the coming sprint and gave us enough space to now have a much less crowded sprint planning. Another thing I think would have helped would have been having backlog refinement meetings to come up with new issues or being less abstract about the issues we already have.  

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

Unleash your Enthusiasm Learning Pattern

Being a beginner have very few perks so we must utilize them to their utmost extent. The authors make the point of arguing that the new guy has the ability to bring new life into a team that could perhaps have gone stale or that maybe could be improved by such addition. I must confess this learning pattern, or I would better describe it by calling it a resilience building pattern, is a pattern that can help with confidence building and narrowing the aim for purpose. When working with a team in an environment that is new, you don’t only confront with your team’s expectations of what you can do, but also with your own expectations on what you think you should be able to contribute. This ties well with something I think every student struggles with and may carry over to the professional struggles of transition called impostor syndrome.

I have read about impostor syndrome before repeatedly in quorums in which professional developers as well as other professionals talk about it or answer questions about it. I should say that the mere volume in which these topics appear in the wild is a telltale of what should be expected in the first few years of a developer. As a student we easily fall trapped by the illusion of being undeserving, when we grapple with the idea that we have much to learn still. Sometimes it is true that we are unprepared to complete a task or that some of the background knowledge needed for the task was under evaluated in the past and have become a barrier to present issues. But even on the eve of such failures we must not succumb to the temptation of self-assigning ourselves with the impostor role. The imposter would not put in the years of instruction and struggle to become the product of these experiences.

There are little cautionary tales in this pattern as well. This is something I think the authors were very smart to add. In the wild dealing with real world social interaction there can be no one fits all solution. Feeling out group dynamics while applying these tactics is very important. We all have the tendency to grow a little cynical over time so we shouldn’t be judging too harshly an individual or group’s receptivity. If we use just the right mix of the appropriate beginner enthusiasm, we can feel like we belong, or even better, like we have something to add.

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

Sprint 1 Retrospective

My first Sprint Retrospective experience overall truly has been great. Being introduced to a new team environment is different every time, I did not really know what to expect. I had a specific mindset going into this one particularly. I wanted to know, where will I fit in best? I wanted to know the best ways I could assist my team in tackling this project. My teammates made this process very easy. They are intelligent and very ambitious about our project. They were very open about their strong suits and what topics they thought they might not feel as strong in. It allowed us to fill in those gaps and get everyone on the same page. I learn a lot from them.

List of my major contributions to GitLab:

Issue Title: Basics of Keycloak.
Issue Link: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/issues/1

Product Link: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/blob/main/Keycloak%20Introductions.md

Issue Title: Gateway/Ingress. Once requests are past it, are all communications considered secure?

Issue Link: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/general/-/issues/4

Product Link: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/blob/main/API_AccessControl_Authentication_using_Istio_Ingress_Gateway.md

It’s been a very fluid experience so far teamwise most definitely. My individual performance is a different story. I need to make a conscious effort to change the some of the ways I approach things the next Sprint. I created 13 out of 44 issues created. I undercalculated the weight on many of those issues. And instead of continuing to build those issues into smaller ones, I just kept trying to take the heavy issue head on. This put me in many inconclusive rabbit holes. Instead of confusing my teammates with information that is still very new to me, I just kept reading in hopes that something would suddenly click for me and I could produce a confident result. I will link an example of one of the issues I am referring to.

Research: Deploying Keycloak on AWS Kubernetes: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/general/-/issues/5

Another issue I struggled with was the Gateway/Ingress Research Issue I completed. I spent an incredible amount of time creating that research writeup. Which I personally don’t feel confident on it. I am not sure it is tutorial we will even be following. But I think that it is a good start to grasp the concept of what we will be working on. Another one of my struggles was that I didn’t prioritize Keycloak. I completed my Gateway/Ingress research before I attempted to secure my first NodeJS App with Keycloak versus a Standalone version. Which the Standalone version does not promote a strong understanding of Keycloak versus securing a NodeJS app.

Aside from my self criticisms. I feel very confident heading into our next Sprint. I really am finally starting to feel that confidence behind my understanding of these concepts. It was relieving to secure a NodeJS app with Keycloak for the first time. And it was extremely motivating to start coding again. I can really feel all the knowledge I absorbed start to piece together. I am excited to move forward with tutorials to further learn my way around Keycloak. I have been communicating with other groups on how to deploy Keycloak on AWS Kubernetes. I know what I personally need to improve on to further help elevate my teams process during our next Sprint.

From the blog CS@Worcester – Andrew Sychtysz Software Developer by Andrew Sychtysz and used with permission of the author. All other rights reserved by the author.

Sweeping The Floor Learning Pattern

This pattern is very important it tells us how to begin the career switch from student to paid professional. It is a scary moment of unprecedented uncertainty. It helps us see with a clearer image that there are levels of expectation. These expectations are stratified to build a path to success. It also throws cautionary tales of getting comfortable doing the work at the outer layers of what’s expected.

This is very personal because everyone of us graduating will face the reality of a professional environment. I could not say that it will be harsh or easy. What I can say is that the expectations and anxiety that we generate ourselves is harsh. It makes me feel better to think that the professional world in general has a path in which one can climb, even if this path is steep. The great fear is that there is no path, the goal is the space station, and you don’t know how to build a rocket.

Putting my trust on the writers I expect this sweeping the floor pattern a practiced reality in real situations. I don’t believe there are any menial tasks. All tasks must be completed, and I wouldn’t mind if I had to do some of them or even all of them if it’s all I can do. I have used this pattern in my own life differently. When my car brakes I usually fix it myself because I can not afford the extra expense, this is something that I really don’t want to do. It takes time away from my studies, but it also helps me afford it. Some people say why should they pay a mechanic x amount for only an hour of work but the amount it would take a normal person without the tools and environment would much offset whatever savings they think they had. Most of the time I think if I had the money, I would pay double for a professional to do this for me.

You learn the cost of doing something by doing things you wouldn’t necessarily want to do. Sweeping the floor may begin with doing the easy undesirable work but it must progress into doing work you are uncomfortable with. Success in life comes when you accept uncertainty and never get too cozy as to be paralyzed by extraneous events.      

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

Digg Deeper Learning Pattern

This pattern is a great idea for a beginner such as me. It offers a way to complement the lack of knowledge that comes with the lack of experience. It should be used carefully because of the ease of wanting to just reinforce the skills you are already good at. Knowing a little on a lot of subjects will not help getting things done and knowing a lot in just one subject will get you just as far. The secret as I see it is to have a good toolbox and know how to at least hold each tool. As you need to pick up each of these tools you learn about them more in depth but not too much to hinder your progress. As you shuffle through this toolbox picking up things you need and not obsessing on one tool you build a hierarchy of depth in the knowledge of things you need most. We will handle the same tool more than once and every time we do, we should dig just a little more.

The author presents a more all in version of the dig deeper which I think is the philosophical normalized world idea. It would be nice if we had the luxury of tunnel vision and look for the PhD dissertation of the original design algorithm for every tool we use, but it is also the easiest way to fall into a deadlock. I find that in school it is very hard to get in depth knowledge on every subject as much as I want. Time and time again I see myself compromising and kicking the can down the road, because I do want in-depth knowledge in some subjects, but there are time sensitive co-responsibilities that need immediate attention. Although, as I said earlier, some of these tools that I want to understand better come up again and again over the semesters and I do indeed gain a little more ground on understanding them.

I believe the author is right when he says that we need to learn to dive into ever lower levels of understanding.  By lower I mean from specific to general and by specific, I mean not only the surface high level function you need. The author does throw a little caution which I also mentioned earlier. The risk of becoming what some call a one trick pony.  The balance is really hard to define, and it is very personal. I don’t have my own balance definition yet, but I hope that with time this too will come.

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

Expose your Ignorance Pattern

This learning pattern is very important it exposes us to a very delicate issue. Although the Software Development community is built around everchanging technologies, and we are all shooting at a moving target, the fear of letting others know what you do not know is constantly present. Particularly to me, another analogous fear that I think is related to this learning pattern is the fear of you believing you know something and being shown the opposite. I think that at this level in our learning careers, so close to graduating, this pattern is extremely important. This period of entering the field officially, is the period in which we feel the need to show what we know, coupled with doubts and the lack of experience which rob us the confidence we need.

I hope that once we internalize this pattern regardless of the fear of using it, the field, out in the wild will become gradually more amenable. Perhaps this is why I think that a job with a grounded company with tradition in technology is the best steppingstone to a software developer. Every company small or large today relies on technologies that we must understand. This is the reason I fear the non-tech companies that need tech people. The fear that they will expect the newbie to know it all, or worst, not understand what it really takes to get what they want. I think that this fear will probably gradually disappear maybe at about 2 years in the field.      

To sum up I must say that this pattern served me well in my career as a student and I think it will serve me just as well as a developer. I feel lucky to know that I can relate and count on people that are either having the same problem as me or have surpass it to help me. Reaching out to ask people for help is not only better than staying ignorant but help build confidence in the person whom you asked. Even when you ask someone who does not understand the field, their out of the box answer may guide you to a better understanding. I found that I discovered a lot of the answers I needed just by formulating the question and dissecting it to a non tech aficionado.  

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

Apprenticeship Patterns Chapter 1 and 2-6 introductions Summary

I found interesting that a lot of the practices mentioned in the book are probably day to day patterns that we practice involuntarily. Some patterns are surprisingly new and offer a good way to cope with the workflow of continuous learning. The comparison with medieval ways of artisanship in which the learning takes a practicum meaning and the theoretical is stripped out in favor of physical interaction which is very interesting. I am an enthusiast of the theoretical realm, but I must agree that expertise which people wrongly associate with the illusion of talent only comes with continuous long-term repetitions of small actions on limited theoretical content.     

The book showed me that there is more than one way to navigate through a lifelong learning journey. It is comforting to know that in the Software Development work environment the continuous improvement presented by the authors is not only present but encouraged. The idea of sharing these patterns and improving on them is very open source like. It shows the developer understanding of the need for each other and that there is no downside to help the general improvement of the community.  

The chapter that talks about perpetual learning is enlightening. It absolutely homes in on the greatest obstacle to learning which is distraction.  I agree to it but have my reservations because it also mentions that if you love learning you get over these distractions. What I think is truer is that focus is also the most important skill to be practiced. It involves more than a set of actions and habits; it also involves chemical reactions and sensorial exposure as well as countless parameters out of our control. I confess that as I navigate through my undergrad incursion, I came across supplements to improve focus and used them even if just for placebo effect. I have set controls such as continuous study times, set brakes, meditating 20 minutes for every hour, sleeping a minimum of 8 hours, balancing topics by due date and importance, not consuming alcohol even in social events, ignoring people and everything that is not study. Which is why I have a pile of mail and bills after every semester. But even after all the controls I still must continuously adjust and adapt to optimize focus. Without focus there can be no real learning.        

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