Author Archives: jeffersonbourguignoncoutinho

Sprint 3 Retrospective

Issues Evidence

Issue:: HTTP Get Range of Questionnaire Submissions

This issue was added to this sprint to complement the client specification. The main idea was to create an endpoint to query the questionnaire data set and return values within a specific date range.

Issue:: API: determine input fields for Guest info and QS collection

This issue is vague and shows that we have much to improve on naming issues. I interpreted this as looking at the API calls and parameters to make sure they all meet client specification.

Issue:: testing API for getRange

This was done in multiple levels. At the backend with dummy values and a working clone of the app designed to emulate the android calls.

·  Reflection on what worked well

This sprint started well we had a better understanding of the agile workflow. Communication was key to many of the problems we had to tackle. We meet a few times online outside classroom to clarify definition on what needed to be worked on. We shared our work during these sessions and worked out the logic for a few methods. The attendance was important, and participation help us be successful this sprint. Not everything was as smooth as it could have been, but we did finish the sprint with working elements of this current sprint goals. One very important element that was added to this sprint was the mock app feature which allowed for integration testing. This helps because it shows the API will work not only in a web page or web app but also in an android environment without any unintended consequences. I can attest to integration problems because in my robotics project different components networking with each other would behave strangely in ways we didn’t expect or understand. So, checking communication was made successfully with no hick ups is a big plus.      

·  Reflection on what didn’t work well

We still struggle to give tasks meaningful names that everyone understood. At the end of the sprint finals and projects kept most of us busy. Not the entire group meet during the off-class meetings. We worried so much about having something to show that we perhaps missed out on the opportunity to write better documentation to assist future developers. The API version correction was not completely done because we lacked understanding of the CI environment and other school commitments kept most of us from dedicating a huge amount of time to it.   

·  Reflection on what changes could be made to improve as a team

We could have used more time outside the classroom. We did meet more often and had more meaningful interactions than the previous 2 sprints but there is still a lot of room for improvement there. Communication on what each of us were working on could improve. Sometimes we would not work on things because we thought they were being worked on or started working on things already done. Some of us merged the work to main which is fine, but it caused some conflicts trying to merge the branches back. Some issues were not taken or if taken not assigned causing confusion.

·  Reflection on what changes could be made to improve as an individual

I could have dedicated more of my time understanding the technologies and concepts. Although I gained a great amount of knowledge on JavaScript, I still don’t have the adequate know-how to be proficient in the language. Another thing that I could have done better to help would be to dig deeper in understanding the GitLab CI/CD environment and its automation. This lack of understanding prevented me from accomplishing some goals I wished I had completed this sprint. I wish I had taken less classes this semester and dedicated more of my time to this class. A few times I obsessed over parts of projects where I was stuck and wasted time without meaningful gain. This happened less often than other sprints because I did make note of this bad habit, but breaking the habit was more difficult than I thought. The few times I overcome this habit and broke away from the infinite loop of no success I was able to stumble into the solution later because my mind was uncluttered and clear. One of the goals I have for myself in the future is to never dwell or obsess a problem.  

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

Draw your Own Map Pattern

So far, I have looked through all the patterns in the book as learning patterns. This pattern is somehow different it shows not a formula for growth but a remedy against decay. It tells us of things to come in our professional lives. It warns of the possibility of professional demands that can crush one’s soul. It tells stories of individuals bravely breaking through barriers imposed by different situations in life.

This pattern may seem unwarranted to the steps we are about to take, moving in fresh to the work force, but I believe it applies just as well now as it probably will 4 or 8 years from now. With the semester coming to an end many students probably had an internship opportunity, but many more probably didn’t. Finding out what makes someone tick can be hard especially with the lack of reasonable experience in different subfields. There is a lot of opportunity out there but not all of it are the best fit. I refrain from saying good or bad because I believe these are relative qualifiers.

