Use the Source: how to numb your mind faster than a lobotomy

Perhaps it’s just naturally a trait of mine, a coincidence growing up, or perhaps I more broadly reflect societies supposedly shrinking attention span; regardless of the cause, I have very little patience for reading documentation. Instead, I often like to open a sample project, usually the placeholder created by default, and see what happens when changing things around, or how information is passed between files. As such, I oftentimes find roundabout ways of completing tasks in a new language or framework. This results in less than ideal code, even if functioning, that does not follow best practice or any convention the language/framework may have. So therefore, the “Use the Source” spoke to a weakness I have in software development.

It states that one should choose a complex, and necessarily open source, project in the language you are hoping to learn to fork and pore over. In doing so, one can internalize as many of the lessons this code may have to teach, the ways experts write in this language, the “tricks of the trade” if you will; and, as a result, be inspired to apply these concepts in ones own project. This unfortunately, sounds terribly boring. It’s hard enough for me, and many other students I know, to pick apart our own code only months after writing it. I can’t imagine trying to parse years of work by developers with an incredible knowledge of their chosen language. This seems like a recipe for frustration. I could easily see a student not unlike myself throwing themselves at a new language in this fashion and coming away discouraged and maybe even completely overwhelmed; to the point where they may shy away from learning that language at all.

Instead, I would propose a healthier middle ground. I find that in messing with the code you can find little victories where your exploration paid off – victories that, for myself at least, keep me motivated. However, as mentioned previously, learning completely on ones own may waste valuable time and internalize bad or inefficient habits. As such, I think one should push their abilities as far as they can manage, then seek guidance from communities online. There exist thousands of YouTube tutorials and stack overflow threads where more than one solution is reached to nearly every problem; so, unlike the open source project, you can pick a solution that has a logic you understand best and can implement. I may have no patience to dig through years of documentation, but I don’t lack the patience to instead experiment and ultimately learn the language/framework.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Use Your Title

The next apprenticeship pattern I was drawn to has to do with the imposter syndrome. The problem comes when you obtain a title that doesn’t seem to reflect your skill level, at least in your mind.

The description of the pattern is much different than my expectation. I had imagined using a title to advance your career, but the suggestion is quite the opposite: it posits that the title is ultimately pretty meaningless as far as your skill level, but you can use it to gauge your employer.

An impressive title is tempting to pursue. It seems to prove to others that we’ve achieved success, which can be tempting for someone with parents to make proud or neighbors to keep up with. This can be completely removed from your actual success and may not reflect your actual job duties. While not explicitly stated in the book, this pattern suggest that if a company sets your title to something prestigious, and you don’t agree with it, it might be possible that the company sets the bar too low. If you know your skill is below a senior engineer, you should be somewhere where the senior engineers will help you get to their level. That’s not possible if all the senior engineers are at your level and know you don’t have the skills.

I’ve always reached out of my job title, as suggested by the Draw Your Own Map pattern I wrote about last week. As such, my job title did not reflect what I was actually doing. “Use Your Title” says that this can tell you whether you are appreciated, and reflects your employer more than your skills, and this has led me to leave jobs before.

I did have some problems with this pattern. It seems a bit contradictory, saying to not let your title affect you, but then saying to use it to decide how you feel about your company. Regardless, it sparked some thought about how I will be perceived and will help me to consider how my employer feels about me in the future.

I’m going to admit ignorance here: I don’t understand how the suggested action ties in with the description of this pattern. It says to write down a long, descriptive job description and consider how others would perceive you upon reading it. While this exercise might be useful, I don’t see how it applies to “using your title”. My only guess is that you want your actual title to match as closely as possible to your own goals. When there is a mismatch, for better or worse, it might mean you are not aligned with your company.

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.

Apprenticeship Pattern Review 5: Craft over Art

I am not lying when I say I have been avoiding delving into this pattern from Apprenticeship Patterns, for fear that it would hit close to home. Upon reading “Craft over Art”, I’d argue that this pattern is full of more enlightening information than any I have discussed so far. Oh yeah, and it also hit very close to home.

