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.
Chapter 5 covers the topics of trying to be a hero and having goodwill as a software developer. The author highlights many of his previous jobs where he was extremely overworked, forced to meet unrealistic deadlines, and worked on large scale projects without any client interaction. These are all definite no’s for a software craftsman. The first lesson is learning to say no. Over working creates bad code which is bad for developers, managers, and clients. A manager can’t be allowed to dictate impossible tasks. Development teams need to stand their ground on what can realistically be done with a constant communication flow to managers and clients. When a developer has to say no, they must provide alternatives or suggestions to the problem. Developers must always be clear about what can get done and any concerns should be addressed as soon as they arise. Keeping transparency with managers and clients allows everyone to work as a team to deliver the best product by a deadline. Also, managers should work as part of the team, facilitating workflow and protecting their developers from external pressure.
After reading this chapter I would definitely have to give the author credit for sticking it out as long as he did at some of his past jobs. I can’t imagine only a few hours of sleep in a car and then back to coding especially with no overtime pay. That is clearly abuse of power by the employer and should never be allowed anywhere. One point the author mentioned that I liked was if you deliver every time you say yes and commit to something, saying no will carry weight to it. I also agree with giving options and alternatives when saying no. A flat no provides no explanation or workaround and isn’t a sufficient answer. Basically from this chapter I will take away the points to not get overworked and always stay transparent with the workflow to both managers and clients.
Chapter 6 covers the topic of working software. The author reminds us the Manifesto for craftsmanship values working software over comprehensive documentation. He then makes the argument that programming is like gardening and that code must be maintained. If code is left to rot, implementing features and changes becomes a bigger task as time goes on. The author mentions that this rotting code is usually the product of developers self-imposing time constraints and pressure on themselves to accomplish tasks quickly. One way to avoid the rotting of code is to practice Test Driven Development from the start and automating testing. That way tests are always written for new code and they can be easily run on top of the old tests. He also mentions how many developers tend to shy away from legacy code because of the frustrations it brings. Instead of focusing on the headache legacy code presents, it’s advised to pick apart small bits and improve them, writing tests along the way. By piecing small bits of legacy code into an upgraded format, huge improvements can be made over time. Lastly, the author makes the point that the cleaner software is kept, the greater lifespan of an application and the greater return for the client which is always the end goal.
After reading this chapter I think there are some good points to take away. First I liked the author’s approach to legacy code. Rather than complain and avoid it, take it as a challenge to improve the code and implement new technologies and tools. While I would still like to work on a project relatively young in development I will keep this positive outlook of legacy code bases in mind. Secondly, I think it’s clear by now that TDD and test automation are best practices in software development and are the way of the future. They have shown up in almost every book covered at this point as well as emphasized by Robert Martin. In summary, my biggest takeaway is to remember to always maintain and improve my code as an ongoing process and take the time to do it right.
In Sprint 4 we finally got our first issue assigned. Unfortunately, our first issue (NGPOC-183) was rather difficult. It took us several days to try and understand how to tackle it and we ended up not being able replicate the problem on the test server. We had posted questions on the issue in JIRA and reached out to the developers on Slack but were not able to get any clarification or guidance. Although this issue has been a dead end so far I did get gain some knowledge in the code base and have better understanding with how the location feature works in the AMPATH dashboard. Right before break our group decided to take on a new issue (APTS-296) but we have not made much progress with it yet. Aside from our issues in JIRA pulling changes from the AMPATH repo as a remote upstream always seems to create a lot of conflicts and problems connecting to the test server. It hasn’t been anything we haven’t been able to work through but does slow progress down. We find it better to pull in changes frequently to make sure we are up to date and our changes will cause as little conflict as possible if we can get to a pull request. Looking back at the last sprint we did what we could for our first issue but the lack of further guidance slowed us down and kept us from any measurable progress. Looking forward we hope to make considerable progress on our new issue and move towards our first pull request. As of right now the team is still working well together and we aren’t going to adjust our velocity for the next sprint.
Chapter 3 covers the topic of what exactly software craftsmanship is. The author generalizes it by stating its putting responsibility, professionalism, pragmatism, and pride into software development. He then goes on a long walk through of how software craftsmanship came to be and the history behind it. Basically software craftsmanship has been around since 1999 however it never really gained traction until about 2009 when the Manifesto was published online. The Software Craftsman Manifesto outlines four main values of a developer: 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. The author concludes with the main idea that software craftsmanship is a lifestyle and mindset of professionalism in software development and always striving to provide the best service to clients.
After reading chapter 3 I thought there were some really good points but I did think the history was a little drawn out for the reader. I agree with the manifesto the author laid out however everything he mentioned seemed to be common sense. It is also something that must be embraced by the entire business for it to be effective. While one developer could be a craftsman, it takes everyone to follow the manifesto for it to truly work and give the client the best experience possible. My favorite idea from this chapter was the ‘craftsman swap’ where developers from different companies would trade places and act as if they were a developer at another company for a week. This is a great way for teams to get an idea of what they could do better and sheds some light on how other companies are operating. Both teams benefit and can adopt the best practices from the combination of two teams. I can however see where competing companies may not want to have their competition directly working with their team to gain any kind of competitive edge. Overall, I think the Manifesto for craftsmanship holds good points any developer should be following and sets a higher standard for developers everywhere.
Chapter 4 covers the topic of attitude being a software craftsman. The author makes a point to make it clear that we as individuals are responsible for our own careers and continued learning. While it’s nice to work for employers who invest in their employees we are ultimately responsible for keeping ourselves trained and up to date. He goes on to talk about all the different ways we can keep up on our training so that we are always learning. First he mentions reading material in the form of books, blogs, or technical websites. The author does mention even beginner developers should keep a blog to document and track their progress. Next he talks about ways to practice. When practicing a problem it’s important to focus on how the problem is actually being solved and not just writing code that works. Katas which are short coding exercises or doing personal pet projects are also some suggested ways to get good practice in. Lastly the author touches upon time management. Many times we tell ourselves we are too busy but he insists to make time. We can do this by limiting habits like TV watching or social media use. He does make a point that there needs to be a good work life balance but to own your own career you must manage time wisely and keep your skills sharp outside of normal working hours.
After reading chapter 4 I noticed a lot of commonalities mentioned from Robert Martin’s Clean Coder. I strongly believe it is an individual responsibility to continue software learning at any career stage. Out of the ways mentioned I find myself following social media and blogs the most. With the speed that tools and technologies come out, blogs tend to have good early information and usually tutorials to help you learn. One thing I’m not sure I fully agree with is the Pomodoro Technique. While I think it may be useful for someone who’s off track, setting timers and keeping such a rigid schedule does not seem sustainable. Personally I know I would keep checking the time remaining which would hinder my focus. In conclusion my career will surely benefit from personal learning and proper time management skills.
Chapter 1 covers the topic of software development in the 21st century. Basically the author is introducing the overall theme of the book in that today’s developers are expected to be software craftsman. Just being able to write code isn’t good enough, a developer needs to have the ability to contribute to the business in as many ways as possible. The author also points out what seems to be a flaw that seniority among developers is earned by years of experience instead of knowledge. He argues that developer’s experience can be so different across technologies and industries that just years of experience should not indicate seniority. In conclusion the author is preparing the reader to learn how to become a software craftsman like he mentions.
After reading chapter 1 there’s not too much information yet but I think the author made a couple good points. The first one being that he basically demoted himself from architect to developer for the simple goal of being happier. I think it’s important to remember that in order to be successful you need to be happy above all else. I don’t think maintaining a job you are completely dissatisfied with is sustainable. I also agree with the author’s thoughts on seniority. While years of experience definitely holds value, someone with proficient knowledge of a subject shouldn’t be thought of as junior just because they haven’t developed for as many years.
Chapter 2 covers the topic of Agile development. The author gives a general idea and history of the methodology. Basically Agile was created by the most influential developers in the early 2000’s to address both process and technical oriented disciplines. These disciplines would ensure developers built the right thing and built that thing right by getting the most feedback as possible through quick and short iterative work cycles. Agile completely changed the development world and gave control to small teams who played all the roles of software development following the 12 principles of the Agile Manifesto. While the Agile takeover massively improved communication in business, it ultimately led to the Agile hangover as the author calls it. Companies were using Agile only as a process improvement and maintained their sub-par technical disciplines. Before long, companies who had adopted Agile development were back to their old ways and not seeing the results they expected. The author blames this on the companies only committing to partial transformations and neglecting to improve their technical disciplines. The author concludes saying that software craftsmanship and the Agile methodology can work together for best practice. While Agile will improve upon the development process, software craftsmanship will promote better technical practice and doing more for the client.
After reading chapter 2, my thoughts of Scrum have been reconfirmed. As one of the most popular Agile implementations, Scrum has taught me the importance of constant feedback and changing demands to work in the most efficient way possible. I can definitely see how the Agile hangover was destined to happen. Focusing on the development process was a great idea but lower level disciplines of writing good code should have been enforced before if not alongside the adopting of Agile techniques. This really shows that no method or technique can outweigh bad code or lack of technical discipline. Having seen the effects of only focusing on improving processes I do wonder if Agile coaches and professional training seminars are better equipped to address the importance of technical improvement alongside Agile development for optimum results. In summary Agile development is a great technique for a development team but must be accompanied by correct technical practice through software craftsmanship.