Perhaps. I tend to believe it's more of a difference between an overall healthy organization and an unhealthy one. An unhealthy one will take a good boss and ruin him. A healthy one will purge bad boss's and make good boss's better.

Hi Mark,
Community Edition is downloadable. Just go to the community edition site (http://trisano.org/) to get it.

Feel free to join us in irc (freenode/trisano) if you have any questions about downloading/installing.

Thanks!

Dave

You're right Mark. Here's an updated link to the TriSano product site (we've renamed the product since this post). I hope that helps!

http://csinitiative.com/products/trisano/overview...

You know the saying that the exception proves the rule? This is definitely one of those moments. If you have to find an example that extreme as an (apparent) argument against this post, it is powerful evidence that it's a good rule.

Well Dennis, that may be your bottom line but it's not mine. I'm much more concerned about the long term impact of a job I hate on my health, wealth, and happiness than I am about a paycheck.

That said, the pay is about the same. One major difference though - if we're successful there's a heck of a lot more upside than in IT. Conversely, failure is a lot rougher too.

Hi Jim,
While this is perhaps not as detailed an analysis as you'd like, here are the differences that have been important to me:
1) I feel valuable to the company. I'm not treated like a cost center anymore - I think this is because I'm not. I'm directly tied to my company's revenue.
2) People listen to my recommendations. I don't always win, but when I lose it's because of what's best for the company, not because of what's politically expedient for my management chain.
3) I like my work. A lot of this is because of how important it is that we stay current. We're always close to the edge, and that is fun.
4) I don't have a lot of meetings. When we meet, it's because we have to, not because it's someone's mandate or best practice.
5) My leaders understand my job and actually grok the issues I face.
6) My leadership is under the same pressure to stay current in their responsibilities as I am and they do it.
7) We focus on execution and delivery.
8) We have simple, effective communication channels.

None of these things were true in any of the corporate IT work I've done.

Oh yeah, thought of one more:
9) We don't carry ANY dead weight. We are very careful who we hire and we don't keep low performers around.
Dave

That's a good idea Adam. I think I'll mess around with that. When I test our Enterprise Edition version I don't have to worry about that because the build process creates a working copy that is outside of git, but it's an issue with our Community Edition.

C'mon Jim. Don't you ever find a bug in the work of someone who is a friend of yours and think "Hah - this is such a stupid bug I can't _wait_ to tease Mac about it"?

I agree with your assertion that testing is good for the team, but I'm also acknowledging that finding bugs is fun, partly because sometimes the bugs you find embarrass your buddies.

That's so awesome. I love you true-to-the-faith context guys. I'm not being facetious - I really do.

I should have had something in the list about context trumping everything because I totally agree with you, but I didn't really intend anyone to take me seriously. I think everything on the list is a good tip under the right circumstances, but I was really just trying to poke fun at best practices by making ten of them up in less than two minutes.

1) The devs I work with are not offended when I find bugs. They sometimes feel stupid about the bugs I find, but that's not the same thing. Other devs I've know in the past are a different story.
2) I like them both. It's fun to balance them out a bit. I do a lot of hobby-coding (trooptrack.com) and I like it too. But it doesn't have the guilty pleasures of attacking someone else's work product the way testing does.
3) Yup.