The context for this pattern is very general, as it states that you are being paid to deliver working software to a customer. The pattern argues that delivering working, useful software is paramount to building some magnificent thing in order to display skill or artfulness. We are trying to become craftsman not artists, and while there is a time and place where making the most beautiful code and software is appropriate, a line must be drawn. As explained in the pattern, it is important that a bottom line for quality is determined and met at all times, even under pressure. It is important to note that the authors argue that “utility and beauty are not opposed, but interdependent.” This means that we have to constantly choose a balance of the two that work for any given situation, and this will change constantly.

As I am an extremely creative minded person I find myself often trying to create “art” when I am trying to deliver working software, especially when I am working on self-directed projects. I find myself working on all of the frivolous parts of a project, expending all of my energy on minimal functionality. The end result tends to be me giving up on self-directed projects because I get burnt out working on all of the bells and whistles, while minimal actual functionality is present. A conversation between me and an observer tends to go like this:  “Wow that looks awesome! But what does it do?,” the observer exclaims. “Nothing but it looks cool right??,” I say, sweating slightly. My point is historically I tend to put valuable functionality lower than fancy technology and fluff. After learning about the Agile principles and Scrum frameworks I have been getting much better at reflecting and making sure what I am working on is valuable to the customer.

This pattern is packed with information that I will continue to think about in my career. It is fun to have a romanticized idea of what being a software craftsman is, but at the end of the day the most important thing is that utility is what I’m getting paid for.

From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.

First Sprint Retrospective created git repository for approve guest web ui. created isApproved web ui git repository. created ApproveGuestService git repository. designed our rest API and created a wiki page for it. created and worked with registration to create a mock database design. got familiar with how docker works and how we can use it to complete this project. found more information on docker and how to connect it to MySQL. Initialized and set up the base code that will be changed for the rest api. created a mock angular project to test and better understand how angular works and what it can do.

Things that worked well was letting people work at their own paces and at their own times in order to maximize work done. This laid back style that we used helped the members to not stress on what was done or what needed to be done by a certain time and allowed us to focus on the tasks at hand. Our team was very focused on each task and for the most part knew what we could accomplish. things that didn’t work were people calling different issues before they finished the one that they were working on which left other members trying to figure out what more they could do to be useful to the team. All of our reviews were done at the end of the sprint which made the quality of those review less than what they would normally be.
Since it was our first sprint, we were unsure of how much work was enough work and had a lot of free time to work on other issues because we finished the others early. As a team we could do reviews on Tuesdays and Thursdays to lessen the reviews needed at the end and allow for more time and consideration when reviewing each issue. We also need to only take one issue at a time and avoid planning out the work course for our whole sprint and instead only pick up the next issue when we finish the one we are working on. We should also set up schedule days to meet up and work together outside of class to be able to finish more and help one another with issues and problems that we might be facing. I want to work on making more time outside of classes to work on the sprint issues and work on more difficult tasks but since this sprint was just a set up sprint, I’m sure that I will be faced with more difficult/time consuming tasks. I also want to make sure that I add/write my ideas/communicate on gitlab so that it appears and if someone continues this project in the future they can understand my thought process.

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.

Sprint Retrospective 1

What we did as group for sprint

Our first sprint we planned out what are the things we need to work on during the sprint and how long would it take. We assigned each other to what their tasks will be, whoever was comfortable in doing took the tasks and started working on it and whoever was unaware or was not sure everyone in the group made sure that the member has enough info to cover the task. 

After agreeing and planning out the sprint, we all started to work on the project. We started by creating two black angular apps for is register and register guest and one black rest server. We created classes and used java language for the rest API, HTML and TypeScript for Angular App.

One of the challenges that we faced during this sprint was working on the database. We decided to choose MySQL for our database.

