1. I find funny
2. I find asinine
3. I find insightfully true
4. And stand on their own, with little to no comment needed

And launch as soon as you can, so you start learning from users what you should have been making.
...
So when you look at something like Reddit and think "I wish I could think of an idea like that," remember: ideas like that are all around you. But you ignore them because they look wrong.
...
Here it is: I like to find (a) simple solutions (b) to overlooked problems (c) that actually need to be solved, and (d) deliver them as informally as possible, (e) starting with a very crude version 1, then (f) iterating rapidly.

I've learned that developers who spend most of their time thinking about their project, rather than grueling over mundane tasks and busy work, do better. Their projects are stronger, easier to develop, and organized beautifully. These developers spend much of their free time doing things like evangelizing the MVC paradigm, reading non-fiction, and dining out. Their counterparts - those who fear the rush of extra web traffic, faulty error handling, and accidently falling into while() loops that never end - live in fear of their creation, dreading the day when it will turn on the parent.

1. I find funny
2. I find asinine
3. I find insightfully true
4. And stand on their own, with little to no comment needed

At this stage, if you've heard of Rails and you haven't converted, it's entirely possible that you never will. It's also entirely possible that anybody who still isn't even taking Rails seriously by this point might just be some kind of idiot.
...
Every programmer should also read Chad Fowler's "My Job Went To India" book, where he explains that as larger and larger numbers of programmers adopt a particular skill, that skill becomes more and more a commodity. Rails development becoming a commodity is really not in the economic interest of any Rails developer. This is especially the case because programming skill is very difficult to measure, which - according to the same economics which govern lemons and used-car markets - means that the average price of programmers in any given market is more a reflection of the worst programmers in that market than the best. An influx of programmers drives your rates down, and an influx of incompetent programmers drives your rates way the fuck down.

Instead, I want to talk about my first attempt at solving the puzzle, which was an utter failure. A glorious, spectacular failure. Perhaps the single most impressive failure of my career. Failures are often much more interesting than successes, but for some unfathomable reason, people are often reluctant to discuss them.

Me: read file blah.txt and display it on system output
Java: How should I name the class?
Me: Test
Java: How should I handle errors?
Me: I don't care right now, I just need to display that data to system output
Java: But I need to know this, what if something unexpected happens?!
Me: I just want to make a prototype damn it!
Java: Sorry, can't do it.
Me: Ok, do nothing on error.
Java: And which implementation of Stream class should I use for reading?

Everyone knows that diversification is the key to managing financial risk, but few people seem to apply this principal to their professional careers. Most developer shops are relatively limited when it comes to the number of technologies and problem domains they deal with. If you want to diversify your resume without job hopping every year, then it makes sense to actively seek out technology experiences that are different from the ones you use in your day job.

Neal Ford and others have been talking about the distinction between dynamic and static typing as being incorrect. The real question is between essence and ceremony. Java is a ceremonious language because it needs you to do several dances to the rain gods to declare even the simplest form of method. In an essential language you will say what you need to say, but nothing else. This is one of the reasons dynamic languages and type inferenced static languages sometimes look quite alike - it's the absence of ceremony that people react to.

1. I find funny
2. I find asinine
3. I find insightfully true
4. And stand on their own, with little to no comment needed

In the software industry, we've been chasing quality for years. The interesting thing is there are a number of things that work. Design by Contract works. Test Driven Development works. So do Clean Room, code inspections and the use of higher-level languages.

All of these techniques have been shown to increase quality. And, if we look closely we can see why: all of them force us to reflect on our code.

That's the magic, and it's why unit testing works also. When you write unit tests, TDD-style or after your development, you scrutinize, you think, and often you prevent problems without even encountering a test failure.

Perhaps I've made it seem like I'm on the side of the pirates. Just to make it clear that I'm not sailing under the jolly roger: In my own view, piracy is wrong. It's wrong even when the people making and selling the game are senseless, self-destructive fools. It's wrong even if the game sucks. It's wrong if you're broke. It's wrong even if "you weren't going to buy it anyway." It's wrong and I don't do it, ever.

It is not my intention to preach at pirates and get them to change their habits. I'm not anyone's mum, and it's not my place to tell people how to act. I actually think that having lots of people repent of piracy right now would be horrible. The managers would conclude their monstrous policies were working, and we'd get a double helping of the same, forever after, in every game they put out.

Regardless of the approach taken, I definitely no longer believe that sprocs should play any significant role in any application. The current mandate in the software industry is to strive to lower costs by increasing developer productivity and ORM's clearly help to do this by eliminating the need to write and maintain countless simple CRUD sprocs.

It's definitely time for all of us .NET developers to abandon our convention sproc wisdom and start playing catch-up with the rest of the industry when it comes to using ORM's.

I am not at the mercy of some big up-front UML diagrams or "non-agile" models grounded in getting something wrong in its entirety and very thoroughly before you take measures to fix it (or even begin to detect it).

1. I find funny
2. I find asinine
3. I find insightfully true
4. And stand on their own, with little to no comment needed