I read Apprenticeship Patterns as per the syllabus and I found a lot of things that resonated deeply with me. Dave talks about giving up on learning to code, or rather to program after being unable to do anything compelling or significant, and only having had mastered Perl on his third attempt. I myself have on multiple occasions traded a language for another when I stop making progress. My thinking was – “Maybe, this isn’t the one for me”. So, I hopped from Python to JS to Scala to Java to C learning only the basics and just enough to satisfy any classes that might’ve required it. I was a jack of all trade, and master of none! Only upon revisiting Python again for a summer fellowship with a professor, and working on learning more than just the syntaxes, idiosyncrasies, and fun facts about the language, was I able to move on to being somewhat competent. Dave’s story tells us how he sought out mentors, took on challenging projects, and continuously challenged himself to improve and grow as a software developer. His story serves as an illustration of the apprenticeship journey and the importance of seeking out opportunities for learning and growth in the software development field.

I also really liked the definitions and the progression in stages – an apprentice, to a journeyman, to a master. Looking at software development as a craft to be honed and mastered like an Archer, or a Swordsman was quite interesting to think about. The third chapter especially was very enlightening. For the pursuit of efficiency, or most likely in service of sloth – my favorite sin, I take shortcuts whenever possible. I have noticed in myself the tendency to bodge things to make do – like putting on a band-aid over a bullet hole, to push perfection for later, to say – “Can’t be bolloxed, this will have to do!”.  Walking the Long Road is quite a departure from that mindset, and one I hope to grow into. Ah! to be able to rip off the band-aid!

All in all, quick fun read. Not bad at all!

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

I read Apprenticeship Patterns as per the syllabus and I found a lot of things that resonated deeply with me. Dave talks about giving up on learning to code, or rather to program after being unable to do anything compelling or significant, and only having had mastered Perl on his third attempt. I myself have on multiple occasions traded a language for another when I stop making progress. My thinking was – “Maybe, this isn’t the one for me”. So, I hopped from Python to JS to Scala to Java to C learning only the basics and just enough to satisfy any classes that might’ve required it. I was a jack of all trade, and master of none! Only upon revisiting Python again for a summer fellowship with a professor, and working on learning more than just the syntaxes, idiosyncrasies, and fun facts about the language, was I able to move on to being somewhat competent. Dave’s story tells us how he sought out mentors, took on challenging projects, and continuously challenged himself to improve and grow as a software developer. His story serves as an illustration of the apprenticeship journey and the importance of seeking out opportunities for learning and growth in the software development field.

I also really liked the definitions and the progression in stages – an apprentice, to a journeyman, to a master. Looking at software development as a craft to be honed and mastered like an Archer, or a Swordsman was quite interesting to think about. The third chapter especially was very enlightening. For the pursuit of efficiency, or most likely in service of sloth – my favorite sin, I take shortcuts whenever possible. I have noticed in myself the tendency to bodge things to make do – like putting on a band-aid over a bullet hole, to push perfection for later, to say – “Can’t be bolloxed, this will have to do!”.  Walking the Long Road is quite a departure from that mindset, and one I hope to grow into. Ah! to be able to rip off the band-aid!

All in all, quick fun read. Not bad at all!

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

I read Apprenticeship Patterns as per the syllabus and I found a lot of things that resonated deeply with me. Dave talks about giving up on learning to code, or rather to program after being unable to do anything compelling or significant, and only having had mastered Perl on his third attempt. I myself have on multiple occasions traded a language for another when I stop making progress. My thinking was – “Maybe, this isn’t the one for me”. So, I hopped from Python to JS to Scala to Java to C learning only the basics and just enough to satisfy any classes that might’ve required it. I was a jack of all trade, and master of none! Only upon revisiting Python again for a summer fellowship with a professor, and working on learning more than just the syntaxes, idiosyncrasies, and fun facts about the language, was I able to move on to being somewhat competent. Dave’s story tells us how he sought out mentors, took on challenging projects, and continuously challenged himself to improve and grow as a software developer. His story serves as an illustration of the apprenticeship journey and the importance of seeking out opportunities for learning and growth in the software development field.

I also really liked the definitions and the progression in stages – an apprentice, to a journeyman, to a master. Looking at software development as a craft to be honed and mastered like an Archer, or a Swordsman was quite interesting to think about. The third chapter especially was very enlightening. For the pursuit of efficiency, or most likely in service of sloth – my favorite sin, I take shortcuts whenever possible. I have noticed in myself the tendency to bodge things to make do – like putting on a band-aid over a bullet hole, to push perfection for later, to say – “Can’t be bolloxed, this will have to do!”.  Walking the Long Road is quite a departure from that mindset, and one I hope to grow into. Ah! to be able to rip off the band-aid!

