Chapter 3 covers the general topic of when and how to say yes as a professional at work. The stand out message is three simple rules: “You say you’ll do it. You mean it. You actually do it.” Avoiding phrases like “let’s” and “we” are crucial because they almost always hint at non-commitment. It said to make more definitive and personal statements. These include using “I” and giving a specific task which will be completed at a designated time. This chapter also reinforced a theme from chapter 2 in regards to only committing to what you can truly deliver. That is if you depend on another team or individual only make real statements about yourself however work with that other party as best you can to get closer to the target goal. Also another idea mentioned previously was early communication. Specifically mentioned in this chapter is to raise a red flag as early as possible because this gives the best chance at a work-around that still allows you to follow through with an expected task. The strongest point of the chapter is to be clear and definitive when saying yes, similar in how to say no in chapter 2.
After reading chapter 3 I have a few takeaways to reflect on. The first is to be more definitive in my own statements. I am definitely guilty of using the “I’ll do my best” mentality and after reading this chapter I realize that way of thinking won’t cut it in the long run. I also think an important message was to not commit to something that is out of your control. Looking forward I will take more time to think about what I am actually promising will get done and ensure it is fully within my power to do so. I also think the last scenario in the chapter was a good lesson. The employee promises that he will meet a Monday deadline knowing he is fully capable of doing so. It was his confident negotiating of taking a day off after his task was complete that I found worthy of remembering. This shows it’s sometimes okay to put in that extra work for an earlier deadline but not to be afraid to take that time to reset afterwards. Once again I believe applying the Scrum development process could help avoid some of these situations and improve your saying yes skills. By having semi-regular sprints you are saying yes and being held to your word on a more frequent basis. This development framework should help keep everyone honest and committed.
Chapter 4 talks about a wide spectrum of factors to keep in mind when actually coding to maintain the professional character the book strives for. One of the main factors mentioned is distractions while coding. This could be that you didn’t get enough sleep, a personal issue at home, or possibly just writers block. You should take some time away from the desk and see if there’s anything that can be resolved regarding the issue so that your mind will be able to focus on your code. Secondly, the author mentions “the zone” where programmers may feel like they are on a roll and have tunnel vision. He warns that you should never code in this state because you lose sight of big picture concepts and will likely return to the written code to fix mistakes. Overall the theme of this chapter is that you should recognize when you are not doing your best coding. It’s suggested to meet with a pairing partner or maybe just walk away for a few minutes so that only the best code gets written.
After reading chapter 4 I think there is a lot of good advice to keep in mind when coding in the future. This being said I’m not sure everything is as easy as it is told. Life distractions will always be present and I’m not sure trying to solve them at work would look professional among my peers. I do agree however with the idea of stepping away and taking a break if I feel like I’m not writing good code. Having a mentor, as the author mentions towards the end of the chapter, could be a great way to stay on track by meeting regularly with that mentor or even a partner. In regards to the author’s mention of false delivery and defining done the Scrum framework once again would help prevent the shortcomings mentioned in the chapter. Throughout the book so far Scrum has proven to address many of the concerns in each chapter. I am starting to see why this form of agile development has been so widely adopted.
Chapter 1 gives a layout of what a true professional software developer should be and highlights a broad spectrum of attributes one should possess. The first major trait is accountability. More specifically, while bugs are certain to occur it is up to the developer to do everything in their power to see their employer’s problems as their own and take all measures to avoid bugs and errors. When a QA team comes back with a bug, a professional developer should be surprised. The second major trait of a professional developer is testing. It is even suggested to use test driven development (TDD) where tests are basically written before the actual program. There should always be some form of automated testing to ensure software is working correctly prior to QA. Also along with the coding aspect, a professional is always making small changes to the structure of their software to ensure continuous improvement. Lastly, a true professional pursues knowledge and information outside of working hours. It is said to dedicate the 40 normal working hours to your employer and 20 hours for self-growth every week. Within those 20 hours it is also not only important to learn new skills but also practice and sharpen skills already obtained.
After reading chapter 1 I believe there are a lot of takeaways, especially for a student who is seeking good habits before letting bad ones set in. One thing that I am going to look into further is the test driven development approach. I lack the experience and knowledge of appropriate testing and by writing tests first I think it would have nothing but positive effects on my development. I also think the 40/20 hour split is an important habit to start now. Even though as students we are learning many hours already, I still strive to learn outside of the curriculum and this chapter has reconfirmed my actions. I will try to continue if not increase my time spent learning more skills outside classroom studies. Lastly I definitely need to practice more of the skills I have already learned. I often find myself only using something when I need it, forcing me to look simple things up that should be committed to memory. This chapter showed me what I really need to be doing if I want to consider myself a professional by the right definition.
Chapter 2 highlighted a lot of situational awareness of when to say no as a professional software developer. One key point is to search for the best possible outcome when dealing with a supervisor. Additionally, never make false estimates and always stay honest in what you truly believe. Saying or working with the “I’ll try” attitude is recipe for disaster and not the trait of a true professional. Lastly, the chapter is clear that being upfront and consistent with your abilities and timelines is best for everyone involved.
After reading chapter 2 I can definitely see how this advice may come as more of a challenge to a junior developer. They lack the experience to accurately and confidently set time tables for themselves. I think there may be an unavoidable learning curve to the “saying no” mindset however it definitely seems like great advice to follow. Having a systematic approach to development such as using Scrum could also alleviate many of the issues described in this chapter. Working in shorter sprints with continuous contact with the client in the Scrum manner should for the most part prevent a team or developer from being coerced into an impossible task. Also, it is much easier to say no as a team rather as an individual to a supervisor. Great content to think about and to keep in mind when you know you are being pushed to accomplish an impossible task on time.
This is my intro for CS 448, I look forward to blogging about the experiences I have in this class.