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.
From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.
