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.

Apprenticeship Patterns: Concrete Skills

The next Apprenticeship pattern I’ve decided to discuss is titled “Concrete Skills.” This pattern is targeted at developers who wish to join a talented team in order to find better learning opportunities. The problem here is that professional development teams have no incentive to hire new developers who cannot immediately contribute to their work. The pattern explains that, in order to acquire a position in such a team, a developer should develop concrete skills. These are specific skills that a developer is particularly experienced with, such as working with a certain language or development framework. By knowing and being able to list their concrete skills, a developer can help themselves gain the trust of professional teams and begin a career as a software developer.

I chose to read this pattern because I have often experienced fears regarding my ability to find a career with my current experience level. I frequently feel that my current skill set is not good enough for me to be useful on any professional development teams. I think this pattern has helped clarify my reasoning behind these fears. Development teams focus on concrete skills when determining who to accept, while I have always been focused on my overall skillset. This perspective has caused me to focus on what I don’t understand when looking over the work of experienced developers, which has only served to discourage me and make me feel inadequate.

In order to get a start as a software developer, I should focus on determining what my concreate skills are and solidifying them. This pattern helped me understand that concrete skills are more important than overall experience to teams accepting new members. For this reason, I should focus less on what I don’t know and how I compare to other developers, and I should instead concentrate on the skills I already have. In the time I have been pursuing software development, I’ve become skilled at programming in many languages, especially Java. I’ve also learned to use tools like Git and frameworks like Angular, and I’ve done lots of work with creating GUIs. These are just a few of my concrete skills, and I’m sure many of them would be useful on a development team. If I start concentrating more on solidifying these skills and less on grasping at skills I don’t have, I could likely put together a list of concrete skills that would help me find a place on a professional team.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Sweep the Floor

To be successful in software development field communication, dedication of working along with different work environments, gaining trust from team members and clients is important.

Imagine you are new in a fully developed team. All team members know each other well enough to be comfortable discussing the software that they will be working on. And there you are, unaware of the work environment, software and team members. It is because you are new and also because they are unaware of you as well. Now, if you don’t start communicating with your team because of lack of experience or knowledge on a software, programming or any specific task in hand then you will prevent the team’s growth and their trust in you. 

In order to prevent any miscommunication, try to ask questions, add up your opinions, learn from them, shadow how they are doing and ask to volunteer. Taking small steps in account will never lose their trust in you. They will acknowledge that you are willing to help even with little knowledge. Such as, maintaining, reviewing code, “bug fixing, eliminating technical debt, setting up the project wiki, updating documentation, acting as a sounding board for other people’s ideas, and so on.” Try to focus on less edgy work, where there are less risks rather than “rather than the core where there are usually many dependencies and lots of complexity.”

Acknowledging simply takes you from doing nothing to doing something  meaningful for yourself and for the team. It will be hard beauce you are putting time and effort into something that isn’t big enough for you to enhance your programming skills. But if you take in this action and do more research and discuss with your group you will soon be able to help in complex areas on a project. 

It is something that everyone complains about when they are in this situation. It is like being an intern again. It is a slow process towards your growth in the field but the only way to get out of it is to be patient and try to give your efforts to contribute to the project.

From the blog CS@Worcester – Tech a Talk -Arisha Khan by ajahan22 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Record What You Learn

Today I have decided to post about the “Record What You Learn” pattern. This pattern is targeted at developers who find themselves repeatedly learning about the same topics. Some lessons just never seem to stick in their memories, and they often forget the details of their past works. According to the pattern, simply recording what you learn in a journal, wiki, or blog can be an effective solution to this problem. Keeping such a record not only helps reinforce old lessons, but it can provide us with a powerful tool for drawing new connections in our knowledge and developing new lessons to pursue. A record also helps us understand how we came to develop our skills and allows us to easily share our experiences with others.

I decided to read this pattern because I often find myself repeating old lessons. Many programming projects I have worked on, both on my own and for school, have required me to reapply topics I worked with in the past. More often than not, I struggle to remember all the details I need and have to search for tutorials or guides to refresh my memory. In fact, my list of bookmarks in my browser is crowded by tutorials that I have needed to return to many times. Whenever I find myself searching for help with an old skill, I just get frustrated with myself for having a poor memory. I never even considered keeping a record of my lessons to make them easier to remember.

Reading this pattern has definitely changed my perspective on my troubles with remembering old lessons. I may be having these difficulties because I have not done anything to reinforce my lessons, and not simply because my memory is bad. I definitely think keeping a record in a journal or a personal wiki would be helpful to me. Instead of searching through my list of bookmarked tutorials for hours searching for one bit of information, I could simply refer to my own record to find what I need quickly. A record would also make it easier to reflect on my past lessons, which I think could help motivate me to continue learning new things. In addition, a record might make it easier for me to help others learn skills, as it would allow me to look back on how I learned those skills myself. I was honestly surprised by how useful recording what you learn can be, so this pattern has made it clear that creating a record of my lessons would be worth doing.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

Study the Classics

