In Sprint 6 even though we were close to fixing the issue we had assigned ourselves, we chose not to take on additional tasks due to it being the final sprint. We continued to work on APTS-296 and were able to run a fixed instance of the issue on our computers. Unfortunately, we realized that our solution was flawed. When we were ready to submit a pull request we realized that the developers were not going to accept changes we had made to the npm module directory. This was not part of the original repo and cannot be cloned from GitHub by other users. Once we knew we were going to need to some guidance we reached out to the developers on Slack. Basically they said the property that needed to be updated was part of the schema that gets implemented when users run their npm install commands. Therefore, we were directed to reach out on JIRA and mention a particular developer to help fix the issue. Once we did this the developer implemented the change we requested and testing feedback was posted on JIRA. Within a couple of days the ticket was successfully closed out. While we may not have been able to get a pull request submitted we did directly track this issue and ensure it was solved. One lesson to take away would definitely be to ask questions early on. Instead of struggling to look for a solution and work on the issue for a whole sprint, we could have reached out to the developers and found the full solution was beyond our capabilities. If we were to have more sprints I believe we would adjust our velocity to taking on 2-3 issues in one sprint. We’ve gotten pretty comfortable navigating the code base so we would be able to track the location of issues quicker. We would also communicate with the developers more to ensure speedier solutions. From a personal perspective I don’t think I utilized the knowledge and help from the AMPATH developers enough. I saw it as bothersome to them and tried to avoid it at all cost. In reality they were quick to respond, knew exactly what to do, and usually it wasn’t all that difficult. Lesson learned; don’t be afraid to ask for help.
Chapter 15 covers the topic of pragmatic craftsmanship and what the term actually means. He starts off by remind the reader that cheap and fast code that lacks quality will always become expensive and slow to change over time. Quality is always expected at the end result and the author claims that quality does not have to be compromised by a team of software craftsmen. By practicing Extreme Programming and Agile methods testing, integration, and deployment are done daily with working software every step of the way. The initial learning curve is what causes teams to stray from this way of development. Instead companies need to hire craftsmen so that the best quality and development environment can be achieved and passed on to junior developers. The author goes on to talk about other development staples like TDD and refactoring and implementing them correctly. He also advises that when working closely with a business the team should be able to visualize the businesses goals quickly and get feedback as to always pleasing the customer. Projects are never about an individual and code should always be kept small, testable, and easy to understand while constantly doing the job intended. Two main rules the author mentions regarding program design are to minimize duplication and maximize clarity. The author concludes with saying that a craftsman masters their practice and provides quality at a good value. Quality is always expected regardless of the situation and to master the practices to deliver quality, one must be pragmatic.
After reading chapter 15 there is definitely some good advice however the chapters are starting to become repetitive. While the main message was delivering proper valued quality, many suggestions and topics such as TDD and refactoring are being repeated. The best lesson I took away was to never have the mind set for a project of quick and cheap. Customers always expect quality and by practicing the right methodologies you can always guarantee it. Aside from that the two design principles of minimizing duplication and maximizing clarity should be kept in mind for any programmer.
Chapter 16 covers the topic of a career as a software craftsman. The author outlines what being a software craftsman really means. Above all you need passion. The world is becoming more and more reliant on software and craftsmen need to be able to solve problems and be curious aside from just writing code. The author then suggests climbing the ladder through the progression of a career. Those who switch to managerial roles have switched ladders and should view it as a career change. Taking a job as a developer should be seen as more than just an occupation and really a lifestyle commitment. Each job should align with career goals and progression. As the author says a craftsman is committed to excellence and the role they are playing in the evolution of society.
After reading chapter 16, it was mainly a motivating summary of all the lessons learned throughout the book. The only part I still don’t fully agree with is limiting your job search to only a few companies. In reality people have families to provide for and bills to pay. While I do not condone staying in a job you are unhappy with, sometimes you just can’t land the dream job and may need to settle or stay where you are for a little longer. This especially applies to junior developers who are still just trying to gain exposure and experience in the field. In conclusion I think this book was well written and provided some great guidance for a software developer at any stage in their career. That being said I did find many chapters to be repetitive and many lessons to be similar to ones in Clean Coder.
Chapter 13 covers the topic of creating a culture of learning in the workplace. The author insists the culture starts with the senior personnel who are viewed as role models. If they are excited about being at work, it will rub off on other team members. The author also advises to give developers the freedom to learn. It leads to happy developers, more innovation, and an overall better work environment. He then goes on to a lengthy list of topics developers can do to create this better work environment:
Start a book club
Have tech lunches
Organize group discussions
Switch Projects for “x” time
Conduct group code review
The author then goes on to give advice to developers trying to create a culture of learning. He reminds the reader that you can’t change everyone with your enthusiasm and that’s okay. If you can help other developers re-discover their passion for what they do, it will still have a positive impact on the workplace. Some of his advice is as follows:
Be an example
Focus on those who care
Don’t force participation
Avoid consensus delays
Don’t ask for authorization
Don’t complicate/Make excuses
Establish a rhythm
The author concludes by saying that the culture of learning is everyone’s job. It can also be cheap and easy as passionate developers will naturally create this kind of environment.
After reading chapter 13 I think there’s a lot of really good advice to take away. I definitely agree with the overall message that having a culture of learning is imperative to any development team. Without it, developer’s skills get outdated and team innovation will be on the decline. Software development is an ever changing field and creating a culture of learning in the workplace is one way to keep up. There were only a couple of suggestions from the author that I didn’t fully agree with. The first was encouraging pet projects in the work place. While I think it’d be okay to have a lunch discussion with a co-worker about a side project it seems a little unprofessional to me to dedicate any of the work day towards it. If it’s not a topic that directly benefits your skills at work I would especially save it for outside work. I wouldn’t want to give any impression my side work was more important than my company’s. Secondly I didn’t agree with the advice to not ask for authorization. If you’re going to conduct training in the workplace it’s always a safe bet to run it by the manager. Even if you don’t formally ask permission, maybe just invite the manager to stop by or participate. In summary, I think the author’s advice and suggestions promoting a culture of learning are really good.
Chapter 14 covers the topic of driving technical changes. More specifically how to convince skeptics to be more open to new ideas. First the author breaks down these skeptics into types that someone may encounter. They include types like “The Uninformed”, “The Irrational”, and “The Boss.” Once you’ve identified the type/s you may need to convince you need to be prepared for technical conversation and heated debates. To actually get the ball rolling towards a change you see fit the author provides an outline: establish trust, gain expertise, lead by example, choose your battles, iterate, inspect, and adapt. He also suggests not letting fear and incompetence get in the way of doing what is right to implement a positive change. As far as getting permission from the boss he says not to worry about that. They don’t care about the low level implementation, they just want solid results. As far as convincing a team to adopt a new idea, you should be proficient and able to teach the skeptics. If you don’t have a grasp on the subject it will come off as difficult and a waste of time. The author concludes with the idea that implementing changes is the responsibility of a true software craftsman. Whatever is best for the project and customer is what should be implemented. In order to adapt to these changes, a craftsman needs to know how to communicate with everyone and show the real value in the change they want to implement.
After reading chapter 14 there are definitely things to keep in mind for a future career in software development. I do think this chapter is aimed at much more experienced developers as it would be extremely difficult for a junior developer to convince a team to make a technical change without the experience to back up their reasoning. That being said it is of the upmost importance to satisfy the customers and anyone who can see a beneficial change to make that happen should try to implement it. I did not agree with the idea of not informing the boss once again of a technical decision. A good manager will care about the team and a good team will be transparent to their manager especially if a technical change is made. As I mentioned for chapter 13, I don’t see it being necessary to ask permission. Something like “We are implementing TDD because we can benefit as a team in this way” should suffice. Aside from that, the chapter was useful and reminds the reader of responsibility and accountability.
Chapter 11 covers the topic of interview anti-patterns. Basically it covers what to avoid as someone giving an interview to attract true software craftsman. The author first suggests to avoid intimidating the candidate as well as to avoid trying to seem smarter than them. An interviewer should be humble and treat the interview as a professional and technical conversation. Relying on brainteasers and questions irrelevant to the open position should also be avoided as it doesn’t pertain to how well they’d do the job at hand. The author also highlights other suggestions such not blocking the internet, not to code on a whiteboard, and not to conduct phone interviews. His advice is to make the interview as relevant as possible to the job; use real tools and write code on a computer. Software craftsmen are also interviewing the company and as the author says will reject offers from bad companies.
After reading chapter 11 there is a lot that I agree with but some things that I do not. First I strongly agree with avoiding brainteasers or situations that make it seem like you are trying to outsmart the candidate. It’s uncomfortable and if the interview seems stressful, one can only assume how bad the actual job would be. I also strongly agree with not blocking the internet. If someone is stuck on a question, they should be given the chance to find the answer however they see fit. As a software developer you will always have tools and resources to help you with whatever problems you come across. One thing I slightly disagree with is not writing code on a whiteboard. I think this is perfectly legitimate for base knowledge coding problems or algorithms that will pertain to the job especially for a junior level job. For more senior developers, their work and portfolio should be able to speak for themselves. I also disagree with not conducting phone interviews. The phone interview doesn’t need to be extremely technical but it’s good to make sure the company and candidate are on the same page. If this short conversation can filter people out then I see that as valuable time saved. Perhaps someone thought the job encompassed other responsibilities and were disappointed upon coming in for the interview. There’s no need to allow those kinds of situations to occur. Lastly I believe that companies spend a lot of time in creating their hiring process. Just because they may proceed through their selection process different would not make me reject an offer. Above all I look for a job I’d be excited to go to every day and people I can relate to. The selection process can be very generic for larger companies and won’t always reflect the open position. It’s up to the candidate to dig deeper and see if it’s something they truly want.
Chapter 12 covers the topic of the cost of low morale. The author touches upon how a team with low morale can bring an entire company down and just how costly it can be. The first contributor to low morale mentioned by the author is what he calls the “agile hangover.” The agile transformation that swept many companies did very little to improve developer’s technical skills. They had a new process but were still developing the old way. If anything this hurt team’s motivation even more. Another contributing factor is the employment of 9-5 developers. These are developers who don’t actually care about their job and are just there to collect a paycheck. They have no sense of urgency and do not care if they show zero results. While some people simply can’t be motivated, hiring a few craftsmen to a team can definitely turn things around according to the author. They can help fix technical issues, bring new innovations, and get a team excited again. Craftsmen can get a team to enjoy their work more which drives better results. Developers who enjoy their job will care and improve their skills.
After reading chapter 12 I agree with the ideas presented by the author. I do think he makes the situation seem a little easier than it truly is though. Not many companies can afford to hire a few craftsmen developers on to a team for motivation. I also think it would be tough even for a few craftsmen to get an entire team excited about their job. If a team and its members have dropped that low in caring then some employees probably just need to be let go. It could also be management or general company culture that has caused a development team to be so poorly motivated. Hiring some craftsmen will not fix a companywide issue. Also if a true craftsman were to listen to the author’s hiring advice, they would most likely not take a job with a team that lacked morale. I agree that low morale can cost a company a fortune but I think the issue goes deeper than the advice offered by the author.
Chapter 9 covers the topic of developer recruitment. The author makes an immediate claim that job board type sites with the traditional job description are a bad way to hire developers. Many job postings list an abundant amount of technologies that aren’t even required to do the specified job. This immediately filters out some really good candidates. Listing years of experience can also filter out good candidates because years is not necessarily a measurement of knowledge. The author goes on to say that many larger companies continue to get developers similar to their “bad” ones because they are relying on their poor recruitment process. Getting rid of generic job descriptions and avoiding the mistakes mentioned, gives access to a wider range of potential craftsmen. This can also remove any obscurity the recruiters have with not understanding the true technical aspects of the job and prevent keyword matching. Another piece of advice given is that companies should avoid financial compensation for employee referrals. It creates wrong motivation and incentive to recommend a potential employee. Working with talented people who improve the quality of the work environment should be compensation enough. It is suggested that companies should always be proactively recruiting. Getting involved in tech communities and user groups is a good and cheap way to gain exposure to potential talent. By building a pool of candidates for future employment, the hiring process can move much quicker. Lastly, the author suggests that you look for passion above all else when selecting a new developer. Someone who blogs, contributes to open source, or attends conferences will likely see the employment opportunity as more than just a job. In summary, if you are currently dealing with “bad developers” look to change the recruitment process to hire the people you really need.
After reading chapter 9 I found a lot of the author’s suggestions and advice to be helpful for my future. While I agree with his points, many companies still post job descriptions like the ones he called out. For people who are unemployed it’s not always easy to find the perfect place to work never mind go through a selection process for a company that isn’t even hiring right away. I strongly agree with the author’s comments about not listing years of experience on a job description. It can filter out people who are newer but more current with a technology and keep people who have done the same exact thing for “X” amount of years. One thing I have noticed looking for entry level software jobs is that companies post long lists of specific technologies for required skills. I think it’s more important that a candidate demonstrates the ability to learn new things. Having a coding assignment as part of the selection process can allow candidates to show their adaptiveness to new technologies as well as give a current sample of work. I have also seen job postings for entry level or junior developer positions that require a lot of experience or many technologies. I can’t imagine postings like this can get very many applications as they are not practical. While I agree with the ideas in this chapter, the hiring process in the United States is still far from adopting them as the new norm.
Chapter 10 covers the topic of interviewing from both the company and candidate side. The author gives a helpful reminder that an interview is not someone begging for a job. It is a business negotiation with the goal of creating a good partnership. As the demand for software developers is at an all-time high, candidates do not need to settle for anything less than a good partnership. From the perspective of the company giving an interview the author makes several points. In general it is best to focus on the candidate’s enthusiasm, projects, and achievements and not necessarily hard skills like a particular technology. He also says to favor those who ask questions showing genuine interest in the company and their role. Lastly it’s important to not only give a clear outline of the open position but to make sure it matches what the candidate is looking for. The author also gives advice from the perspective of the candidate. He suggests to take the time in the interview to analyze everything about the situation. Learn as much as possible about the work environment, hiring process, and actual role you’d be filling. A good interview should also have some key elements to it. For one, the interview should feel more conversational and not like a scripted test. You can’t truly show or find passion and talent with questions requiring yes and no. It is also suggested that some form of coding be part of the hiring process. This could be a pair programming session or a pre-interview coding assignment for filtering. A software developer should also be a part of the interview process at some point. Developers interviewing developers is beneficial for everyone. In conclusion a good interview will form a productive partnership that both sides are enthusiastic about.
After reading chapter 10 I strongly agree with the interview advice given by the author. In regards to asking questions in an interview, I can’t imagine I’d be very interested in a role that I didn’t want to know anything about. I also think it’s important to remember how much time you truly spend at work. Most of your time is spent on the job so I think the most important point is that you can see yourself being happy going to work every day. While I think it’s important to analyze the logistics of the interview, many times people can be very nervous going into an interview which can hinder the execution of their interview game plan. I believe a good interviewer will get the candidate comfortable in a conversation before getting to the important parts. Lastly, as a soon to be developer I think it’s important to remember the abundance of jobs there are in the field. I can’t settle for something that I won’t be truly excited about. It makes for a bad partnership and violates all the advice given by the author as a software craftsman.
In Sprint 5 we were finally able to make meaningful code changes on our new issue (APTS-296). We basically focused the entire team on the issue because the semester is quickly coming to a close and we want to have a pull request accepted before our last sprint finishes. This issue took a while to figure out because the code we needed to modify was in the node_modules directory and we were only focusing on the src directory. Once we broadened our search to node modules we able to successfully modify the code and run it on the AMPATH test server. I think by focusing everyone on our issue it allowed us to make sure we were able to come up with a solution. Luckily during this sprint nobody has had server issues and we have been able to pull changes from upstream with no major problems. Looking at the next sprint our main focus will be to get a pull request submitted and accepted. To do this we will need to set up Travis CI on our team’s GitHub repository and squash all commits to one so that AMPATH accepts our changes. Overall we had a productive sprint and we will focus all of our effort on the pull request in our last sprint.
Chapter 7 covers the topic of technical practices. The author explains that Agile methodologies help build the right thing but craftsmanship focuses on technical practices to the build the thing right. These practices are referred to as Extreme Programming and have been considered part of Agile since 2001. The problem is that many companies did not adopt Agile’s technical practices for a number of reasons including they weren’t shown the business value of them. The practices mentioned by the author are as follows:
Automated Testing Test First
Test Driven Development Continuous Integration
Pair Programming Refactoring
All of these practices provide business value in the form of shorter feedback loops, cleaner code, improved system knowledge, or increased maintainability. The author goes on to say that all developers including managers should be held accountable for the practices they adopt and even more the ones they choose not to. Lastly the author reminds us the importance of pragmatism in being a software craftsman. Developers should always look for ways to doing their job better. It’s the developer’s job to adopt the right practices which provide the best business value and provide maximum customer satisfaction.
After reading chapter 7 there are definitely some good takeaways for my future development. Primarily I think it’s important to remember that it’s important to continuously look for ways to add value to your environment. While there might be a learning curve in adopting new practices, focusing on the business value in the future should suppress any doubts. While I don’t think every project needs to adopt every practice of Extreme Programming, I do think there is at least one practice that every project can and should adopt. At this point in my software development knowledge I would be hesitant to join a team in the future that was not practicing some sort of automation testing or TDD. It has been brought up so frequently by major role models in the programming world that I don’t think I could settle for anything less.
Chapter 8 covers the topic of the long road of a career to mastery. The author explains that it’s important to take control of your career and break it down into small iterations like you would a program. After each iteration, re-revaluate short term and long term goals and make sure your career is in alignment. If you’re not sure about your future then it’s time to create new opportunities to open doors for yourself. These can include attending tech events, blogging, or presenting at a conference. One thing to keep in mind is that your career is an investment. Maintaining and improving technical knowledge will always ensure a software craftsman is never too far from a job opportunity with the stability and security they need. The author goes on to say that aside from money there are three things which should motivate a developer in their career: autonomy, mastery, and purpose. He also warns the reader not to get caught up too much in a career inside a company. This can cause a shift away from personal goals and towards just getting the next promotion. He mentions that this is a common path to having under qualified and outdated managers. In conclusion a developer must understand where they want to be in their career and focus on reaching their own goals over a company.
After reading chapter 8, I think there is some really good advice to remember for my future career. I really liked his statement that knowledge is forever. I truly believe that if you maintain your skills and knowledge you will always be prepared for what life may throw at you. I do believe this chapter was aimed more for developers who have at least several years of experience. As someone who is just entering the field, I can’t be too stringent on the specifics of my first job. While I would not take a job doing something I absolutely hate, I think that you need to make a little more sacrifice in the beginning so that you can dictate the path of your career as you gain experience. Lastly I fully agree with valuing a personal career over any career within a company. If at any time it seems like you need to sacrifice your future goals to stay with a company then it is probably time to leave. This chapter was a good reminder that we are all responsible for our own path.