The last sprint of the semester.  This semester flew by, but I am proud to say that we finally fixed our issue! Turns out we focused so much on how to fix it that we didn’t even realize it was totally out of our hands.  We ended up asking for help, and the openMRS developers got right back and said that they will need to contact someone in order to make this change.  I learned something very important from this sprint.  I learned that you shouldn’t stay stuck for too long without asking for professional help.  We broke down the whole issue and knew where the problem was happening, but we just didn’t have the access to the code to change it.  This must happen all the time in the professional world.  Next time I have any type of coding bug to fix, I will break down the problem (like we did), but I will make sure to ask someone for assistance way sooner.  If we never asked for help, we would have never resolved this issue.  Our last and final thing to do for the semester is put together our final presentation.  I look forward to sharing with everyone!

From the blog CS@Worcester – Alex's Comp Sci Blog by alexsblog13 and used with permission of the author. All other rights reserved by the author.

Chapter 11 of The Software Craftsman gives great advice on what companies should NOT do when interviewing for new developers.  Many great developers will end up not going with certain companies because of a horrible interview experience.  Individuals conducting interviews need to make sure to not scare away great potential workers by having bad interviewing tactics.  The chapter discusses that interviews should not be a test to see how well you know the answer to close ended and technical problems.  Anyone can simply memorize and study common interview questions to be sure to come across as a good candidate for the job. However, this chapter makes a great point that just because you know the technical/text-book answers doesn’t mean that you are the best candidate for the job.  I personally would rather have a co-worker that is passionate and wiling to learn, rather then someone who knows “everything”.  A passionate coder is the coder that will be great.  A coder who knows everything may seem really good and all, but they also may lack that passion and drive that someone else might have.

Chapter 12 talks about how low morale can negatively impact a workplace in more ways then you may think.  This chapter discusses that having passion will go long ways in the overall outcome of an organization.  I agree with the whole idea of this chapter, and I have actually personally experienced this.  The experience I had wasn’t at my computer science internship but it was when I used to work at an ice cream shop.  Most of the girls I worked with there, along with myself, would want to make nice looking ice cream cones and sundaes for the customers.  However, there was one girl that was always extremely sloppy.  The ice cream would be dripping everywhere, and the customers were never happy with her work.  This was a perfect example of someone who had no passion whatsoever.  She was just there to simply get paid, and she did the bare minimum amount of work possible to get the paycheck.  Her lack of effort negatively impacted all of us.  We would have to clean up after her, and deal with the problems she caused with the customers which brought down everyones motivation and attitude.  My experience relates to what this chapter talks about.  The chapter talks about how being a motivated developer will motivate other developers to work hard.  Have one person bringing everyone down with no passion or willing to try their best is not a good thing in any type of work place.

From the blog CS@Worcester – Alex's Comp Sci Blog by alexsblog13 and used with permission of the author. All other rights reserved by the author.

Chapter 9 is the first chapter of Part II of The Software Craftsman.  This chapter discusses what companies can do to attract great developers during the recruitment process.  Many companies will post a traditional job description along with the criteria that you should have ____ years of experience.  The chapter states that companies may be pushing away great developers that would be extremely beneficial to the company by their recruitment process.  One point that really stuck out to me is that many jobs require so many years of developer experience.  I have always thought this truly made no sense.  A second year software developer could be much better and have more skills then a software developer with 12 years of experience.  Seniority is not a good way to judge the quality of a worker.  Another good point the author talked about is looking for a developer with the passion.  Having a passion for something will mean that you are giving it your all.  A developer who loves what they do and wants to succeed will always be better then someone who just does enough to get the paycheck.  Overall, I enjoyed reading this chapter.  It was interesting to get some tips on how companies should view you as a developer, rather then how you should view yourself like in the previous chapters.

Chapter 10 gave advice on the interview process for both the companies and the candidates.  The author stresses that an interview shouldn’t be an integration of the candidate, but instead a business negotiation where both parties reach mutually beneficial agreements.  I really enjoyed and agreed with the whole idea of this chapter.  I am always extremely nervous for interviews and feel like they are testing my every word to make sure I say the right thing.  However, it really shouldn’t be like that.  An interview,  on the side of the interviewer, should be a way to get to know your possible soon to be employee and see if they are a right fit for the job.  If you give a formal “by the book” interview, someone coming in is going to answer like a robot and say what you want to hear.  I really hate how so many companies expect you to have the perfect answers to every question.  If I ever personally give an interview, I will make sure to make the candidate feel comfortable and like they don’t have to speak like they are reading from a textbook.  Another good point the chapter made is that when giving an interview you should be more focused on the candidate’s passion, willing to work, and previous accomplishments then what skills they currently have.  Someone who is enthusiastic about learning new things will be able to pick up quick on any skill they may not have going into the job. When I first got accepted to my internship as a software engineer, I was only a freshman and honestly had minimum technical skills.  I was honest with the interviewer, but I also was clear that I was willing to put the time and effort into learning anything that I needed to.  I ended up getting the job, even though I wasn’t the best at everything.  Now I can say, as a senior that I know so much more then I did during my interview as a freshman.  I am willing to keep this mindset throughout future jobs.

From the blog CS@Worcester – Alex's Comp Sci Blog by alexsblog13 and used with permission of the author. All other rights reserved by the author.