Overview of what we did:

  • Designing: endpoints, front ends
  • Choosing the database program to run the server to match with Angular App
  • Designing wireframes
  • Coding backend
  • Coding frontend

What i did for sprint

I volunteered to do the front end for the isRegistered. Shams and I discussed  what the layout of the page should look like. Before starting the code I made sure that the other team members agreed on the layout and language that I thought of using. To keep it simple, I used HTML and CSS and webstorm as the tool to write the code for the frontend.

What caught my attention was the Docker. I researched more on the docker whiel working on the frontend. I’ve never worked with a docker before and was curious in know how it works. I researched and shred whichever information I found helpful in understanding the  docker to the team.

Reflection on what worked well?

What worked well was frontend. I enjoyed my time coding and exploring more in designing the layout. It came out quite nice.

Reflection on what didn’t work well?

What didn’t work well for me was being consistent with the issues that were assigned. It was helpful in knowing the issues and working on it. But I rarely did a few because of figuring and working on the frontend. I would be aware of the next sprint.

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

I feel like not everyone was on the same boat. There should be roles assigned, such as who is the manager, which keeps everyone on check. I do feel confused about what else we would be doing in the project. I recommend planning out and having everyone on check.

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

     More material the better the understanding of the task. I should research and discuss what/how my team members are doing. Knowing it would also enhance my knowledge on the project and I might be able to help them as well.


    Whole project : 

    Issue board:

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.

Sprint 1 Retrospective

At the middle of last week, our team finally concluded our first sprint, working on user approving system for the LibreFoodPantry. Overall, I think our team did pretty good on doing a lot of initial setups and communicating with other teams to make sure we can have a consistency on data across databases. For me personally, I did quite a lot of work on setting up repositories, researching on making the back-end database, and helping my teammate, as well as people from other teams on the problems that they have that are related to our module.

List of what I accomplished during the last sprint:

– Setting up repositories, including ApproveGuestWebUIApproveGuestService, and isApprovedWebUI, which regarding to tasks like forking from templates, enforcing rules for making changes to the source code, and informing the team about that policy.

– Researching about how mySQL database can be initialized on Docker containers, import – export existing mySQL container for future usage, and communicating to it from outside of the container (wiki page is available at link)

– As I am more interested in getting the back-end to finish in the early stage of development, I helped one of my teammate, Tyler, to make documentation about REST API endpoints and further getting feedback and making suggestion with other teams on those endpoints (wiki page is available at link).

– With all that endpoints in place, I setup the schema to potentially be what the mock and the actual database looks like and getting appropriate changes to it to match with the Register Guest module (wiki page is available at link).

– Finally, I had a lot more time towards the end of the sprint than I expected, so I dug deeper in setting up Spring Boot for the REST API and making a few objects within the program to lighten the amount of work for the next sprint.

With a lot of work that is put into initializing the project, I also learned a lot. While I did have a chance to experience SCRUM on my last internship, this time we use Gitlab as a tool to log all of our work, which I really the simplicity but professional and effective, rather than Jira and Confluence, which are more corporate driven software. I also learn to operate Docker, which I delay on getting to know it for a while as I though to myself that virtualization is a most optimal way to go, and after the last sprint, both are now under my consideration for future projects. And lastly, I learn that communication is really important, especially in the early stage of development, as a lot of data structures have to be defined and unified among the teams.

There is also the excitement, and at the same time,  frustration, of planning what to do to optimize the time and the work needed to get the job done as we had a list of questions without a clear answer on where we should head to. Although on Gitlab, we got really few comments put up, the teams had a lot of face to face conversations to make decisions on problems, and that I think is a problem that we need to record more of our conversation during the next sprint. At the end of the sprint, we are able to finish every issue tickets that we put up initially and we got quite some spare time afterward so I think we did a really great job on what we set out to do and I think the more sprint that goes on, we would be able to take a much heavier workload.

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

Sprint Retrospective 1

