See http://madexpo.us/
The Mid-Atlantic Developer Expo.
In my backyard (more-or-less).
There's going to be this: http://madexpo.us/Sessions/384
and this: http://madexpo.us/Sessions/385
I'm looking forward to http://madexpo.us/Sessions/339, which I'm certainly going to attend. Many other sessions look like fun, too.
Thursday, April 26, 2012
Thursday, April 19, 2012
Should the CIO Know How to Code?
Read this Computerworld posting: Should the CIO know how to code?
The answer is "Yes."
The examples of "well-functioning non-technical CIOs" are people as rare as hen's teeth. "These are leaders who know what they don't know. They are good at asking the right questions, probing for further insight, and then re-framing the answers in such a way that the business side will understand".
I'm sure there are people like this. In the last 35 years, I've met very, very few. Two actually.
Larry and Chuck are the two examples.
Larry knew what he didn't know. He took the time to actually sit with actual developers and actually watch them work. It was weird the first time he sat and watched you type. But without deep knowledge, he couldn't be sure the projects would get done. So he allocated an hour or more each day to sit with key developers and learn.
Chuck did essentially the kind of thing. He sat with each developer individually every single day. He did not have all-hands meetings that lasted hours. He did not have an "around the table" where everyone spent 20 minutes boring the entire rest of the team with irrelevant details.
Could they code?
Essentially, yes. They looked at code over a developer's shoulder. They participated in a form of "pair programming" where they watched code happen. By themselves they couldn't code much. As pair programmers, however, they could work with another programmer and get stuff done.
The answer is "Yes."
The examples of "well-functioning non-technical CIOs" are people as rare as hen's teeth. "These are leaders who know what they don't know. They are good at asking the right questions, probing for further insight, and then re-framing the answers in such a way that the business side will understand".
I'm sure there are people like this. In the last 35 years, I've met very, very few. Two actually.
Larry and Chuck are the two examples.
Larry knew what he didn't know. He took the time to actually sit with actual developers and actually watch them work. It was weird the first time he sat and watched you type. But without deep knowledge, he couldn't be sure the projects would get done. So he allocated an hour or more each day to sit with key developers and learn.
Chuck did essentially the kind of thing. He sat with each developer individually every single day. He did not have all-hands meetings that lasted hours. He did not have an "around the table" where everyone spent 20 minutes boring the entire rest of the team with irrelevant details.
Could they code?
Essentially, yes. They looked at code over a developer's shoulder. They participated in a form of "pair programming" where they watched code happen. By themselves they couldn't code much. As pair programmers, however, they could work with another programmer and get stuff done.
Subscribe to:
Posts (Atom)