All in all, quick fun read. Not bad at all!

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

I read Apprenticeship Patterns as per the syllabus and I found a lot of things that resonated deeply with me. Dave talks about giving up on learning to code, or rather to program after being unable to do anything compelling or significant, and only having had mastered Perl on his third attempt. I myself have on multiple occasions traded a language for another when I stop making progress. My thinking was – “Maybe, this isn’t the one for me”. So, I hopped from Python to JS to Scala to Java to C learning only the basics and just enough to satisfy any classes that might’ve required it. I was a jack of all trade, and master of none! Only upon revisiting Python again for a summer fellowship with a professor, and working on learning more than just the syntaxes, idiosyncrasies, and fun facts about the language, was I able to move on to being somewhat competent. Dave’s story tells us how he sought out mentors, took on challenging projects, and continuously challenged himself to improve and grow as a software developer. His story serves as an illustration of the apprenticeship journey and the importance of seeking out opportunities for learning and growth in the software development field.

I also really liked the definitions and the progression in stages – an apprentice, to a journeyman, to a master. Looking at software development as a craft to be honed and mastered like an Archer, or a Swordsman was quite interesting to think about. The third chapter especially was very enlightening. For the pursuit of efficiency, or most likely in service of sloth – my favorite sin, I take shortcuts whenever possible. I have noticed in myself the tendency to bodge things to make do – like putting on a band-aid over a bullet hole, to push perfection for later, to say – “Can’t be bolloxed, this will have to do!”.  Walking the Long Road is quite a departure from that mindset, and one I hope to grow into. Ah! to be able to rip off the band-aid!

All in all, quick fun read. Not bad at all!

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

Testing is an essential tool when it comes to software development. This week I listened to the podcast “Code Newbie Podcast”. In the episode “How to make sense of the testing landscape”, they talk about the importance of testing, and why people test, what kind of testing is done. They bring in Sergei Egor who is the CEO of AtomicJar. His company works with Testcontainers a java library that supports JUnit testing. The reasoning for looking into this episode, in particular, is so I could get more familiar with how testing works and its intricacies. The experience with testing my programs is very minuscule, and so having a veteran QA developer explain the little details of testing is just what I need personally.

Sergei goes on and explains that when discussing software, new features are being implemented almost all the time and so in order to make sure that those features work as intended, testing must be done. When working on a program, it’s fair to assume that the program must meet a certain amount of requirements and so testing ensures that all those requirements are met. The whole point of Sergei’s company is to optimize testing for software companies that don’t want to create miscellaneous code just to test a certain feature or task. The question that Sergei brings up is why can’t it be done through the backend of the program? And so Sergei’s company basically specializes in these software developing phenomena.

He goes on to explain different types of testing such as automated testing, performance testing, and the most popular type of testing which is unit testing. Unit testing is basically low-level and it will tests individual methods and functions. I’ve worked with unit testing in my previous computer science courses so I am most familiar with this type of testing. I would use unit testing in java for the most part. I had a project that involved me creating a banking account class, and basically, I had to create a JUnit class that would test all my methods such as my “getFirstName” method or my “getBalance”, so on and so forth. It would basically tell me if these methods succeed or not. When Sergei started talking about unit testing it felt very familiar with assignments I’ve worked on in the past.

When he started going into performance testing which is a test that evaluates the speed and reliability of an application, it made sense on paper but with my little experience, I began to struggle with how one may go about doing something like that. With the implementation load test as Sergei mentions, load tests are used to work the application to its full potential and record its response times and request counts as he goes on to explain. Something else that I found interesting while listening to Sergei is the question of why can the developers test the code so that the company doesn’t have to hire a crew of QA engineers. In Sergei’s words, he explains that many developers don’t want to think of all possible inputs for a program they would rather have an algorithm such as property testing do it for them.

Property testing relies on properties and makes sure that a program abides by those properties. It would be interesting to see this type of testing work with my mobile application which word recorded finance information- it would typically crash when inserting a record of payments occasionally and so having an automated testing algorithm such as property testing could have helped me figure out why my program failed in some instances. Automated testing would serve me in testing my programs and their functionality, running multiple tests whenever it’s needed.

Link to “Code Newbies Podcast” S18:E4: https://open.spotify.com/episode/51gZ0yQATZQ8twsJzRb7YE?si=39e4585f9db143c0

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

This blog documents my journey learning Computer Science (CS) concepts. Posts will be precise and summarized to make the entire process informative, enjoyable and worth your time. The CS discipline is constantly changing and I can’t wait to see what’s coming up next, hopefully we can keep up! Let’s explore together and brace ourselves for the journey ahead.

