Independent in Detroit

I've been playing around with Sublime Text, which is a code editor with a very active community.  I thought it was nice, but after years of using Eclipse, no big deal.  However, some people whom I respect (the guys at Bitovi have turned me and several of my Coworkers on to it) insisted that it was the best editor for programming that you can find.

To decide for yourself, I recommend the videos that Jeff Way at Nettuts put together to improve your workflow.  Watch the first one (it's only 2.5 minutes long) to get a feel for whether it's worth watching any of the rest.  If you watch just a couple more, I'll bet you'll be hooked, though.

What do I like about it?  I'll summarize in terms that are the most important to me:

Multi-platform (Linux, Windows and OSX - all platforms I use regularly).You can open a folder and use it like a project.  None of the long tedious "import" BS that you have to do in Eclipse.Quick file and symbol searching.  (Seriously, I…

I just had a conversation with one of my teammates.  He's not happy with being seen as "The Javascript Guy", and prefers to be seen as a good all-around software developer.

He does make a very good point.  How much of our time should be as "generalists" and how much specializing in particular languages, libraries and toolkits?  How much time should we spend learning new things, vs time spent using the skills we have already built?

It isn't an idle question.  At the extremes, if you're constantly learning new things, you're always a newbie and not adding a lot of velocity to your project.  If you stick with the skills you have and apply only those skills, you will eventually be left behind by the march of technology, and obsolete as a developer.

My opinion is that the balance lies somewhere around 80/20, or even 90/10.  The majority of your time should be spent putting the skills you already have to good use.  I also think that the 10-20% time is s…

In a conversation with Patrick Welsh today, and his take on it was that a craftsman is someone who:

Writes small methods.Uses excellent names.Keeps modules small.Test drives code. The context of this is that it is possible to do all of these things in Javascript.  Claiming that JS is fundamentally different from Java (or any other modern language) is a poor excuse for not being a craftsman.
I tend to agree with him, and disagree with John Marx's statement that you can be a software craftsman without doing the above things.  I think that John's point was that technique != mindset.  My disagreement is that at the current time, using these techniques is the way to be a craftsman.  As techniques and tools evolve, the definition of craftsmanship will evolve.
What do you think?

I had a great discussion with one of my coworkers today.  He felt that we were adding a lot of noise to our current project due to the number of "fluff" people on our project.  In his opinion, anyone who wasn't spending most of their time on a keyboard (software developer, analysts creating stories, QA) is overhead.

Such people (which list includes me, BTW) have the following negative effects:

Communication overhead / Noise - people doing the actual work are often asked by multiple people how something works or why a particular choice was made.Meetings - we can be a source of meetings and other discussions apart from the "noise" above, if only to justify our time on the project.Duplication of effort - this has definitely happened to us.  More than one person steps up to get something done (analysis of a problem, breaking down & estimating a set of stories, etc.) and because we're not all communicating face-to-face, they don't work together on it.Cli…