An interesting read and insight into issues a developer faces. I appreciated all the tips, but if I had to narrow it down to three I'd choose the following:
- Advice on using the right tool, and becoming a "power user" of it - the right tool makes the job easier...always be willing to try new, more effective tools and be ready to master them if they provide enough value.
- "Don't count the hours" - Deep work is what matters. There is a limit to it, and pushing beyond may be counterproductive.
- Pair programming with someone more experienced - it may be intimidating to work with someone who knows more than you and show how little you know. But its a great way to get your thought process refined by someone who has already been there. I imagine theres no faster way to improve; this is something I'll look to do in Turing.
I flew for the Navy, so this touches on one core principe we've practiced over the years. I'm surprised to find the medical profession adopting this practice so late, since the benefits of checklists address so many issues that are shared between the fields. One is the issue that proper routine preparation, while tedious, greatly increases the success rate of the endevor and improper preparation frequently results in diaster. When I arrived at my Readiness Air Group we were all warned about the two pilots who tried to take off with their wings folded. Why would they do such a thing? After years of flying, the preflight tasks are so routine (roughly a hundered items) that they decided not to break out the checklist - a decision that could have resulted in the destruction of a multi-million dollar aircraft and more importantly the loss of 5 lives. Of course they lost their wings and never flew again; they also again demonstrated why checklists are there to be read and not memorized. The medical profession operates with extreme fatigue and clearly needs checklists.
The second issue is that checklists address is the need for a logical and speedy troubleshooting process when an issue arises. If your plane has lost all engines or your patinet is bleeding out and you are panicking, is this the time to grab at the first solution that enters your mind? A good checklist provides an efficient and reliable method of troubleshooting, from big picture to small. Consider my dad trying to debug software over the weekend - he spent all Saturday making no progress and getting progressivly more frustated. Waking up Sunday, he realized he wasn't examining the company's most up-to-date version of the code so nothing fit correctly. Again, an obvious (but not) big picture problem that a one-minute checklist would likely catch.
So the benefits of a checklist are not lost on me. With my very limited programming knowledge, I can begin to imagine how checklists would help with preparation, and more certainly with troubleshooting.
What is your impression of strengths-based development? What questions do you have about this kind of development?
Having never been a part of strength-based development, I can appreciate it from a distance. That the best work comes from "doing what you love and applying your strengths in creative ways" is something I agree with. Of course, weakness cannot be neglected.
What do you feel are your top strengths? How do you know?
When I've been given the chance to give feedback and/or critical analysis of a project, understanding issues and devising methods of making the process better come naturally to me. I know because my superiors implement my feedback and frequently request me for critical/creative analysis.
How do you hope to develop your strengths for your new career in software development?
Good critical analysis comes with a deeper understanding of all the factors in play; I hope that by gaining an understanding of myself in this environment, as well as my cooworkers and of course the technology, I will be able to develop insight that allows us to be more effective.