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.

Chapter 5 of The Software Craftsman basically talks about dealing with pressure and deadlines as a professional and not always being the “hero”.  As a software developer you aren’t a superhero and you don’t need to say yes to everything asked of you.  In fact, a huge point this chapter made was learning to say “no”.  This topic of saying “no” is something that we read about in the last book, The Clean Coder.  Although saying “no” may seem to be rude or unprofessional, it is actually the professional thing to do.  In the field of computer science, there is pretty much always something that needs to get done.  This doesn’t mean that you always need to be the one to do everything.  It is great to work to your full potential and get a lot done, but when you start saying you’ll do things you don’t have the time to do, it can get bad quick.  It is better to have good quality work rather then quantity.  Overall, I enjoyed reading this chapter.  Even though we already learned about this topic from the other book, I enjoyed reading the author’s personal stories on this matter.  He really went through hell trying to be the hero all the time, but luckily he came to his senses.

Chapter 6 discussed the issues with low quality software.  The author basically talks about how keeping up with the code base is very important.  Working code can easily turn into low quality and very bad code.  He discusses how many software developers will ignore the legacy code because they don’t want to deal with it.  However, that is a terrible attitude to have.  Putting off this problem is only going to create a bigger problem later on.  It is a much better idea to update the legacy code piece by piece so eventually the code will be working again.  This author made some very good points about working software and the attitude you should have towards it.  Personally, I would much rather just ignore legacy code and do something different.  However, this chapter made it clear that ignoring the problem is never the answer.  Keeping up with the code base and updating it with unit tests can make a huge impact on the overall product.  No one likes non-working low quality software.  From now on I will deal with situations like this piece by piece rather then facing a huge problem all at once.

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.

Sprint 4 of the semester got cut a little short because of spring break.  While I was in Cancun I can honestly say I was not too focused on the project.  Before the break, we were assigned our first issue, but none of us were able to reproduce the bug.  A few of my team members reached out to the AMPATH developers and we were able to get assigned a new issue.  We actually all had to take a step back and re-fork our whole project due to it being out of date.  When I did that, something got messed up because I currently cannot get the test server to go online.  I plan to get my personal issue resolved with the server within a few days.  Our new issue seems pretty simple and straight forward.  I look forward to working with my team to start fixing more and more actual issues with the system.  Hopefully this sprint will be much more productive because we will have a full sprint with no interruptions.

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 3 of The Software Craftsman started off by discussing what exactly software craftsmanship is.  It gave the definition of software craftsmanship from a view different points of views such as; wikipedia, the authors personal definition, and a shorter more clean cut definition.  The chapter talked about how it is all about being professional when developing software which is something we have already previously learned in this class.  An interesting thing that this chapter discussed that I haven’t seen too much in previous chapters of this book or even in the whole Clean Coder book, was the history.  It gave in-depth information of the software craftsmanship movement and all the history you could possibly know behind it.  It was interesting to me to learn about historical details on where exactly this idea of software craftsmanship stemmed from.  Finally, the chapter covered the software craftsmanship manifesto.  The manifesto consisted of 4 major points:

1. Not only working software, but also well-crafted software.
2. Not only responding to change, but also steadily adding value.
3. Not only individuals and interactions, but also a community of professionals.
4. Not only customer collaboration, but also productive partnerships.

My favorite of the four was, number 1, “Not only working software, but also well-crafted software”.  This a very important point that every software developer needs to be aware of.  Just because a program may work, doesn’t mean it is crafted the way it should be.

Chapter 4  was about the attitude that a software craftsman should always have.  The chapter went through and mainly gave tips on how to improve yourself as a software craftsman.  Some of the advice that I personally took a lot from is always keeping our self up to date, practicing and balancing your work and personal life.  The topics of keeping yourself up to date and practicing are two things that I have seen a lot throughout this course.  It is clear that these two things are extremely important to any professional, but especially one dealing with technology.  Technology is advancing everyday and it is each individuals responsibility to keep up with it throughout their career.  Work-life balance is something that nearly everyone has to deal with at some point.  It is crucial for me as a soon-to-be software developer to start practicing different techniques to find the best work-life balance that works for me.  This chapter mentions a technique called the Pomodoro Technique.  This technique basically says that you should separate your work into 25 minute intervals.  It is proven that working in small intervals can maximize your creativity.  I am willing to give this technique a shot, even though I am not too confident it will work well for me.  I tend to be able to focus for a long period of time when I get into a groove.  If I was forced to stop myself when 25 minutes is up, it may set me back.  However, it can’t hurt to try.  Who knows I may find out that this is perfect for me.

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.

A huge point that Chapter 1 of The Software Craftsman discusses is what “seniority” is in a company and how it’s measured incorrectly a lot of the time in the workplace.  The chapter states, “There is a huge difference between having 10 years experience, and having 1 year experience repeated 10 times”.  That quote stuck out to me and made me think how true that is.  Just because you have worked somewhere a long time doesn’t mean that you have more knowledge then the person sitting next to you who worked half the time you have at that company.  The other main point this chapter talked about is something that I actually think about all the time. It talked about how developers should be able to keep up with the modern ways of working.  As a developer you need to keep up with the modern tools and equipment.  If you’re doctor was using medicine from 1990, and not upgrading his practices, you would be concerned.  That is how you should think as a software developer!

Chapter 2 discusses what it means to be agile, and how to solve the problems that come along with that with software craftsmanship.  The chapter stresses how you NEED to have a good balance between process-oriented and technical-oriented disciplines and methodologies.  It also talks about how you need to be able to work with your team as a whole.  I agree with this chapter that although being agile can be beenificial, it can also cause a lot of problems.  This is where you need to take your craftsmanship and apply it to help fix those problems.  Becoming more agile in computer science is a “game changer” as the chapter stated.  I now see how being agile in the workplace is very important and can change a lot.  I wish to take this knowledge and hopefully become more agile.

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 was the most successful yet.  I think we are all starting to really get the hang of things in our group and daily scrum meetings each week.  We are now at the point where we have been assigned issues from AMPATH and are diving head first into the openMRS code.  My big obstacle this week was trying to figure out why it was saying I had the wrong login credentials for the AMPATH standalone server.  I realized half way through the sprint that I was stuck on the issue for too long, so I decided to go to my teammates for help.  In a few days, one of my team members actually found the solution to the issue.  All I had to do was switch my web browser to google chrome and download a plugin I was missing.  The lesson I am going to take from this sprint is to not spend too much time getting stuck on something without asking for help.  It is always a good idea to try and figure out a problem by yourself but if it’s coming to the point where it is taking you a little too much time, you should always ask for help.  This semester is pretty short, so I don’t want to waste any time that I could be focusing on something else.  This next sprint I plan to get more done then I did this sprint.  I am not completely satisfied with the amount of work I accomplished this sprint and wish to improve.

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.