What we did as group for sprint For this sprint we as a team started our first meeting by putting in place a plan for the whole sprint, we picked the first steps of the architectural design for our API. We decided the roles for each one of us, and then divided the tasks, so … Continue reading Sprint Retrospective 1

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 1

For the first sprint we did a lot of setup tasks as well as the designing of the architecture. In addition to some of the programming. The first thing we did was talk about the architectural design of the service. Once that was settled a group member created the wireframe for the “register” user interface. A group member also created the wireframe for the “is registered” user interface. The next thing we did was create the blank projects on gitlab. After this we initialized two blank angular apps in the user interface projects. We also created the blank rest server. While this one going on a group member was working the database understanding it and creating one that the architectural design specified. At the same time we created the class the design specified in the rest api and created the endpoints. We also connected the endpoints to a run-time database to test the rest server. In Addition we put in a template to learn how to make scheduled calls in a rest server. At the same time we also started coding the wireframe designs in HTML pages. That basically all we did for the sprint.

For the sprint I personally first created the main documentation issue and kept  it updated. I did this after the meetings or after consulting with the rest of the team and coming to a consensus with them. I also did several of the issues. First I did the issues for creating the 4 projects and initializing them. I also did the issue for designing the endpoints. I also did the issue for creating the object classes for the rest server. In addition i did the issues for creating the endpoints and finishing the rest server with a fakes database implementation. The last issue I did was researching how to make a scheduled method call in a rest server.

For the sprint I personally first created the main documentation issue and kept  it updated. I did this after the meetings or after consulting with the rest of the team and coming to a consensus with them. I also did several of the issues. First I did the issues for creating the 4 projects and initializing them. I also did the issue for designing the endpoints. I also did the issue for creating the object classes for the rest server. In addition i did the issues for creating the endpoints and finishing the rest server with a fakes database implementation. The last issue I did was researching how to make a scheduled method call in a rest server.

I thought the sprint went mostly well. I thought we did using the issue to break the work of the project up into smaller pieces for us to do. I also thought we did a good job of assigning issues to different people to make sure everyone had something to do. Lastly, I thought the documation issue worked well to keep the whole team on the same page as far as what the current plan was.

    Even though the sprint went well there were still some things we needed to improve on. I feel like there should have been more time spent planning before we started. Since a lot of  the first half of the sprint was spent changing our mind on the design and having to start over and this was inefficient. In addition before the working documentation issue was made we were not really telling each other what the plan was or when we changed it. We also could have had better communication overall especially at the start. We got much better later on though.

There are a few we could do better for the next sprint. I don’t think there is much however as we fixed most of the problems by the end of this sprint. The most important thing is to have a better planning meeting. We could be more communicative with each other on what we are doing. Lastly i guess the communication we do have could be better quality and more informative.

I could do a better job individually too. For the next sprint I need to do a better job of explaining why I am making the decisions i am making. I could also do a better job keeping the team updated on what I am doing and my progress. Lastly I could do a better job with the overall documentation of my issues. That being said, I don’t think me or anyone else in the team really needs to be better individually to much.  I think the biggest problem was the poor planning meeting at the beginning.


    1. This is the whole project.
    1. This is the rest server project i was working on.
    1. This is the issue board for all our issues.
    1. This is the working documentation issue that has the current plan for the project.

From the blog CS@Worcester – Tim's WebSite by therbsty and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective

Here I am finding out about docker, posted resources to videos for the team.

Created a document that highlighted the key commands that would be used for docker containers and images.

These are the endpoints that I reviewed and moved to done.

From the very beginning of the spring we had assigned everyone an issue of what they needed to start on. From there each respective person worked individually on their assigned task until moving onto the next one. This was working well for our team in the beginning and for me, because I had a higher weight task, because everyone had something to work on. However, once I thought I was done researching docker and creating the wiki for the docker commands, I had run short of things to do with docker. My main task was familiarizing myself with docker but since we were not going to be using docker until at least the next sprint, there was little to do with everything I had just learned.