Knowing what you want is important and changing your mind about what you thought you wanted is part of the process too. A lot of us will start on the first opportunity that comes out. Some of us may be luckier and have a short buffer to sort through a little. None will truly know what they are handed until they take the first step. But regardless of when and which, we must know the direction we want to take. Even not so glorious opportunities can serve us well as long as there are steppingstones in the right direction. We must watch for the fool stones, and this happens a lot I can say it from personal experience. You may find yourself in a place filled with opportunities that do not apply to you only because systematically maintaining you where you are is of greater interest to your employer and believe me, they will do the dance to have you stay there as long as possible. The author warns for that specifically. I think we are at a better place than the examples the author mentions. These people where stuck for years and the longer you take to move the greater obsolescence in your skill set. We must not wait long when is time to move. Employers have their own interest, and it is perfectly fine and healthy. But so should you have your own interests at heart and if they don’t align, then perhaps it is better for the employer, as well as yourself, to part ways.

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

Sprint #2 Retrospective

Issues Evidence

Issue:: backend: look at all lose files in backend/ and determine what is needed and keep them if so.

This issue was worked out in different layers. I wanted to be careful to maintain integrity while modifying the code.

Issue:: backend: in source/data create .js files for methods to be used.

In this issue we have decided after reviewing the code from last semester’s software architecture class that we would reuse it because it served the purpose of the project. Much of the code had to be changed and reformatted to meet our needs.

Issue:: backend: source/ figure out index.js

This file initialized the objects that are important for the operations across the various actions the backend is responsible for. My idea was to explore and find out more about the JavaScript syntax and methods and modules handling as well as behaviors.

Issue:: all: setup semantic release.

This was commission by Dr. Wurst, my colleague Robin and I had already worked through the process of factoring the steps needed to set up the continuous integration GitLab environment. Even though the steps were clear, I took longer than expected some failures along the way actually helped me look deeper into the settings of the continuous integration environment and experiment on them to find out the innerworkings of GitLab’s continuous integration tool and its security.

  •   Reflection on what worked well

In this sprint we tried to work out the issues we had on the first. The idea was to not repeat the mistakes already made and if mistakes were made, we would want them to at least be new ones. In that sense our sprint was successful we were able to identify and adjust expectations. One of the important things that we worked on was to be more specific on the issues and to delineate a better definition of done. In this sprint we were able to connect our different projects and also able to identify points where modifications need to be made in order to work properly.

  •   Reflection on what didn’t work well

Our team suffered from the short absence of some members due to personal unforeseen reasons. The team adapted and the absentee members put back in their missing share and we were able to still have our goals completed. We communicated well as a team but sometimes we would put in too much work leaving little to share. Thankfully the work done individually was hardly final and the trouble shooting, and integration made sure everyone had a part to play. We also had trouble with issue artifacts from the last spring. The names didn’t help us make much sense of what we needed then and moving them around got us a bit lost on planning for the last sprint.

  • Reflection on what changes could be made to improve as a team

To improve as a team, I think communication is definitely key. We should have more meetings outside class and maybe work on issues within these meetings. I see that sometimes we do work during class, but I think these one-on-one meetings would be better utilized for higher level organization, like adjusting tasks, trouble shooting, cleaning up the repo and other tasks. Reaching out is also a good idea if anyone is stuck. It not only helps the person trying to solve the problem but also whoever is there to help. It reinforces what they know and build confidence at the team level.

  •   Reflection on what changes could be made to improve as an individual

I personally think that I could have done more if I have not obsessed over an issue or another. I actually have found myself paralyzed by over planning. I have so many things to get done that organizing how to do them take longer than it is worth. I increasingly found that a generic schedule with cut off set times to switch from one activity to the next can help but a lot of times I freeze when stuck and enter a brute force infinite loop. This account for most of my wasted time that is when I believe that productivity not only flattens but drops so sharply that even if I moved forward, I still feel like I am stepping backwards. Shuffling tasks is truly the best way to succeed in not all but most so ill try to be better at that.  

From the blog CS@Worcester – technology blog by jeffersonbourguignoncoutinho 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.

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.