Pattern 1: Your First Language

I decided to dive in with one of the first patterns of the selection, “Your First Language”. I chose this one because I was curious about the tips that the author would give individuals trying to decide on a first language, as well as to see if any of the tips translated for someone like myself, who is trying to branch out into learning more and more languages. This pattern breaks down the steps to choosing a first language and gives several factors for why you should potentially choose a language but makes sure that it is clear that these are tips and not the only reasons for selecting a first language. After picking the first language, the pattern lays out some tips for how to actually learn the new language. The pattern also lays out a simple means of learning more languages down the line and why someone should pick a particular different language.

I’m glad that I chose this pattern because I’m currently in a position where I am forced to learn a new language for a job I will be starting after graduation. The language that my new position almost entirely uses is C++ and I have absolutely no experience in it. The procrastination is killing me as my “native tongue” as the pattern describes it, is Java. Java is what I always try to use to solve problems even if I’m being asked to write in a language like javascript, python, etc. I always revert back to the concepts I’ve learned throughout college almost exclusively using Java. Learning C++ is going to be something that I must do and will attack throughout the next few months before starting my job. The opening to the article was also very helpful in relieving the stress slightly as it talks about how when you start your first job, you’re not expected to be an expert in ANYTHING. I’ve learned that through my last two internships where even though they were both Java based, they used entirely different frameworks and almost everything that isn’t core Java syntax, required an entirely different skill set and understanding.

The only part of the pattern that you could argue I disagree with, is the complete focus on your choice being driven by potential physical mentors. With the internet and communities within the internet, it is relatively easy to find mentors online who are more than happy to answer any of your questions in understanding a new concept or a language for that matter. Overall, I found this pattern VERY useful!

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

MINIX3: Scheduler Research I

Before I can edit the scheduling algorithm for my independent study, I need to understand the intricacies of how it works. That’s what I tasked myself with this past week, and as it turns out, there’s a lot to know.

MINIX is structured in 4 layers. Top to bottom, they are the User Processes layer, the System Server Process layer, the Device Drivers layer, and finally the Kernel. Originally, the scheduler was built into the Kernel (like you would find on a traditional operating system, I would assume), however an independent project by Björn Patrick Swift moved the vast majority of the scheduling handling into the user space — specifically the System Server Process layer. This change allowed for a much more flexible scheduler that can be easily modified without worrying about large impactful (and potentially damaging) changes to the rest of the Kernel. On top of this, it allows for multiple user mode scheduling policies to be in place at the same time. The current user mode implementation of the scheduler is an event-driven scheduler, which largely sits idle and waits for a request from the Kernel. In order for this the happen, though, the kernel needs a scheduling implementation as well.

The Kernel scheduling implementation runs in a round-robin style, and chooses the highest priority process from a series of n priority queues. When a process in a priority queue runs out of quantum (or time left for it to be executed, which is predefined), it triggers the process’ RTS_NO_QUANTUM flag. This is what dequeues the process and marks it so it may no longer be run. The two system library routines exposed to user mode from the Kernel are sys_schedctl and sys_schedule. sys_schedctl is called by a user mode scheduler in order to take over the scheduling for a process. sys_schedule is then used by a scheduler to move the process to different priority queues or give it different quantum, based on its policy. It can also be used on currently running processes for the same functionality.

Having a minimal Kernel scheduler is important because without it some processes would run out of quantum during system startup, before the user mode scheduler has even started. Not only this, but in the event that the user mode scheduler crashes, it could be possible for the Kernel to take over scheduling until the user mode scheduler is restarted (I’m unsure if this is currently implemented or not, though). There are plenty of benefits to having a simple, inefficient Kernel implementation whilst placing the majority of the workload on user mode schedulers most of the time.

The report I linked previously that details all of the workings of the scheduler is fairly long (20 pages), so I’m going to continue reading it and taking notes on it. I don’t want each one of these blog posts to get too long and wordy, so I’ll make a few posts (all of them this coming week) on this topic, each a continuation of the last.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Concrete Skills|| S.S. 4

Sams Ships (4)On this weekly individual apprenticeship pattern post, I’m going to discuss Concrete Skills. This pattern is pretty much explained with someone wanting to be a part of a good development team but they have not yet built up their development experience. My reaction to this pattern is that this would be a comforting one for students in college or upcoming graduates (and even entry-level developers) to feel a little less pressure on bridging the gap between starting fresh and being an experienced developer.

Concrete skills are interesting to me because you can have all the knowledge and information but being able to take what you know and apply it to something is different. The main takeaway I got from this pattern is to learn things that you will be able to apply even when you are still in the on-boarding phase. This has caused my to change the way I think about my intended profession because of course I want to get started and involved in projects right away. I like the feeling of being able to help people out when I have down time at my current opportunity just because I get to sharpen up a skill in one area instead of just sitting there.

