Live Q&A - Beyond Coding: Toward Software Development Expertise
Dear mjlinden, Thank you - I'm delighted that it had value for you. Happy to discuss further; feel free to contact me: m.petre@open.ac.uk.
Following my perhaps rather ambiguous question in the chat, I'll re-phase and expand upon it ... just a bit and hopefully, with more clarity. From my comprehension (I could be wrong!) true innovation follows on from the creative process. Over recent decades, certainly with the wide-spread adoption of IT Tools across the board (amongst other things), the pace of innovation has certainly quickened and widened. The knock-on effect of this is ever-increasing competition (globally, with constant pressures on time-to-market et al), ever-increasing costs of development (certainly staff renumeration) and labour-churn (including staff poaching) - a few (of many) examples that I had termed 'dynamics in play'. Basically, as teams are composed of individuals (who many can certainly think for themselves, including of themselves !!), what are the impacts on the creative process? I'm tending to think of the negatives here, sorry, rather than the positives (if there are indeed any!) and, in this instance, poor decision making (meeting deadlines), burn-out (constant pressure), redundancy (threat of) etc come to mind! A follow-on question would be "How can these 'all-around-us' pressures be minimalised for the benefit of greater creativity / greater productivity" - read the book?
Dear BobF, Complex question ... shall we arrange a conversation? If you're happy to speak, feel free to contact me: m.petre@open.ac.uk. If not, I'll try to distill the key observations of what has worked in practice over the next couple of days and post something brief here (since the long version isn't likely to fit in this format).
Sounds good. Expect an email from me to kick-off within 24-48 hours, once I have distilled my questions even further. What do they say ... "Life's complicated"! Re: 'Ways Experts Think' - Personally, I think this is primarily innate i.e. personal characteristics although many will try to emulate with some success, some failures! PS: I would probably fall under the latter category although 'who knows' ;<)
Most experts would put themselves in the latter category! From experience, the best way to identify experts it to ask other people (who will usually agree on specific people), rather than to ask the experts in question (who will usually say 'Not me!' - because they are expert enough to see the gaps in their expertise). But there's also evidence that emulating the practices that embed the mindset does improve outcomes.
Just wondering if my email, sent on 8 May, was successfully received by the OU server? Regards
Interesting analysis, as an Engineer its great to see that several things we do (problem solving) explained how we get there. It does bring up a question that I had over years that some managers ask on "when" or "how much time" does it get to be there on that "expert" level. I always say we need the experience from the problem, but 2 teams working on same problem with same experience usually do not get there at the same time because whatever "expert" is on that team will have different maturity to get these habits executed from one day to another. What will be the average minimum expert age you have come across in your analysis? sounds like you studied teams where at least there is 1 or 2 "gray hair" engineer , but probably not. O probably same question I get asked , by when this "expertise" level is reached ? . As a reference I have seem that scrum teams after 6 sprints the efficiency pretty much stays the same (velocity of the team becomes more stable, some expertise is reached)
Dear Megareve, Thanks for your interest and questions. The answers aren't simple. Yes, many of the experts I've studied are older -- but some are quite young. Short version: it depends on breadth of exposure (different types of problems), reflection, and when they develop a design mindset. I would be careful to distinguish 'efficiency' from 'creativity' and from a longer-term understanding of 'productivity'. The phenomenon you describe might have much to do with team communication and dynamics -- and, yes, there's evidence that it usually takes a bit of time and experience to 'bed a team in'. That's a contributor to -- but not the same as -- creativity. Happy to discuss further; feel free to contact me: m.petre@open.ac.uk.
Thank you for a very interesting talk.
Thank you - glad you found it so!
This is a good high level talk about techniques engineers can use to get unstuck in design and debugging. I want a poster of the different ideas Marian talks about for when I need a different methodology to encourage creativity in my team.
Elecia, Thanks for this. I'll see about a poster ... In the meantime, some teams use the book ('Software Design Decoded') as a prompt; for example, they pick a page a random, or post a page per day.
An extremely interesting seminar! Probably the best I've attended in years! Beyond that, it has shown me that some of the creative skills I have, and some of the creativity tools I've developed over time, are not those of an "imposter" or oddball, but some of the very same skills and approaches used by experts. In general, it has made me more comfortable in my approaches to thinking as an engineer...