This week I like to talk about this pattern “Reflect As You Work”, so far this pattern is the best in my opinion, this pattern talks about the need to evaluate the work on regular bases, because with time and the lode of work for people who have competent speart, they will get promoted in … Continue reading Reflect As You Work
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.
As I near the end of my college career I am giving more thought daily to what exactly I need to put forth to land my first job as a Software Engineer. Will companies value the fact that I am very creative minded and enjoy collaborating on projects or is are they only looking for the cold hard skills that I have gained over my years of study. The Concrete Skills pattern from Apprenticeship Patterns highlights the fact that, while soft skills are important, the ability to apply knowledge in order to provide value to the companies you are applying to is paramount. Why should a company take a risk on a candidate who doesn’t show that they have the skills the company needs when they can hire someone who does.
This pattern is all about identifying exactly what skills the job you want is looking for and gaining the skill. What may be even more important than learning the skill is building a project using that skill in order to prove your adequacy. While the ability to learn quickly is a great skill, having the foundational skills companies are looking for is important when searching for landing a job. It is important to research which skills are relevant to the positions you are applying for rather than trying to learn everything, since that is an impossible task.
I have recently started my job search and more and more I’m realizing the benefits of having projects that prove my competence in relevant skills for the jobs I am applying to. This pattern has made me realize that it would be a great idea to ask people in my network who are further on in their careers about what skills they put forward that helped them land a job. I can then use this list of skills I gather to slowly pad out my resume with projects that prove that I can provide value to the companies I am applying to. Since I am in my last semester I am pretty packed with coursework, but I am going to set out to learn at least one relevant skill every weekend. By the end of the school year my GitLab will be a place where all of my skills are shown off with well crafted, yet small in scope projects. Concrete Skills is a pattern that every software developer should read and implement because of the huge benefit that it gives you in your career as a Software Craftsman.
From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.
The pattern “Be the Worst” is one that most people have heard many times and its a great life lesson that can be applied to many other situations. The idea is to surround yourself with people that are better than you and learn from them and grow. Basically don’t be afraid to not be at the same level as your peers and try to surpass them with every experience. This can also be a way to help others that are struggling or want to be better at something that you excel at. This pattern is definitely one that i could see myself using in my professional career and also in my education because the quickest way to learn something is to be surrounded by people that understand the concepts and to observe them and ask questions. Everyone has weak points and things that they wish they could be better at so finding people that excel at what you struggle with can only help you to learn and grow.
The one thing that I feel this pattern failed to make an extremely important part is that you should strive to go on and become the best at what you learn. I might just be a competitive person and this may not apply to all people, but I personally would want to become the best at whatever I do. This pattern also fails to really talk about doing the reverse which would be helping others in the same way that you want help. This pattern changed my perception about the profession of software development because I didn’t really think about how people from all over the place could be assembled to help one another understand things and it makes me think of a coalition/brotherhood rather than work or a job. The pattern talks about how it is a little selfish to join a team knowing that you are the weakest link and that you might hold them back a little, but sometimes you need to be selfish and think about yourself and what you need to grow and become better. Being selfish at times is needed to advance yourself and your career, so I’ll probably do this pattern unashamed and ready to become the best in every group.
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.
Researching more on audio feature extraction last week gave me a lot to think about. As it settled in, I came up with great ideas for hypothesis to test and specific applications for them. The kind of ideas that lead to turning off your cell phone, skipping lunch and dinner, and get things working.
Unfortunately, as mentioned last week, I do not have the time learn audio processing algorithms to the extent that I can implement them, so I will have to make a choice on a library that will help. A further complication was getting code to run in Android. Libraries exist to run Python code in Android, but the Python libraries I’ve found for audio analysis are lacking in features and I would need to use a combination.
The most comprehensive library I’ve found is Essentia. Of course, it’s so comprehensive I won’t be able to use the code for a professional app without a commercial license. Luckily there is a noncommercial license available that will allow me to get results for the project and determine if there are commercial applications.
Essentia is a C++ library. So the good news is I get to use JNI and the Android NDK (Native Development Kit) to run C++ code. Getting C++ code to run from an Android Activity is straightforward enough, but I do worry about potential complications in running Essentia. There are a number of dependencies that I fear might cause trouble with a feature I might want in the future. These are kept to a minimum with a special flag during compilation for Android. But alas, my paranoia strikes.
Because Essentia is open source, I am at least able to see implementations of the audio processing algorithms, and the code is well-documented with references to studies. Signal processing is a degree, not just a semester-long project. I certainly appreciate that fact more over the past couple of weeks. But this will be a great overview and using the code will still require understanding of the underlying processes.
Progress was made on converting files from audio to basic byte data. When I was considering Python libraries, I was under the assumption I could use WAV files and easily get byte data (for example, with librosa). Android’s MediaRecorder doesn’t support saving WAV files, so other formats must be used.
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.
The first of the patterns in Apprenticeship Patterns that I have decided to discuss is titled “Expose Your Ignorance.” This pattern deals with situations where we do not understand every skill we need to use for a project. In such situations, people tend to fake an understanding of things they don’t know in order to appear competent. Rather than hiding our ignorance in this way, the pattern recommends acknowledging when we do not know something and explaining to colleagues that we are still learning about it. This makes it easier to build relationships and improves our ability to learn, which are both important skills for a software craftsman.
I chose to share this pattern because I found it relatable. During many programming projects I have been a part of, I have had trouble understanding topics that my peers seemed to have no problems with. Despite this, I’ve avoided asking questions due to a fear of appearing inadequate or ignorant, and have generally tried to answer my questions through my own research. I think that following this pattern would greatly improve my ability to learn new skills quickly. I would likely have an easier time learning new skills directly from someone with experience instead of trying to teach them to myself.
Knowing that this pattern could improve my ability to learn new skills quickly, I think it may change how I approach future programming projects. Previously, I have felt ashamed of not knowing things and have felt responsible for teaching myself in order to meet the expectations of my team members. I think this pattern will help me accept that it is okay not to possess every skill required for a project. It will also encourage me to communicate better with other developers in order to gain the skills I need. I have always had trouble asking questions and communicating in general, and I think this pattern would encourage me to get better at it. I will try to approach future projects from the perspective that it is okay to not have every skill I need, and that I should try to learn from other developers instead of keeping to myself. This communication might also help me build relationships with other developers as well as a reputation for myself that could lead to a more successful future.
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.
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.
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.
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.
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/ApproveGuestWebUI created git repository for approve guest web ui.
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/isApprovedWebUI created isApproved web ui git repository.
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/ApproveGuestService created ApproveGuestService git repository.
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/ApproveGuestService/-/wikis/REST-API-design designed our rest API and created a wiki page for it.
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/ApproveGuestService/-/wikis/Database-Schema created and worked with registration to create a mock database design.
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/ApproveGuestService/-/wikis/Docker-Documentation got familiar with how docker works and how we can use it to complete this project.
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/ApproveGuestService/-/wikis/mySQL-with-Docker found more information on docker and how to connect it to MySQL.
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/ApproveGuestService/-/tree/feature/initialize_rest_api Initialized and set up the base code that will be changed for the rest api.
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/mockprojects/AngularTodoList 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.
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:
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.
Links:
Whole project : https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest
Issue board: https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/Plan/-/boards
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.