A good question proposed in the pattern stood out to me, “If we hire you today, what can you do on Monday morning that will benefit us?” It’s interesting to imagine yourself in the role of a hiring manager; they have to hope to understand you well enough so that they can trust that you will be able to do your job and have an impact on the company. This thought makes me want to continue what I’ve been doing in terms of pursuing different learning experiences that will help me become a stronger developer not only knowledge-wise but skills-wise.

I do not disagree with something in the patterns as it gave me something new to think about and look forward to using in my future. I found it useful to hear their advice on considering looking at other CVs as references of what we would like to put on our potential list of skills.

 

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

The Value of “Toy” Programs

This Apprenticeship pattern “Breakable Toys” highlights the importance of creating an environment to experiment with important software development concepts, while affording us the opportunity to fail at no risk to ourselves.  The philosophy behind this apprenticeship pattern is the best way to gain meaningful experience is to practice and fail and learn from our mistakes.

In the context of software engineering, that means to create “breakable toy” programs that we can use to hone our skill set, while not having the pressure of success in the workplace get in the way of the learning process. We can experiment at our own pace, and practice the concepts that are integral to our careers in an environment where we are entirely in control.

What stands out to me the most about this pattern is the unique solution the authors suggest; create a “toy” program that is meaningful to you that you will use. Sure the goal is to practice the skills that will make us successful in our careers, but the authors suggest that by creating a program that we will actually have fun making will add to the motivation of the creative process.

The authors provide a few examples of people who create their own wikis to learn fundamental concepts of front end development and web design like HTML or REST, or those who make games when they learn different languages to cement the fundamental concepts. The emphasis is on creating a safe environment to test and experiment with different tools while still having fun and fostering creativity.

The main point I took away from this pattern is the importance of creating a safe environment to practice my craft, without having to worry about the scope or the severity of the task, while at the same time being intrinsically motivated to create something of personal value. Real learning and experience isn’t something that can be gotten on the first pass or on the fly; trial by error by far is the best teacher. After all, it would be illogical to expect a musician to perform in front of an audience without rehearsing first.

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

Your First Language

This week I am reviewing another pattern from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. For this week’s pattern I decided to go with the chapter “Your First Language”.  The context of this chapter is you have a shallow understanding of one or two different programming languages. This chapter grabbed my attention because while I have been in school for four years learning software development, I still feel that I only have a shallow understanding of a few different languages (in this case Java, C, and python, but Java is definitely my strong-suit). I feel that from the perspective of the classroom we know a decent amount about our languages, but from a real-world point of view, we only know the proverbial “tip of the iceberg” meaning that we still have much  more to learn about our languages. The problem presented by the book is that we feel that we need to be masters at our first programming language in order to be a good programmer and a purposeful part of your team at work. While the book says that you should not stress over the fact that you only know one programming language, they also point out that most jobs require that you know at least one programming language inside and out to get the job. This is a “catch 22” because jobs expect you to be masters in a language and be extremely proficient but at the same time they understand that you likely have little to no experience with your language because all you have had experience with is programming assignments in school. This kind of puts us at the disadvantage because we are expected to be masters at our trade to get an entry level position at a company we  may not be at forever. The solution proposed by the book is to improve your learning of your first language. How does the book propose this? By having actual problems to solve with your programming language skills and knowledge. I think this is important because using your skills to learn how to solve actual problems helps you retain your programming language skills and makes you a better programmer.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – The Long Road

The apprenticeship pattern “The Long Road” is a pattern for those aspiring to become master software craftsmen. For these people, the path that should be taken differs from what is expected from them. Rather than trying to climb the wealth ladder by taking every promotion you can get and enter a less programming-oriented role, you should continue walking on “The Long Road” by focusing on learning and long-term growth.

This pattern is really interesting because it’s a path that focuses entirely on honing your craft rather than salary. I’m sure most people would jump at every opportunity that offered them more money, regardless of what the job actually entailed, so long as they considered it a “step up.” This is a different, legitimate path to take, but it won’t necessarily be the same path as the one to master software craftsmanship. It’s entirely possible that in the long term, focusing on learning and long-term growth would get you “further” down the path of mastering software craftsmanship.

I’m still not entirely sure if it’s the path that I want to take, as it’s difficult to pass up short-term gains. It’s easy to say that you want to walk the long road, but when facing a fork in the road it may be hard to continue. Although, I’ve heard many stories of people who took a higher paying job only to end up regretting it due to lack of growth, poor work-life balance, boring work, etc. That being said, I don’t think that I’ve experienced the industry enough to decide what path to walk. So it’s difficult to say whether I agree or disagree with the pattern, but focusing on improving yourself would likely not lead you down the wrong path.

Imagining strange roles that you could be in 10, 20, 30, or 40 years from now and what you did to end up at those points is an interesting exercise that I think would help people figure out what they want to do in life. Obviously it’s not necessarily guaranteed that you would have a breakthrough from just thinking about it, but you might realize that you don’t like the path that you’re on right now or maybe your dream role has an entirely different starting point from where you are now.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

