<?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/"
		>
<channel>
	<title>Comments for One Lazy Programmer</title>
	<atom:link href="http://www.infusionsofgrandeur.com/assets/blog/?feed=comments-rss2" rel="self" type="application/rss+xml" />
	<link>http://www.infusionsofgrandeur.com/assets/blog</link>
	<description>Ramblings from an Average Joe Software Developer</description>
	<lastBuildDate>Wed, 19 Oct 2011 07:03:28 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1</generator>
	<item>
		<title>Comment on &#8220;Real Programmer&#8221; truisms, rules and maxims by programming</title>
		<link>http://www.infusionsofgrandeur.com/assets/blog/?p=12&#038;cpage=1#comment-3481</link>
		<dc:creator>programming</dc:creator>
		<pubDate>Wed, 19 Oct 2011 07:03:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.infusionsofgrandeur.com/assets/blog/?p=12#comment-3481</guid>
		<description>&lt;strong&gt;asp.net...&lt;/strong&gt;

[...]&#8220;Real Programmer&#8221; truisms, rules and maxims &#171; One Lazy Programmer[...]...</description>
		<content:encoded><![CDATA[<p><strong>asp.net&#8230;</strong></p>
<p>[...]&#8220;Real Programmer&#8221; truisms, rules and maxims &laquo; One Lazy Programmer[...]&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Fending off Attacks on Average Joe Software Developers by EricC</title>
		<link>http://www.infusionsofgrandeur.com/assets/blog/?p=70&#038;cpage=1#comment-3465</link>
		<dc:creator>EricC</dc:creator>
		<pubDate>Wed, 07 Sep 2011 16:28:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.infusionsofgrandeur.com/assets/blog/?p=70#comment-3465</guid>
		<description>I agree that the standards are different for independently developed apps done by a one man shop than enterprise level applications created, maintained and extended by a group of developers over the course of several years.

My comment about the app just working was said from the perspective of the user. The user doesn&#039;t care about design patterns or underlying architecture. If the program does what they need it to do and proves to be reliable, then they&#039;re happy.

I&#039;ve worked on all kinds of projects, big and small, with development teams of varying sizes. Bad practices can absolutely kill a project. But many a healthy project has been developed with less than ideal practices.</description>
		<content:encoded><![CDATA[<p>I agree that the standards are different for independently developed apps done by a one man shop than enterprise level applications created, maintained and extended by a group of developers over the course of several years.</p>
<p>My comment about the app just working was said from the perspective of the user. The user doesn&#8217;t care about design patterns or underlying architecture. If the program does what they need it to do and proves to be reliable, then they&#8217;re happy.</p>
<p>I&#8217;ve worked on all kinds of projects, big and small, with development teams of varying sizes. Bad practices can absolutely kill a project. But many a healthy project has been developed with less than ideal practices.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Fending off Attacks on Average Joe Software Developers by bartlomiej_n</title>
		<link>http://www.infusionsofgrandeur.com/assets/blog/?p=70&#038;cpage=1#comment-3464</link>
		<dc:creator>bartlomiej_n</dc:creator>
		<pubDate>Wed, 07 Sep 2011 10:17:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.infusionsofgrandeur.com/assets/blog/?p=70#comment-3464</guid>
		<description>Sorry, but I cannot agree with you at all... I am not sure what kind of software are you creating (is it some small apps for iOS only?), but this idea that &#039;it just needs to work&#039;, no matter of an internal quality has a chance only for small, one-developer projects. Additionally, the project would have to be a one quick shot and that&#039;s over - you sold it, forgot it.
In ANY other case, doing as you suggest is a suicide, or at least - shooting in your own foot.
It is not a matter of being &#039;elite&#039; to use well-known design patterns, generally understood idioms, syntax, naming conventions etc. It is just a matter of being a solid engineer, working in the team who pays respect to the other collegues.
It is also a matter of reducing a maintenance costs of the software in the future, minimizing a costs of introducing new people, assuring you have solid regression tests to keep existing features working and so on.
 
The code doesn&#039;t needs to be super-hiper-clever, but needs to be clean, self-explanatory, and overall architecture has to have a reason behind.
It can be done by the &#039;average&#039; developers, just not by those too lazy to care.
  

Personally, I came from enterprise Java world and I usually work with (or lead) teams - quick&amp;dirty  approach is no-go and would kill ANY project in longer term.</description>
		<content:encoded><![CDATA[<p>Sorry, but I cannot agree with you at all&#8230; I am not sure what kind of software are you creating (is it some small apps for iOS only?), but this idea that &#8216;it just needs to work&#8217;, no matter of an internal quality has a chance only for small, one-developer projects. Additionally, the project would have to be a one quick shot and that&#8217;s over &#8211; you sold it, forgot it.<br />
In ANY other case, doing as you suggest is a suicide, or at least &#8211; shooting in your own foot.<br />
It is not a matter of being &#8216;elite&#8217; to use well-known design patterns, generally understood idioms, syntax, naming conventions etc. It is just a matter of being a solid engineer, working in the team who pays respect to the other collegues.<br />
It is also a matter of reducing a maintenance costs of the software in the future, minimizing a costs of introducing new people, assuring you have solid regression tests to keep existing features working and so on.</p>
<p>The code doesn&#8217;t needs to be super-hiper-clever, but needs to be clean, self-explanatory, and overall architecture has to have a reason behind.<br />
It can be done by the &#8216;average&#8217; developers, just not by those too lazy to care.</p>
<p>Personally, I came from enterprise Java world and I usually work with (or lead) teams &#8211; quick&amp;dirty  approach is no-go and would kill ANY project in longer term.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Building Better iPad Tables by BiOM&#039;s iOS Page &#187; Blog Archive &#187; Library For iPad UITableViewCell’s With Multiple Dynamic Controls</title>
		<link>http://www.infusionsofgrandeur.com/assets/blog/?p=94&#038;cpage=1#comment-3463</link>
		<dc:creator>BiOM&#039;s iOS Page &#187; Blog Archive &#187; Library For iPad UITableViewCell’s With Multiple Dynamic Controls</dc:creator>
		<pubDate>Tue, 06 Sep 2011 04:03:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.infusionsofgrandeur.com/assets/blog/?p=94#comment-3463</guid>
		<description>[...] You can find more information on Eric’s website about the library here: Building Better iPad Tables [...]</description>
		<content:encoded><![CDATA[<p>[...] You can find more information on Eric’s website about the library here: Building Better iPad Tables [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on &#8220;Real Programmer&#8221; truisms, rules and maxims by Fending off Attacks on Average Joe Software Developers &#171; One Lazy Programmer</title>
		<link>http://www.infusionsofgrandeur.com/assets/blog/?p=12&#038;cpage=1#comment-3457</link>
		<dc:creator>Fending off Attacks on Average Joe Software Developers &#171; One Lazy Programmer</dc:creator>
		<pubDate>Thu, 14 Apr 2011 20:57:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.infusionsofgrandeur.com/assets/blog/?p=12#comment-3457</guid>
		<description>[...] are programmers out there, hmmm… what did I refer to them as a year ago? Oh, yeah, &#8220;Hotshot Superstar Software Engineers&#8220;… who desire to have the most pristine, optimized, streamlined code that always uses the [...]</description>
		<content:encoded><![CDATA[<p>[...] are programmers out there, hmmm… what did I refer to them as a year ago? Oh, yeah, &#8220;Hotshot Superstar Software Engineers&#8220;… who desire to have the most pristine, optimized, streamlined code that always uses the [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on What makes a Software Engineer &#8220;Senior&#8221;? by Trinity Treece</title>
		<link>http://www.infusionsofgrandeur.com/assets/blog/?p=22&#038;cpage=1#comment-3376</link>
		<dc:creator>Trinity Treece</dc:creator>
		<pubDate>Thu, 10 Mar 2011 21:45:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.infusionsofgrandeur.com/assets/blog/?p=22#comment-3376</guid>
		<description>Programming is not a zero-sum game. Teaching something to a fellow programmer doesn&#039;t take it away from you. I&#039;m happy to share what I can, because I&#039;m in it for the love of programming.</description>
		<content:encoded><![CDATA[<p>Programming is not a zero-sum game. Teaching something to a fellow programmer doesn&#8217;t take it away from you. I&#8217;m happy to share what I can, because I&#8217;m in it for the love of programming.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on What caused a Mac OS X Cocoa developer to defect to Windows and .net? by Tim S</title>
		<link>http://www.infusionsofgrandeur.com/assets/blog/?p=27&#038;cpage=1#comment-1135</link>
		<dc:creator>Tim S</dc:creator>
		<pubDate>Tue, 26 Oct 2010 22:16:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.infusionsofgrandeur.com/assets/blog/?p=27#comment-1135</guid>
		<description>One more thing: you don&#039;t have to do it &quot;the way users want&quot;, you can (and should) have a strong opinion about how it should be done. However, don&#039;t just do it some way and then say &quot;this is my opinion!&quot;, rather take some time to really think out your UI and develop an informed opinion. Spend a lot of time asking &quot;why?&quot; -- &quot;Why do I need to enter in people before I give them gifts?&quot;, &quot;Why are there so many columns of information?&quot;, &quot;Why should I display items in columns at all?&quot;</description>
		<content:encoded><![CDATA[<p>One more thing: you don&#8217;t have to do it &#8220;the way users want&#8221;, you can (and should) have a strong opinion about how it should be done. However, don&#8217;t just do it some way and then say &#8220;this is my opinion!&#8221;, rather take some time to really think out your UI and develop an informed opinion. Spend a lot of time asking &#8220;why?&#8221; &#8212; &#8220;Why do I need to enter in people before I give them gifts?&#8221;, &#8220;Why are there so many columns of information?&#8221;, &#8220;Why should I display items in columns at all?&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on What caused a Mac OS X Cocoa developer to defect to Windows and .net? by Tim S</title>
		<link>http://www.infusionsofgrandeur.com/assets/blog/?p=27&#038;cpage=1#comment-1134</link>
		<dc:creator>Tim S</dc:creator>
		<pubDate>Tue, 26 Oct 2010 21:18:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.infusionsofgrandeur.com/assets/blog/?p=27#comment-1134</guid>
		<description>Rather than focusing on functionality, try reducing the scope of features and make the UI for what you do *amazing*. Also, check out Getting Real, from 37Signals. It&#039;s a very fast read. 

Good luck!</description>
		<content:encoded><![CDATA[<p>Rather than focusing on functionality, try reducing the scope of features and make the UI for what you do *amazing*. Also, check out Getting Real, from 37Signals. It&#8217;s a very fast read. </p>
<p>Good luck!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on What caused a Mac OS X Cocoa developer to defect to Windows and .net? by EricC</title>
		<link>http://www.infusionsofgrandeur.com/assets/blog/?p=27&#038;cpage=1#comment-1131</link>
		<dc:creator>EricC</dc:creator>
		<pubDate>Tue, 26 Oct 2010 20:05:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.infusionsofgrandeur.com/assets/blog/?p=27#comment-1131</guid>
		<description>Don&#039;t get me wrong, I WANT users to absolutely love the program. I WANT it to do everything they want the way they want.

The distinction I make when referring to &quot;spoiled and whiny&quot; is the distinction between the user who says, &quot;yeah, I use this program because it helps me do something I want to do, though I wish it did it this way instead,&quot; and the user who says, &quot;I&#039;m not going to use this program at all, even though it would help me do something I want to do, because it doesn&#039;t do it the way I want it to.&quot;

I want to hear from the former user, and do what I can to improve his/her experience. The latter user is someone I don&#039;t think I&#039;m ever going to please and probably shouldn&#039;t spend much time trying.

Given time, I would certainly want to produce a UI that blew people away. However, I prefer to implement functionality first, and once the program does many (or most) of the things I think it should do, (based on my own input and that of others,) then focus on &quot;prettying it up&quot;.

I&#039;ll read those articles you linked and see what they say about the subject.</description>
		<content:encoded><![CDATA[<p>Don&#8217;t get me wrong, I WANT users to absolutely love the program. I WANT it to do everything they want the way they want.</p>
<p>The distinction I make when referring to &#8220;spoiled and whiny&#8221; is the distinction between the user who says, &#8220;yeah, I use this program because it helps me do something I want to do, though I wish it did it this way instead,&#8221; and the user who says, &#8220;I&#8217;m not going to use this program at all, even though it would help me do something I want to do, because it doesn&#8217;t do it the way I want it to.&#8221;</p>
<p>I want to hear from the former user, and do what I can to improve his/her experience. The latter user is someone I don&#8217;t think I&#8217;m ever going to please and probably shouldn&#8217;t spend much time trying.</p>
<p>Given time, I would certainly want to produce a UI that blew people away. However, I prefer to implement functionality first, and once the program does many (or most) of the things I think it should do, (based on my own input and that of others,) then focus on &#8220;prettying it up&#8221;.</p>
<p>I&#8217;ll read those articles you linked and see what they say about the subject.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on What caused a Mac OS X Cocoa developer to defect to Windows and .net? by Tim S</title>
		<link>http://www.infusionsofgrandeur.com/assets/blog/?p=27&#038;cpage=1#comment-1129</link>
		<dc:creator>Tim S</dc:creator>
		<pubDate>Tue, 26 Oct 2010 19:37:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.infusionsofgrandeur.com/assets/blog/?p=27#comment-1129</guid>
		<description>&quot;I also think it’s a sign of users being spoiled and whiny.&quot;

And this is why you fail.

You should be spoiling your users, treating them like they&#039;re worth spoiling. Do that, and they&#039;ll be fanatical about your product, no matter what it is. Trying to find less picky users rather than trying to make your product stellar is the absolute height of hubris, the &quot;I&#039;m right, and I&#039;ll find users who don&#039;t care!&quot; attitude isn&#039;t going to win people over, even less whiny ones.

I strongly suggest you read everything that Kathy Sierra wrote on her blog. Start here if you can&#039;t find a better place: http://headrush.typepad.com/creating_passionate_users/2005/06/featuritis_vs_t.html

Then, read Joel Splosky&#039;s User Interface Design for Programmers: http://www.joelonsoftware.com/uibook/fog0000000249.html

Then, when you&#039;re working on your Windows version or an update to your Mac version, keep them in mind. You want to make the experience not just EASIER for users than the alternative of using a pen and paper, but you want to make your users PASSIONATE about your product. If these aren&#039;t your goals, why bother?</description>
		<content:encoded><![CDATA[<p>&#8220;I also think it’s a sign of users being spoiled and whiny.&#8221;</p>
<p>And this is why you fail.</p>
<p>You should be spoiling your users, treating them like they&#8217;re worth spoiling. Do that, and they&#8217;ll be fanatical about your product, no matter what it is. Trying to find less picky users rather than trying to make your product stellar is the absolute height of hubris, the &#8220;I&#8217;m right, and I&#8217;ll find users who don&#8217;t care!&#8221; attitude isn&#8217;t going to win people over, even less whiny ones.</p>
<p>I strongly suggest you read everything that Kathy Sierra wrote on her blog. Start here if you can&#8217;t find a better place: <a href="http://headrush.typepad.com/creating_passionate_users/2005/06/featuritis_vs_t.html" rel="nofollow">http://headrush.typepad.com/creating_passionate_users/2005/06/featuritis_vs_t.html</a></p>
<p>Then, read Joel Splosky&#8217;s User Interface Design for Programmers: <a href="http://www.joelonsoftware.com/uibook/fog0000000249.html" rel="nofollow">http://www.joelonsoftware.com/uibook/fog0000000249.html</a></p>
<p>Then, when you&#8217;re working on your Windows version or an update to your Mac version, keep them in mind. You want to make the experience not just EASIER for users than the alternative of using a pen and paper, but you want to make your users PASSIONATE about your product. If these aren&#8217;t your goals, why bother?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