The second pattern for this week Apprenticeship Pattern is “Study the Classics”. I think this one is pretty straight forward, as it states on point that reading and learning what is in the past is as essential as doing so with documents and books in the current generation, as it would allow ourselves to expose to problems that we might rarely see at the moment.
The patterns start out with an extremely interesting problem that a lot of more experienced people in the field would likely to reference a concept from books and area that we might have now idea it exists, but they expect us to know it already, like any other self-respecting software developers. I have not experienced anything thing like this while working as an intern, but I can imagine that it does happens a lot to new developers in the field. The author explains the solution in a very simple way, which is to admit your ignorance, and ask about the concept, how it works, where do they reference it from and add it to our own reading list. For people like me who has not experienced a situation like that to get a title to read, when picking out books to read, the author recommended us to look at how out of dated it is comparing to the continuously evolving technologies that we have right now to make sure that we are reading the one needed for our on need in the current state of technology development. I think that does not really mean that we can ignore all of the books that are written decades ago as it might contains a lot of information that can even serve until today, still however, they should not be on our top priority list. It is best to have a mix between classics and modern to have a feel of what is the differences, what is improved, what is still remains, and that is the best way to avoid making the same mistakes and have a better referencing stand point when putting out our opinion to the team.
In my opinion, this pattern does not necessary to contain the most useful information to choose the best book out there to read. I think if the author put out some of the examples to make comparison, like a book about Python 2 and another one about Python 3, it should make a clear distinction in the reader’s mind that this pattern is important to keep in mind. With that being said, I think the patter itself is not too informative as much as the other one, but it does have some value to tell the readers that books will always have their value, whether it is old or new, but to prioritize reading the right one, would make one more successful than others

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Concrete Skills

The first pattern in the Apprenticeship Pattern that I read for this week is Concrete Skills. The pattern pretty much talks about skills that are required to be focus on when an apprentice software developer like us start our career. It also lays out a concept, which is to have knowledge about it, does not mean that we can successfully apply it to create a piece of software, and I think that this is crucial to remember.
The pattern starts off by posing a really interesting problem that I think a lot of people, even veteran, are facing I would say, which is having a team, or a company that is not willing to hire someone that will, for sure, not able to not make any contribution to the project, whether it is direct or indirect, and this I think would take away the potential for an individual to learn and maybe even progress himself/herself in the field if it happens to them constantly. As the author starts to explain the solution, which is to acquire and maintain concrete skills, which is really generalized, but when he starts to explain further, it makes a lot of sense to me. He explains that we just simply can bring the ability to learn quickly, or the ability to bring a specific tool or technology that allows the team to work better, and our credibility will be increase among the team, so it is best to be prepared a lot of necessary skills and tools before applying for a position in a team. I like the point where he points out that some hiring manager will have to trust us with what we have and bringing a creation of our own might ensure them that we will fit the job that benefit them. I found it also true that these concrete skills are only noticeable when our resumé is new and lack of experiences. It is certainly be easier as we proceed from job to job, as they are more likely to look at our personal experiences, reputation, and most importantly, our portfolio.
Personally, I think this pattern is really brief about the subject matter, it does not necessary be the most informative patterns, but it certainly motivates me and I am sure a lot other developers out there to learn and do more in their own time in order to make their resumé looks better, as well as gaining more experiences in using tools and languages at the same time. It also made me realize that the demand of tools and technologies are always going to change, so it is quite essential to always learn new things on the go, although our pool of knowledge is filled with a lot of stuff that can easily be used in a team at some point. I feel like this pattern is different as it is more about preparing for getting a job in the field, but it is quite important not to be passed by by new developers.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Wax On,Wax Off

The pattern “Sweep the Floor” talks about how as a new member of a development team you should take the jobs that people dislike and work on the things that are an annoyance. This strategy is something that will help a person to become a valued and respected member of the team that they have recently joined since they did something others felt was a pain. The pattern suggests that you take the leap that others are unwilling to because it will build your reputation among your colleagues. The pattern also talks about how when you start a job after college, that you are effectively starting from square one and the education you received only raises what people will expect of you. This pattern also talks about some negative impacts that may happen, which are that you might become the team’s gopher and be stuck doing the menial tasks that others do not wish to.
This pattern reminds me of my sports teams in high school because the younger and newer players would be stuck carrying the equipment, like basketballs/soccer balls, because they were still learning and were going to be the next generation of the team. I felt that this hierarchy was necessary and built character in many of my teammates and myself. I can see myself wanting to impress and help my future development team in the future, so I will apply this in my future job. I felt that it’s important that the pattern mentioned the possible downsides of this pattern which is being stuck as a floor sweeper. I respect people with more experience than me, but after some time has passed I will not allow myself to be stuck as a floor sweeper and I am not afraid to voice my thoughts and opinions on these matters. Trust is an important part of teamwork, so this is something that can easily help me and others to build that trust with their new team. This pattern didn’t change my thoughts on what I expected in the software development field because having the new workers do things that are a hassle or really low level things is common practice in every job in every field.

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.

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.