Monday, October 29, 2012

A Good Code Editor Is Easy To Find

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 can type command-P, part of a file name, "@" and part of a symbol to drill to a particular method in a particular Java class.  That's all kinds of awesome!)
I never much liked vi (though I can use it in a half-assed way), and I'm not all that thrilled with using a heavyweight IDE like Eclipse (the flakiness outweighs the benefits of having a continuous build too).

Now I can finally be one of those guys who is comfortable with just a shell and a stand-alone editor to do all of their programming work.  That's a level of nerd-cool that I have heretofore reserved for people like Magnus.

Maybe I should grow a beard.


Friday, October 12, 2012

Specializing Generalist: How Much of Each?

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 spent in bursts, so the reality is that I'll spend 99% of my time exercising skills I already have, and building just a but of new mental muscle.  Then I'll discover a need for new skills and spend 90% of my time learning *that* new thing, which slowly ramps down as I use it.

What do you think?  How "special" and how "general" should a good developer be?

Friday, October 5, 2012

What is software craftsmanship?

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?

Thursday, October 4, 2012

Death by Oversight: How much overhead is too much for an agile project?

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.
  • Climate of fear - feeling that you have to please a lot of people with different agendas can create a climate of fear, even if most or all of the people involved have good motives.
It was a compelling case, and I don't have any easy answers.  Some worth considering:
  • Make sure all of the "fluff" people are aware of the problems above!  Stating the problem clearly is the most important step in solving it.
  • Reduce the fluff by having some people step out of the project, or by changing their role to something other than a decision-maker.  (For instance, my role could be developer + management bitch for buying hardware & approving access to resources, and I can step out of most of the planning & oversight work.  Hmm... that actually sounds like a lot more fun than what I've been doing.)