a follow-on question for you, after my blithering blog posting
Raoul Duke
Q.1: where do you draw the line between "this person is different and
diversity is good" and "this person is too alien in their approach and
thinking and either it would just be wrong or too
much change or we'll take for ever just to be able to explain
ourselves to one another which will mean we either never see eye-2-eye
which sucks, or we never ship anything which sucks"?
Q.2: how do you asses this in job interviews?
thanks :-)
![Ted M. Young [@jitterted]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWewvID4ovqyCrnsP9cctDIemJsDN5z3C11VE-IcDbDQYoIHLue=s40-c)
Ted M. Young [@jitterted]
For #2: ask! Ask them about their philosophy of software development and then ask them to back that up with concrete examples that support that philosophy -- and possibly places where the examples didn't follow their philosophy, but they did that on purpose.
I'd love to hear what others think...
;ted
--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To post to this group, send email to software_cr...@googlegroups.com.
To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
David Wilde
In my current job, I'm made to feel different because I think we should code our unit tests!
So my advise is to be open to new ideas but make sure they cna be backed up even when you attempt to pick them apart. Ask what are the pitfalls of such an approach. If these cannot be explained then be cautious. Few people are better than an industry.
Jason Catena
Actually, half of all people are better than the average.
On Sep 16, 2011 7:15 PM, "David Wilde" <djw...@gmail.com> wrote:In my current job, I'm made to feel different because I think we should code our unit tests!
So my advise is to be open to new ideas but make sure they cna be backed up even when you attempt to pick them apart. Ask what are the pitfalls of such an approach. If these cannot be explained then be cautious. Few people are better than an industry.
On 17 Sep 2011 00:53, "Ted M. Young [@jitterted]" <tedy...@gmail.com> wrote:
>
> Very good question...
--You received this message because you are subscribed to the Google Groups "software_craftsmanship" g...
Kurt Häusler
Anthony Green
> Q.1: where do you draw the line between "this person is different and
> diversity is good" and "this person is too alien in their approach and
> thinking and either it would just be wrong or too
> much change or we'll take for ever just to be able to explain
> ourselves to one another which will mean we either never see eye-2-eye
> which sucks, or we never ship anything which sucks"?
A person who can't demonstrate they've thought through their practices
and regularly reflects hasn't demonstrated to me the necessarily
discipline however good a natural programmer they may appear to be.
Pairing is the one non-negotiable. If I can't walk a mile in your
shoes and you a mile in mine then we'll never overcome our second
order ignorance.
Depending on your application merely shipping isn't enough. The cost
of change curve will bite you sooner rather than later. The mythical
man month teaches us the dangers of merely adding more developers to
our team. Think instead about a minimal viable product, release early
release often.
Tony
David Wilde
--
Curtis Cooley
> When I said few people are better than the industry, I didn't mean better
> than the average. I meant that very few people have such radical ideas that
> can change the way that things can be done for the better. If they suggest
> things to you as an employer that you haven't heard of but can't describe
> the pitfalls of these approaches, then ask yourself; why isn't this practice
> industry standard?
> Hope this explains it more clearly.
> David
>
Change moves at the speed of smell. Look at agile development. It's
over 10 years old and still struggles to gain "main stream"
acceptance. I work in a waterfall environment. Please read that last
sentence again to make sure you didn't imagine it.
I think it is very easy for me to keep on the cutting edge of software
development techniques and practices and be way ahead of industry
standards. Not that the cutting edge is always the best, but I feel
it's pretty easy to stay ahead, and I do not practice nearly as much
as the leaders in the craftsmanship movement.
--
Curtis Cooley
curtis...@gmail.com
blog:http://ponderingobjectorienteddesign.blogspot.com
===============
Leadership is a potent combination of strategy and character. But if
you must be without one, be without the strategy.
-- H. Norman Schwarzkopf
David Wilde
--
David Starr
Scrum.org - Improving the Profession of Software Development
David Wilde
George Dinwiddie
I agree with the other David that Agile does not imply any lack of
quality. If extremely high quality is important, that's just one of the
things to include in your feedback mechanisms.
Agile is also not just for situations with changing requirements. A big
advantage of Agile is the use of feedback mechanisms to ensure that you
meet your intended goals or requirements.
Also, even when requirements do not change, peoples' understanding of
the requirements does. Agile makes it safer to run high risk impact
projects using mere mortals.
- George
On 9/21/11 8:45 AM, David Wilde wrote:
> Do pacemaker firms have changing requirements? If not what are the
> benefits of an agile approach? Why would you feel better about the use
> of Agile in this case?
>
> On 21 September 2011 13:34, David Starr <da...@elegantcode.com
> <mailto:da...@elegantcode.com>> wrote:
>
> Not use Agile on high tolerance (quality) projects? What?
>
> I would feel far better about pacemaker firmware developed iterative
> and incrementally than plan-driven. Further, I have worked with many
> organizations successfully creating highly reliable and critical
> software solutions using agile methods.
>
> Please don't give the impression that agile = low quality. Quite the
> opposite. If your quality is low, agile software development is how
> you make it better.
>
> *David Starr
> */Scrum.org/ <http://Scrum.org>- /Improving the Profession of
> Software Development/
> Blog: elegantcode.com <http://elegantcode.com/> | @elegantcoder
> curtis...@gmail.com <mailto:curtis...@gmail.com>
> blog:http://ponderingobjectorienteddesign.blogspot.com
> ===============
> Leadership is a potent combination of strategy and
> character. But if
> you must be without one, be without the strategy.
> -- H. Norman Schwarzkopf
>
> --
> You received this message because you are subscribed to the
> Google Groups "software_craftsmanship" group.
> To post to this group, send email to
> software_cr...@googlegroups.com
> <mailto:software_cr...@googlegroups.com>.
> To unsubscribe from this group, send email to
> software_craftsma...@googlegroups.com
> <mailto:software_craftsmanship%2Bunsu...@googlegroups.com>.
> For more options, visit this group at
> http://groups.google.com/group/software_craftsmanship?hl=en.
>
>
> --
> You received this message because you are subscribed to the
> Google Groups "software_craftsmanship" group.
> To post to this group, send email to
> software_cr...@googlegroups.com
> <mailto:software_cr...@googlegroups.com>.
> To unsubscribe from this group, send email to
> software_craftsma...@googlegroups.com
> <mailto:software_craftsmanship%2Bunsu...@googlegroups.com>.
> For more options, visit this group at
> http://groups.google.com/group/software_craftsmanship?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "software_craftsmanship" group.
> To post to this group, send email to
> software_cr...@googlegroups.com
> <mailto:software_cr...@googlegroups.com>.
> To unsubscribe from this group, send email to
> software_craftsma...@googlegroups.com
> <mailto:software_craftsmanship%2Bunsu...@googlegroups.com>.
> For more options, visit this group at
> http://groups.google.com/group/software_craftsmanship?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "software_craftsmanship" group.
> To post to this group, send email to
> software_cr...@googlegroups.com.
> To unsubscribe from this group, send email to
> software_craftsma...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/software_craftsmanship?hl=en.
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
David Starr
Scrum.org - Improving the Profession of Software Development
David Wilde
Curtis Cooley
> On a life-critical project like a pacemaker, would you not still want to
> have a thorough testing phase before shipping? Would you consider the
> testing that had been done iteratively to be sufficient? Would this
> naturally create something of a waterfall? I really have no experience of
> these sorts of fields and would be interested. I have always thought up
> until now that Agile works well for a great many projects but not
> necessarily all. Would you say that developing software in an Agile way is a
> no-brainer (i.e. there is no reason to not do it)?
Good agile teams build their process to match the team and the
project. If a thorough testing phase is appropriate, then an agile
team will do it while hoping that the testers find nothing. I do not
think adding a testing phase to the end of a project would deem it
waterfall.
While I do think Agile can be done for any project, the values and
principle of the organization will determine it's applicability. Good
agile consultants will do an agile assessment of the organization, and
the honest ones will walk away if the assessment fails. If an
organization values tools and processes over people, won't let the
it's people self organize, and prefers command and control then agile
will fail. That's where I work. What we build is not the limiter, but
the organization's command and control style. I trying to change my
organization, but I'm starting to realize that I may have to change my
organization.
That's why I think it's easy to be ahead of the curve. It certainly is
where I work :)
Chris Parsons
Agile has pitfalls. For example it needs the right culture to thrive in. It will only work well if the whole company has bought into the idea of it. You also wouldn't want to use Agile methods on a project that requires extreme quality. That's not to say that it would be the wrong choice in your line of work.
Suggesting something like continuous deployment/continuous delivery like flickr are doing probably would be. This does have real benefits but I would imagine that there are people at flickr that will be able to say how difficult it would have been to put this in place. I can imagine that for many companies, the effort involved in moving to this would not have a return on investment.
David Wilde
The return on investment stuff I was talking about was specifically about things more niche than agile such as continuous delivery.
I felt that Raouls question also included things other than agile (which I consider to be sufficiently big that most employers should have at least heard of) .
David.
David Wilde
The return on investment stuff I was talking about was specifically about things more niche than agile such as continuous delivery.
I felt that Raouls question also included things other than agile (which I consider to be sufficiently big that most employers should have at least heard of) .
David.
On 21 Sep 2011 19:10, "Chris Parsons" <chr...@rsons.org> wrote:
>
RonJeffries
Do pacemaker firms have changing requirements? If not what are the benefits of an agile approach? Why would you feel better about the use of Agile in this case?
Ron Jeffries
David Wilde
It's quite an easy assumption to make from the name!
I love agile because I think that there are very few software projects that wouldn't benefit from changing requirements. Software's great power is that it can change. If it didn't change it would be better as hardware.
I've never worked on anything where fixed requirements would have been necessary so my assumption comes from experience.
David
Adam Sroka
stuff to understand what they were in the first place?
This distinction requires knowledge that we don't have yet (Are we
pursuing a moving target, or a fixed target that we need to locate
precisely?) Fortunately the distinction doesn't change the way we
approach the problem. We have to do experiments and get lots of
feedback so that we can learn as much as possible along the way.
David Wilde
Adam Sroka
carefully we collect requirements for a pacemaker there are things
that we just don't know about hearts and the bodies that contain them.
Building what we think we need today given that we don't know things
is suboptimal. It behooves us to assume that we can learn stuff along
the way and that our solutions can improve as a result.
When we wanted to send people to the moon no one had even been outside
the atmosphere. There was a lot of science and a lot of educated
guessing going on, but there was a lot of learning along the way and
trial and error as well. And people died, and that was sort of
inevitable given the stakes.
When we send people into combat we know a lot about what they are
facing and we don't know a lot and we have a lot of information to
suggest to us what we don't know. It is necessary to learn along the
way, and people die, and that is sort of inevitable given the stakes.
There are a lot of other, less extreme examples. It is actually harder
for me to come up with an example of a situation where we have
something to gain by investing but nothing to learn along the way.
Assuming that most of the time there is something to learn that cannot
be known before we learn it, it must be true that at least part of the
time there is an economic advantage to being able to exploit the
things we learn along the way. Agile is about embracing that, and to a
lesser extent it is about employing techniques and strategies that
exploit it.
Curtis Cooley
> Maybe I spoke a bit too assertively about not thinking it would work well on
> an extreme quality project (Spaceship, Pacemaker, etc.) - I have never
> worked on anything like this and I would love to hear more stories about
> Agile in these environments. Who was the first to take the risk to try such
> a project in an Agile way?
I worked on a coal miner tracking tool. It used low frequency RF
signals to try to locate where coal miners are underground. If the
system failed, no one died, but if an incident happened and the system
failed, people who shouldn't have died just may. We did this in an
Agile/XP development cycle. We were feeling out the requirements and
the technology at the same time, and striving to keep quality as high
as possible. I always believed that we were doing the right thing
considering how important it was that the system worked. I do not
recall the deployment team ever going out to the test site, deploying
the latest system, and reporting back that it failed. Sure, there were
some bugs, but seldom if ever were there enough bugs or major enough
bugs that I felt we should change the process.
I also think you may have gotten jumped on a little because the view
that XP/Agile is just a way to slam out low quality software really
really fast is somehow prevalent "out there" and most of us are quick
to try and correct the view that Agile does not make quality software.
George Dinwiddie
On 9/21/11 9:28 AM, David Wilde wrote:
> On a life-critical project like a pacemaker, would you not still want to
> have a thorough testing phase before shipping? Would you consider the
> testing that had been done iteratively to be sufficient?
I believe in running all of the tests, all the way through development.
Even though they've been developed incrementally, I would not run them
once and then discarded. Even in projects that are not life-critical,
it's common to also do exploratory testing to identify issues that were
not anticipated. And, if there is a need to meet regulatory compliance,
formal validation, or other requirements, these become a deliverable as
much as the software is.
- George
Esko Luontola
On Thursday, September 22, 2011 9:02:42 PM UTC+3, David wrote:
It's quite an easy assumption to make from the name!
David Wilde
--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To post to this group, send email to software_craftsmanship@googlegroups.com.
To unsubscribe from this group, send email to software_craftsmanship+unsub...@googlegroups.com.
Eleanor McHugh
> Here is what I would call agile: http://youtu.be/ohnOe7Vsx4c
>
> It's not so much about changing where you are heading, but instead about being able to go quickly and fluently wherever you wish. Even going to places where common people cannot go.
That video resonates deeply with me as throughout my professional career I've always been involved with greenfield projects pushing at new boundaries, and the skill I prize more than any other is the mental fluidity which allows me to grok the problem domains I'm tackling with speed and accuracy, leaping from feature to feature in a conceptually similar manner. In recent years I guess I've been at odds with an industry which increasingly lacks the tools to recognise those skills and looks instead for conformity of practice which is why I now focus on my own open source projects rather than commercial development.
When I first started following the Software Craftsmanship movement I hoped it would take a rather different course than it has, recognising that formal practices can only help so far in the growth of a developer's skills and that what's also needed is an environment which promotes the acquisition of good instincts and aesthetics through thoughtful play. However with time I've seen the fallacies of Agile become increasingly prevalent in this space and it makes me sad that so many people will plateau before they reach their full potential because of their belief that mastery of a methodology is the same as mastery of our craft.
As a means to help inexperienced developers acquire competence Agile methodologies are very effective, likewise they mitigate the impact on competent developers of dealing with stakeholders who lack a deep understanding of the problems they wish solved. For both these reasons they're an improvement on classic Waterfall, and if introduced at that particular point when intelligent people are desperately seeking some sense that an apparently intractable problem can be tackled effectively Agile provides a more effective way of taming the associated chaos. Unfortunately like many palliatives it can also become highly addictive with longterm effects which are still poorly understood by most practitioners.
For this reason if given the choice between a pod of Extreme Programmers and two lazy-arse hackers of the old school to work on a project I will pick the latter every time, and their project will deliver both earlier and more successfully because they have skills which transcend the intrinsic limitations that an Agile approach imposes without losing any of the advantages it might offer aside from weekly progress reports. Indeed many of the things Agile fetishises are standard components of any old-school hacker's toolbox: ad hoc pairing is a great way to share knowledge and perspective; exploratory coding engages our sense of play and allows a problem domain to be understood in breadth; bottom-up problem solving results in well-crafted components; reading code teaches the aesthetics of writing good code; iterative development removes the fear of failure by minimising its costs; testing code helps us to understand the nuances of quality.
However for me the mistake Agile makes is to focus on competence to the exclusion of mastery, which is compounded by the drive to automate many things which junior developers should be doing manually. In essence Agile is strong on the concerns of value to businesses but it places little value on the long-term development of the individual software artisans who habitually comply with its strictures.
The hacker path is more erratic, and in many ways more demanding because of its lack of formality, but those who pursue it with commitment will master their craft.
I'd liken this to the difference between Parkour and an army assault course: the former is an art-form with very few limitations on where exponents can move whereas the latter is a means of teaching a group to get from A to B without mishaps along the way preventing them from reaching their goal. Probably starting with an assault course is a good way to develop some of the basic skills for Parkour, but mastering the assault course is no guarantee of being able to move beyond its limitations.
Would a Parkour runner be half as agile if burdened with a 60 pound pack and the dead weight of Private 1001011 who can never quite clear the cargo nets without additional help? Definitely not. In the gap between the two lies a lot more than the methodology of the latter can teach, and as craftspeople understanding the transition from the one to the other should be of importance to us
The trouble is, once you're a Parkour runner it's difficult to see the point in shifting that pack as most of what you'll need along the way is easily acquired with skills you already have mastered - and if you decided you were going to shift it for whatever reason, there's not much incentive to also want Private 1001011 involved in the process - the blighter's only going to slow you down and probably spend the whole time arguing with you over the best way to do things anyway.
Conversely when Private 1001011 becomes an assault course veteran he's already well served by the skills developed there and cannot see that mastery of that idiom is only a first step on the runner's path to complete freedom of movement.
If the purpose of Software Craftsmanship is to produce competent programmers to serve industry's needs then Agile methodologies should probably be centre stage because they're excellent for that. But if it's goal is to lead us to mastery of our craft so that we have the freedom to create any artefact we can conceive then it'd be nice to see a little less concern for methodology and a little more for the intrinsic curiosity and love of code that one needs to successfully pursue that path.
Ellie
Eleanor McHugh
Games With Brains
http://feyeleanor.tel
----
raise ArgumentError unless @reality.responds_to? :reason
Esko Luontola
If the purpose of Software Craftsmanship is to produce competent programmers to serve industry's needs then Agile methodologies should probably be centre stage because they're excellent for that. But if it's goal is to lead us to mastery of our craft so that we have the freedom to create any artefact we can conceive then it'd be nice to see a little less concern for methodology and a little more for the intrinsic curiosity and love of code that one needs to successfully pursue that path.
Anthony Green
On Sep 23, 1:55 pm, Eleanor McHugh <elea...@games-with-brains.com>
wrote:
> When I first started following the Software Craftsmanship movement I hoped it would take a rather different course than it has, recognising that formal practices can only help so far in the growth of a developer's skills and that what's also needed is an environment which promotes the acquisition of good instincts and aesthetics through thoughtful play. H
it reflects the majority of the individuals working in the field.
For those who aren't or those at the beginning their journey I take
comfort from the principles of Shuhari.
I liken it to other professions: as a medical student you don't get to
operate on patients until you've learnt informed good practices, but
you don't advance medical science by not pushing forward.
My experience is the polar opposite: I've seen so many BBoM created by
'lazy-arse hackers who delivered early' managers at a lost at how to
salvage them.
Tony
David Wilde
--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To view this discussion on the web visit https://groups.google.com/d/msg/software_craftsmanship/-/xFMLFIshQtUJ.
Eleanor McHugh
> On Sep 23, 1:55 pm, Eleanor McHugh <elea...@games-with-brains.com>
> wrote:
>> When I first started following the Software Craftsmanship movement I hoped it would take a rather different course than it has, recognising that formal practices can only help so far in the growth of a developer's skills and that what's also needed is an environment which promotes the acquisition of good instincts and aesthetics through thoughtful play. H
>
>> For this reason if given the choice between a pod of Extreme Programmers and two lazy-arse hackers of the old school to work on a project I will pick the latter every time, and their project will deliver both earlier and more successfully
>
> Even if we accept 'naturally talented developer' exists I don't think
> it reflects the majority of the individuals working in the field.
> For those who aren't or those at the beginning their journey I take
> comfort from the principles of Shuhari.
The Tao of Unix is enlightening on this matter [0] although I think St Paul perhaps does a much better job of expressing this in plain English (thanks to the KJV having influenced so much of our day-to-day speech):
"When I was a child, I used to talk as a child, think as a child, reason as a child; when I became a man, I put aside childish things. At present we see indistinctly, as in a mirror, but then face to face. At present I know partially; then I shall know fully, as I am fully known. So faith, hope, love remain, these three; but the greatest of these is love."
We begin our journey in the first full flush of wonder at the power of code, and from that wonder grows the hope that we may one day understand its many apparently inexplicable mysteries. Without hope we wouldn't take the first step, let alone have the strength to overcome the first obstacles on our path.
Some of us embark upon this journey alone, others in the company of friends, but in either case we do not travel far unless we fall in with those more knowledgeable than ourselves. In their company we develop faith in tools and processes, becoming deeply committed to the One True Way (whichever path they happen to believe this to be) and intolerant of those who will not yield to its obvious correctness. Later we may meet new companions who guide us to a different One True Way, the first abandoned as a dark stain upon our character.
At times our faith may be so strong that it moves mountains and dams chasms, at others doubts will ruin all we touch, but whilst it is faith which powers us we are doomed to repeat the same endless cycle, turning from one guru to another in search of enlightenment. This quest is ultimately futile and wisdom lies in its rejection not its perpetuation.
So hope begins our journey and faith sustains us whilst we lack the knowledge to recognise the many snares in our way, but only love can move us beyond these illusory tangles to the wisdom we seek - and true love by its very nature cannot be taught or inculcated. Without love we can encumber ourselves with all the rules and regulations mankind can devise but we might as well be blind, deaf and mute for all the good it will do us.
I can teach a young coder all the algorithms, katas and koans I like but unless that individual possesses the love of code necessary to explore and innovate of their own accord they will never be able to gain the skills that I take it for granted a competent hacker should possess. This has very little to do with natural talent - although without doubt someone who lacks the basic grasp of sequence, repetition, recursion and abstraction will struggle - but it does have everything to do with natural inclination.
Where Waterfall lead, Agile now follows. Developers who desired to make artefacts of quality tried to learn from others who had notable successes, but failing to understand that it's love and all which flows from it that gives birth to good systems they instead tried to enumerate processes and activities which they could replicate. A misguided but noble desire to learn from others has evolved into a cargo cult - the very same kind of FUD against which the early prototypers rebelled because they understood that process is only a means to an end, not the end in and of itself.
That's the point that the Tao of Unix conveys in its own eccentric way, or as The Simpsons once rather aptly put it "knife goes in, guts come out".
> I liken it to other professions: as a medical student you don't get to
> operate on patients until you've learnt informed good practices, but
> you don't advance medical science by not pushing forward.
I would not liken programming to a profession nor a career. Of the the three decades I've spent coding only two of them involved commercial practice, and that largely by accident.
> My experience is the polar opposite: I've seen so many BBoM created by
> 'lazy-arse hackers who delivered early' managers at a lost at how to
> salvage them.
You're confusing 'code monkey with delusions of grandeur' for 'lazy-arse hacker': the difference is clue and several thousand hours of coding experience (both writing and reading). I've worked with some amazingly skilful lazy-arse hackers over the years and I can't imagine circumstances in which any of them would willingly produce a BBoM, although working for balkanised management who actively prevent system requirements being identified for their own perverse reasons it does sometimes happen.
I've also worked with code monkeys, many of whom have seemed eminently well-qualified on paper but in practice understand sweet FA about computers, code or the crafting of beauty. Where possible I've tried to impart clue, however Matthew 22:14 is often depressingly apposite to our craft: "many are called, but few are chosen".
Ellie
[0] http:/catb.org/~esr/writings/unix-koans/methodology-consultant.html
[1] http://www.usccb.org/bible/1corinthians/1corinthians13.htm
David Starr
Scrum.org - Improving the Profession of Software Development
--
Rare Pleasures
> > I liken it to other professions: as a medical student you don't get to
> > operate on patients until you've learnt informed good practices, but
> > you don't advance medical science by not pushing forward.
>
> I would not liken programming to a profession nor a career. Of the the three decades I've spent coding only two of them involved commercial practice, and that largely by accident.
natural inclination to explore and innovate.
> You're confusing 'code monkey with delusions of grandeur' for 'lazy-arse hacker': the difference is clue and several thousand hours of coding experience (both writing and reading). I've worked with some amazingly skilful lazy-arse hackers over the years and I can't imagine circumstances in which any of them would willingly produce a BBoM, although working for balkanised management who actively prevent system requirements being identified for their own perverse reasons it does sometimes happen.
>
> I've also worked with code monkeys, many of whom have seemed eminently well-qualified on paper but in practice understand sweet FA about computers, code or the crafting of beauty. Where possible I've tried to impart clue, however Matthew 22:14 is often depressingly apposite to our craft: "many are called, but few are chosen".
innovative solutions on Hackdays but not be able to demonstrate how to
separate concerns and pull out domain models in a MVC stack. When I
watch Gary Bernhardt's screencasts his approach is comes across as
methodical, intuition-based but arrived at through disciplined
practice.
What I see as the debate gets polarised is a rhetoric increasingly
divorced from my day-to-day reality.
I've been fortunate to be mentored by a people who can 'hack' a Logo
interpreter in CoffeeScript and who've can also given me explanations
of Tell Don't Ask.
Perhaps rather than two distinct groups it's more like a Venn Diagram
of overlapping circles but whose edges are fuzzy. Recognising where
we're located amongst our peers provides signposts as to which
direction we might like to head next on our journey.
Tony