[LRUG] Difficult second album

[Roland Swingler]

> you can't really teach anybody anything ... You're on your own.

I understand where you're coming from on this, but I strongly disagree.

The fact that I think many people relate to this sort of pain means you're
definitely not "on your own".

I feels like you're confusing the fact that it is (a) teaching at this
non-intermediate level is several orders of magnitude harder and (b) that
it may not be relevant to everyone, with the fact that it can't and
shouldn't be attempted.

In terms of feedback around this sort of talk, what I'd be looking for is
zero introduction into why you're doing this or the 'theoretical' side of
things, unless actually new (which, tbh I'd guess you're probably not going
to come up with). Assume I've read every blog post and watched every
previous presentation on this subject. If you can come up with something
distinct and valuable from your own experience - "I've now done this five
times, here is how it has worked out for me" and shaping it into a cohesive
talk then I'd definitely be interested in hearing it. The problem is that
coming up with this sort of talk may take about 6-8 months preparation, and
not many people are willing to put in that much effort (understandably!)

My 2c

Thanks
R


On Mon, Oct 28, 2013 at 11:09 PM, Mark Burns <markthedeveloper at gmail.com>wrote:

> Thanks Paul,
>
> It's a good point, you're right. It's difficult to sketch out exactly how
> much information to convey and at what level to pitch it at.
>
> I like the siren call idea. If you see pattern A, you might want to try
> solution B.
> Solution D is also relevant, but maybe not until you start to get C
> happening.
>
> It would be good to express a few examples of well known maxims/idioms and
> what issues these solve. Along with situations where they may not be
> appropriate.
>
> Maybe with examples simple enough that anyone can imagine the progression
> through into larger and more complex systems, even if they haven't
> experienced that progression first-hand.
>
> Basically, I can't teach you Thai, Vietnamese or Japanese, but I could
> help you learn to spot the differences between them. You can learn a few
> greetings and recognize them when confronting them, but you're going to
> need to do some self study to learn anything of value, and you'll need to
> live there to be fluent.
>
> I think I'd probably want to focus more on aspects of moving away from
> monoliths if focusing on anything. Especially as that probably sounds
> closer to that title.
>
>
>
>
>
> On 28 October 2013 22:37, Paul Robinson <paul at 32moves.com> wrote:
>
>> On 28 Oct 2013, at 17:22, Mark Burns <markthedeveloper at gmail.com> wrote:
>>
>> > I've been brewing the idea of talking about moving from Rails apps of
>> the
>> > scale of 15 minutes blog post through monoliths into services, with a
>> view to separating completely and maybe replacing components (with eek,
>> dare I suggest, maybe non-ruby components) with messaging and queues and
>> the like.
>>
>>
>> The problem with this as a talk is that you can't really teach anybody
>> anything. Not because you can't teach anything, but because people only
>> learn what is relevant to them, and it's probably impossible to structure a
>> talk that is relevant to lots of people who are at this point in their
>> app's life cycle.
>>
>> If I want to teach you how to use Rails to build a blog, well, OK, I can
>> do that. I can give you Railscasts that show you how to use gems and how to
>> do certain things. That's easy.
>>
>> And then you get to a point where you're on your own. You have to go back
>> to the theory and the abstract stuff floating around in the community and
>> look carefully at the problem domain and figure it out by thinking it
>> through.
>>
>> Nobody can help you. You're on your own.
>>
>> So whilst your talk would perhaps be interesting and act as a siren call
>> to those who are about to hit those problems that O'Reilly and Pragprog.com
>> aint going to be able to help them out much for much longer, what they
>> would expect from such a talk might only actually be given via a few weeks
>> consultancy.
>>
>> I'm not trying to say don't do it, I'm saying reduce the scope a little
>> if you want to make it a talk.
>>
>> And if you're not convinced, I'm happy to shoot the breeze about these
>> ideas and others. I'm a CTO, have been a CTO, and consulted as a CTO after
>> many years of working as a straight-up developer. The horror stories I
>> could tell you about the exact moment we're talking about here... oh boy...
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20131029/53865928/attachment-0003.html>