Another tough issue was the actual design of our endpoints. Our teams had not yet gotten the documentation of what would be stored for information on each person. For our initial design we made simple variables that could be replaced once the correct information was present. Eventually we were able to change into the correct variables with proper documentation.

Our team was very good at coordinating with the others when it came to work on our endpoints. We had originally designed them each with base variables as described before. After the documentation was given, the main problem that arose was the communication between other teams. We needed to understand what we were pulling from other teams and what they would be pulling from us. Our team did well to communicate and document the interaction and solutions on GitLab.

I think something that our team could do better in the division of tasks. For next sprint, as mentioned in class, we will be waiting to assign the next task once someone has completed theirs. I believe this will allow for a smoother distribution of work. Another team improvement, we could have better documentation when working through GitLab. When different people were working on different task, it was easy for the work completed to be missed. It can also cause a lack of understanding through the team if there is not much to go off of.

An improvement I could make would to be to take on a greater responsibility. I need to communicate to my teammates that I need to take on more work than previously because I felt a lot of time was wasted. I have to be better at involving myself in the ongoing process of something new in order to immerse myself, even if it is just to help push someone to the end of their goal. Another change I will make going into the next spring will be better documentation. I posted a document in the wiki for reference, but should be in markdown on the page for everyone to see easily.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective: Trial by Fire

Last week our team concluded our first sprint working on the Approve Guest module for the LibreFoodPantry project. This project is part of my Software Development Capstone and has us working on an open source project using Agile principles and the Scrum framework for software development. While I think the project has been going well, there are definitely aspects of our workflow that can be refactored in order to increase our productivity.

What I Completed This Sprint:

For this sprint I took the role of Scrum Master for my team of four. I felt like this would be a great way to put my knowledge of the Scrum framework into practice. While I tried to make sure I was available to the team to answer any questions about Scrum, I feel like I didn’t emphasize the importance of following the scrum framework as well as I could have. I facilitated the stand-ups at the beginning of each class period as well as planning and review meetings. Our team did a good job of explaining what they had done prior to the stand-up and what they were going to work on, but the stand-ups were never used to raise questions about logistics or talk about progress towards meeting our Sprint goal. I feel this is because much of the Sprint was used for getting adjusted to the slightly more structured workflow that we are working with. If I continue to be Scrum Master for our team I will make sure that we utilize class time to the fullest in order to have open discussion about what we need to complete and how we can deliver working software as fast as possible while doing only the minimal amount of work necessary.

I think its important that, as a group, we start to utilize GitLab and our issue board to a greater extant than we did this Sprint. In the beginning of the Sprint we were having trouble coming up with what issues to work on because we didn’t have much information about exactly what it was we are building. I feel like not only our team, but all teams were very concerned with granular aspects of the project such as, what attributes should we be storing in our databases and what style guidelines should our applications use. All of the information that was up in the air was making it difficult for us to feel like we can start developing since everything is subject to change, but it is important for us to remember the Agile principle, “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage”. We should be building this expecting requirements to change, rather than feeling the need to wait until requirements are finalized to start working. Also, I feel like even though our communication with each other and the other teams improved greatly from the start of the Sprint, we should be communicating as much as possible in order to maximize our productivity. We had good discussion with other teams but left minimal evidence of this on GitLab, which is something that we will need to be more vigilant about in the future.

We were able to finish all issues in the Sprint before the end, which is a sign that we gave ourselves too little to work on. I think as a team we made an acceptable amount of progress this Sprint as it was our first ever sprint working as a team. Going forward we can more accurately gauge how long each issue will take us to complete and make sure each member of the team delivers a reasonable amount of work by the end of the Sprint. Reflecting on what I delivered this Sprint I know for a fact that next Sprint I will need to give myself more issues to work on. I wanted to start working on our actual web applications, but the fact that our requirements were vague made me decide maybe we could leave that for the next sprint. I think my own fear of the unknown had me making many spike issues, when we could have made greater progress on the application itself.

“Working software is the primary measure of progress.”


From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.