One more thing, I thought it would be good for me to give a brief background about myself so you can get the whole picture. My passion for technology started when I was young, about the age of four wondering about the person speaking inside our family’s radio and how they fit in there. These are some of the questions I wrested with and couldn’t imagine how tiny that person could be.

As time went on, so did my enthusiasm; this time it was anything electronic especially mobile phones. Back in my day, it was only adults who owned phones and they were mono colored specifically black with a green background. No apps had been introduced yet, the only capabilities they had were messaging, making and receiving phone calls, contact’s book and a few select games such as snake and Tetris. At any opportunity I had to hold someone’s phone, I went straight to looking for games and if I didn’t find any I was deeply disappointed.

Fast forward as technology grew, I decided that I would invest myself in understanding how things work and how they were made to work. In high school, my best classes were STEM especially Physics and Maths. It was fun seeing how different formulae would be used to solve computational tasks. I recognized that paying attention to detail was key to solving any problem. I self-proclaimed myself to be the family’s judge because I would take on arguments and apply logic to them and just like that it they were solved.

Another fast forward; no pun intended, I learned that Computer Science was the what I had been looking for all along. I was lucky my family was gifted a computer by a young adults Christian group from Australia. It was on this computer that I spent my days breaking and learning new things. Then, I got introduced to the internet and was mind-blown, then I learned about Facebook. Best thing at that time, I’m not sure about now.

I could go on and on but in the interest of time and my promise to keep this summarized, let’s stop here. Basically, I’m passionate about Computer Science and I would love to make a positive contribution to the human race through technology.

Thank you for reading my blog.

The post Self introduction appeared first on Velt.

From the blog CS@Worcester Archives - Velt by byaruhangamoses4 and used with permission of the author. All other rights reserved by the author.

For my first blog post on these patterns, I wanted to start with Your First Language. I have only been exposed to a handful of languages since starting my computer science journey. And though I have honed my skills somewhat in those languages, I am by no means a master at them. I can relate to the problem in the pattern, so I was interested in what it had to say. This pattern addresses those who are looking to start learning a programming language or those who feel their skills are not up to par with what a job is looking for. Selecting your first language could influence your future career, so it is important to choose a language wisely. The solution suggests choosing a language based on those around you, for example, an expert in the subject that can mentor you. Becoming proficient in a language involves building up knowledge through reading specifications and solving problems.

One of my main takeaways was to choose a language based on the people you know, specifically an expert. The other takeaway was to look at the community built around a language and see if you want to belong to that community. I found those two points to be the largest deciding factors when it comes to picking up a new language. For me, I would consider my first language to be Java since that was the first language that I learned at school. There were plenty of professors that aided in my learning process and the community surrounding Java is extensive. It would only make sense for me to continue learning about java and solving sample solutions until I consider myself fluent. I think starting a professional career is a bit daunting, but what the pattern explains makes a lot of sense. The only way to become proficient at a language is to do a lot of reading and try out problems myself. A work environment where you can call on a more experienced team member is also beneficial when it comes to learning a language. That being said, I don’t think there is anything I disagree with anything mentioned in the pattern, it more so emphasizes what it means to be a good learner.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

The pattern I decided to read is titled “Concrete Skills” from chapter 2 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern starts off by discussing how hiring managers have no incentive to hire someone who can not directly contribute to a team’s workload. Hoover and Oshineye ask the following rhetorical question from a recruiters point of view: “If we hire you today, what can you do on Monday morning that will benefit us?”. In short, the solution to this problem is to develop and maintain some concrete skills. We learn that with time we will become less dependent on our concrete skills and get hired through the reputation we have garnered from notable projects. This pattern ends by giving the reader a recommendation on how they can begin developing some concrete skills.

The thing I found most interesting from the reading is that at some point in my journey I will become less dependent on my concrete skills. My portfolio and “deeper qualities” will be what matter more. This was interesting to me because in a section that stresses the importance of learning concrete skills in the beginning of my professional journey, I am still getting a message that soft skills are important. This shows me how there is an important balance of maintaining the hard skills I’ve learned in addition to being a team player, having good communication, being empathetic and having many other traits that fall under the soft skills category.

Overall, there isn’t anything that stands out that I strongly disagree with in the reading. As far as how this pattern has caused me to change the way I think, I would say that it has emphasized the importance of regularly updating my resume with technical skills since this is something many hiring managers focus on. Since there are plenty of skills I’ve been developing in school this past year, I took the advice from this pattern to heart and almost immediately started jotting down the skills I have started developing. I also started looking into CVs online for inspiration of concrete skills I want to develop and to add to my own resume.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.