<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: The He-Man Muggle Haters Club for Programmers (part 2)</title>
	<atom:link href="http://improvingsoftware.com/2009/06/22/the-he-man-muggle-haters-club-for-programmers-part-2/feed/" rel="self" type="application/rss+xml" />
	<link>http://improvingsoftware.com/2009/06/22/the-he-man-muggle-haters-club-for-programmers-part-2/</link>
	<description>Upgrading the software development process one reader at a time.</description>
	<lastBuildDate>Tue, 01 May 2012 06:08:29 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: johnfx</title>
		<link>http://improvingsoftware.com/2009/06/22/the-he-man-muggle-haters-club-for-programmers-part-2/#comment-237</link>
		<dc:creator><![CDATA[johnfx]]></dc:creator>
		<pubDate>Tue, 07 Jul 2009 00:34:02 +0000</pubDate>
		<guid isPermaLink="false">http://improvingsoftware.com/?p=983#comment-237</guid>
		<description><![CDATA[Very good arguments. I appreciate your thoughtful response.]]></description>
		<content:encoded><![CDATA[<p>Very good arguments. I appreciate your thoughtful response.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: thehappymoron</title>
		<link>http://improvingsoftware.com/2009/06/22/the-he-man-muggle-haters-club-for-programmers-part-2/#comment-236</link>
		<dc:creator><![CDATA[thehappymoron]]></dc:creator>
		<pubDate>Mon, 06 Jul 2009 23:13:48 +0000</pubDate>
		<guid isPermaLink="false">http://improvingsoftware.com/?p=983#comment-236</guid>
		<description><![CDATA[You&#039;re spot on with regards to what programmers want, but I think you&#039;re off-base as to why.

I&#039;m not afraid of making something easy. 

A task is either truly easy/simple or it&#039;s not. If it really is that simple, I want to get as far away from it as I can, because someone *will* write a magic tool (hey, it&#039;s easy!) and then I *will* be out of a job. 

It&#039;s possible some programmers make a living out of easy tasks, and their livelihoods will be threatened by better tools. But I don&#039;t think they&#039;re the reason that programmers don&#039;t have good tools.

Programmers who write tend to be great programmers, because they are the programmers who know about their tools, care about their tools, and spend the time and energy to actually write better tools.

So the programmers writing tools are not the ones feeling threatened by magic tools. 

Why aren&#039;t they writing magic tools?

If a task is not really that easy, oversimplifying it will make things worse. I&#039;ll find myself hand editing auto-generated code and working against my tools. I believe this is why programmers hate drag &#039;n drop. 

You need to look at an application over its entire lifetime. Will it need to be extended? Maintained? Wired up to another application? Ported?
Magical tools can incur great technical debt.

I&#039;m not resentful of someone who drags &#039;n drops. I have nothing against other people being productive. But if what they&#039;re doing actually is complicated enough to be programming, drag n&#039; drop is not the tool for the job.

Writing a framework (as opposed to a tool) is more of a programmer&#039;s answer to the problem, and there are lots of frameworks for dealing with CRUD apps.

A few additional random thoughts:

Text is portable; source code is an extremely simple (if not greatly usable) representation of a program&#039;s implementation. As a programmer I really, really want to minimize the amount of tool metadata that I need to worry about.
Tool specific metadata means tool lock-in. (Oracle Forms is a good example)

I think Ruby on Rails is a very good example of how &#039;fine-tuning&#039; can lead to a *more* inclusive programming environment. If you want to support magical tools, you need powerful languages.]]></description>
		<content:encoded><![CDATA[<p>You&#8217;re spot on with regards to what programmers want, but I think you&#8217;re off-base as to why.</p>
<p>I&#8217;m not afraid of making something easy. </p>
<p>A task is either truly easy/simple or it&#8217;s not. If it really is that simple, I want to get as far away from it as I can, because someone *will* write a magic tool (hey, it&#8217;s easy!) and then I *will* be out of a job. </p>
<p>It&#8217;s possible some programmers make a living out of easy tasks, and their livelihoods will be threatened by better tools. But I don&#8217;t think they&#8217;re the reason that programmers don&#8217;t have good tools.</p>
<p>Programmers who write tend to be great programmers, because they are the programmers who know about their tools, care about their tools, and spend the time and energy to actually write better tools.</p>
<p>So the programmers writing tools are not the ones feeling threatened by magic tools. </p>
<p>Why aren&#8217;t they writing magic tools?</p>
<p>If a task is not really that easy, oversimplifying it will make things worse. I&#8217;ll find myself hand editing auto-generated code and working against my tools. I believe this is why programmers hate drag &#8216;n drop. </p>
<p>You need to look at an application over its entire lifetime. Will it need to be extended? Maintained? Wired up to another application? Ported?<br />
Magical tools can incur great technical debt.</p>
<p>I&#8217;m not resentful of someone who drags &#8216;n drops. I have nothing against other people being productive. But if what they&#8217;re doing actually is complicated enough to be programming, drag n&#8217; drop is not the tool for the job.</p>
<p>Writing a framework (as opposed to a tool) is more of a programmer&#8217;s answer to the problem, and there are lots of frameworks for dealing with CRUD apps.</p>
<p>A few additional random thoughts:</p>
<p>Text is portable; source code is an extremely simple (if not greatly usable) representation of a program&#8217;s implementation. As a programmer I really, really want to minimize the amount of tool metadata that I need to worry about.<br />
Tool specific metadata means tool lock-in. (Oracle Forms is a good example)</p>
<p>I think Ruby on Rails is a very good example of how &#8216;fine-tuning&#8217; can lead to a *more* inclusive programming environment. If you want to support magical tools, you need powerful languages.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: The He-Man Muggle Haters Club for Programmers (part 1) &#171; Software++</title>
		<link>http://improvingsoftware.com/2009/06/22/the-he-man-muggle-haters-club-for-programmers-part-2/#comment-221</link>
		<dc:creator><![CDATA[The He-Man Muggle Haters Club for Programmers (part 1) &#171; Software++]]></dc:creator>
		<pubDate>Tue, 23 Jun 2009 00:34:59 +0000</pubDate>
		<guid isPermaLink="false">http://improvingsoftware.com/?p=983#comment-221</guid>
		<description><![CDATA[[...] The He-Man Muggle Haters Club for Programmers (part&#160;2)  [...]]]></description>
		<content:encoded><![CDATA[<p>[...] The He-Man Muggle Haters Club for Programmers (part&nbsp;2)  [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

