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.

Chapter 7 of The Software Craftsman discusses some important technical practices.  It also discusses the topics of pragmatism and accountability, as well as tries to help developers understand these practices.  Some of the practices that this chapter talks about is, automated testing, test driven development (TDD), continuous integration, pair programming, and refactoring.  Something that was interesting about this chapter was that it discussed how as a developer you need to figure out what practice you personally are going to adopt.  You don’t need to adopt every single practice, and that’s very important to remember. You need to figure out what works for you individually.  Of course following these practices will be beneficial to overall cleaner code.  However, that doesn’t mean that following all of them is the best way to do things.  I learned that keeping yourself focused on the business value will help to make sure things go smoothly for you.  Overall, this chapter wasn’t one of my favorite but it had some useful information.

Chapter 8 of The Software Craftsman is about the long road of your own career and your own happiness/success.  The author discusses how you need to focus on your own goals and your own path as a developer.  If you aren’t happy with your current status then it’s your own responsibility to change that.  You need to be willing to try new things and create new opportunities for yourself.  Keeping up with the latest technologies is very important and making sure you are at the height of your success.  However, at the end of the day you need to focus on your own goals.  As a developer you should never settle just because you are at a certain spot in your life.  You need to keep reaching to your goals and work hard to get there.

I really enjoyed reading chapter 8 of this book.  It made me think about my own personal goals in life.  I want to get to a place in my career where I can be a confident and independent developer.  Right now I tend to question and second guess a lot of the work I do.  My goal is to have enough technical knowledge and self confidence to be proud in the work I do.  This chapter reminded me how important it is to keep up with technology to make sure you are producing the best work possible.  Overall, I liked this chapter and I could tell that the author felt passionate about the things he said.  Your career is your own journey and you should always remember to make sure it’s exactly what you want.

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.

This sprint we have all been working on one issue together as a team.  Our biggest challenge so far was actually simply finding the file in the huge code base.  We looked everywhere for this one file and had no luck.  I decided to try a different tactic then to just search the full code base for keywords.  I looked at previous solved issues on GitHub for a similar problem.  I think that using GitHub as a resource was the best decision I made.  I was able to find the file within a half hour.  I will now use this method for finding files in the future.  A big obstacle we are currently stuck on is that the file is actually not in the openMRS src code on GitHub.  It would be such an easy fix to make a small change to the file, but it is part of npm and AMPATH has no access to it.  The next steps I am going to take is asking some of the other openMRS developers for some guidance on what exactly we should do.

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.