IndividualApprenticeship Patterns – Draw Your Own Map

Draw you own map was the topic i picked for this week. I really enjoyed reading this pattern. It gives me the understanding of how to beat or overcome the huddles of learning new stuff and become very good at what we do or love.

From the reading, i also got to know, in order to be happy at your work place or your next career. You will have to pick a field you enjoy which most of my time i will be spending. The stories that Desi and Chris’s gave, give me the knowledge that planing your career at an early stage helps a lot. It makes you know what to expect and also what you want. Also from their stories, they could have prevented ending up in a a job they dislike by getting more info or doing more research about their next career or job. In case you did your research and landed to the job and later found out that it is not good for you. It is not late to change or learn new stuff. The pattern also gives ways on how to draw you own map. To me, it was very easy to understand and also felt it is the best way. The actions taken when drawing the map will definitely land you to the dream job you are looking for.

I really like this pattern(draw your own map. It has showed me a lot on how to really design my map in terms of my next career or job. it has also open my mind not just on my field of studies after graduating but also in life in general. I realized this technique that book showed, applies to everything. Not only for programmers or computer science students. I even made my own map which was really fun. I add four desirable jobs i will want to have for the next six years to come. On map diagram, about the desirable jobs, i included jobs no related to my field. Added fields like being a chef and nurse. Also added things i should be learning, whether things not related to my field or new programming languages.

From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.

B4: Create Feedback Loops

          The “Create Feedback Loops” pattern is seen as a way to gain a better understanding of yourself without completely suffering from a blind sense of skill. The book continues on to say that self-assessment is limited to the abilities you have which makes it narrow minded if you don’t have many skills to start with. The best way to cope with this issue is to create a system where you can receive feedback or external data on your performance. It allows a more conscious take on your weak points as seen by other people which in turn will create a much more detailed self-assessment for yourself. The book then shows the importance of feedback in various environments such as job applications where applicants can be turned down, but this can become a learning experience as well. Understanding why one was turned down for a job also is a type of feedback that can show you different aspects of your character that you didn’t see. Finding a specific task to do is the hardest part because you must find something you can measure. Once this is done, compare how that task is affected by your work and understand how your actions are affecting it.

          I found the idea of creating different feedback loops with various people very useful and interesting. The idea of getting feedback from multiple people in multiple groups of your life could be very valuable information. I personally feel that there are aspects of work that meld into our personal lives and until someone else points them out, they seem second nature to us. This idea of taking others advice even when its not work related can cause interesting changes in how you tackle problems and view the situation. I found that listening to these valuable inputs is important but it’s just as important to understand which advice to follow as not all of them are good. I disagree with the idea that self-assessment is only limited to someone’s abilities. I think that even when you have little skill, you can accurately create an ideal image of what you want using facilities like the internet to expand on what you need to work on.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Concrete Skills

This week’s blog is about Concrete Skills from the Apprenticeship Patterns book. It talks about what to do when you are looking for a role on a talented team that will provide you with better practice and enhances your learning, but sometimes these teams do not want to be bothered. Sometimes, having a new hire means you are going to be teaching them again from the beginning and these new hires do not offer anything to the company or team yet since they do not know how things work. This section of the book talks about how to deal with it.

In this section, they talked about concrete skills. They said that it is important to have some concrete skills so that you will be trusted to contribute indirectly until you start to gain their trust. It will help reassure your team members that you can be put to good use rather than being a burden that they have to babysit. They added skills like writing build files in various languages, basic web design, JavaScript, and knowing some standard libraries in the language of choice.

I find it interesting that the book suggests that you look at the CVs of the people whose skills you respect and identify the skills noted on the CV and determine which of these skills would be useful on the team that you want to join. Implement these skills on your own project, make sure that you know how to do them and how they work.

I completely agree with this pattern. I think knowing some concrete skills will come a long way when looking for a job or when starting one. You can’t always rely on your team to teach you stuff and they can’t also just ask you to do things that you have never done before right away since they are also working on stuff and not just there to babysit you. They will expect you to work and you have to prove to them that you are capable of being on the team. That’s why I think having concrete skills is good.

 

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

The White Belt

The white belt as an apprenticeship pattern is what it sounds like. You are at the beginning of your journey and have a deep understanding of your first language. The problem arises when you are struggling to learn new material and it is harder to piece things together than when you started learning your first programming language. The author relates the solution back to Star Wars quoting Yoda, “You must unlearn what you have learned”. By doing so, this accelerates the learning process because you don’t try to relate things back to your current language but instead connect neurons together when trying to understand the new concepts you are learning.

I agree with the many things the author taught in this apprenticeship pattern. That too is how I learn new tools and technologies on my own but on the other hand, I always try to relate it back to my strongest, most knowledgeable language, and see if there are similar concepts and if there are ways to carry out a task more efficiently.

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.