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.