Professional Development Reflection: 29 Behaviors

Duke_professional_dev.md

The 29 Behaviors in this article were all of some value, many in life in general and not just in coding. For me, however, there were a couple that stuck out. First, there are #3 and #4: Acknowledge that micro-decisions matter and Acknowledge that major decisions don't matter that much. As a person who is generally terrible at naming things, I find it interesting and a little daunting that naming convention is made so important in this section, but I have also seen first hand how much a single misplaced letter can keep a piece of code from working at all. At the same time, looking at the bigger picture, it's also important to remember that we are not dealing with life and death situations here. It's easy to get caught up in the idea that a single decision can be the be-all and end-all, when really, there is very little that cannot be rethought, reframed, or just thrown away for something better. Finally, #22: Skip a lot of meetings interested me. It seems like the kind of advice that sounds nice in theory but is not reasonable in practice. However, by setting the expecation and the boundry with co-workers that the work must get done, meeting or no, seems to me to be a healthy way to work.

Checklist Reflection:
To me, there are a couple of things going on in this discussion of checklists simultaneously. First, there is an order of operations. This thing needs to happen before this thing, and before this next thing, and so on, because the whole system breaks down without the order. What I think concerns me about coding is that the order of operations exists, but only at the end, when we test it. One could, in theory, write all of the code backward and it wouldn't matter, so long as the end result is in the right order.
The second thing about checklists is the idea of troubleshooting. If and when something goes wrong, it becomes the diagnostic tree by which we figure out how to fix whatever is broken. This is what I'm looking forward to: having more of a roadmap to fixing what fails than I have now.

Strengths-Based Reflection:
From what I've read so far about Strengths-Based development, I have some concerns. It feels in some way like so many buzzwords and jargon that has always permeated corporate culture. It sounds good, it makes sense, and yet implementation ends up being sporadic and ultimately useless. I guess I just want to make sure that these evaluations are based in good science and not in the observations and anecdotes of people who write business books all day.
For myself, I believe that communication is my best strength. I am shy and soft spoken in person, but my written communication is excellent, and I think I'm getting better about the other part.