Hello, I’m Jim Van Fleet

My friends call me @bigfleet.

about me

I make computers do what I want, more or less.

I am looking for full-time employment.

I cofounded PitchBreakfast with Vic Howie.

I cofounded Code for Charlotte with Jill Bjers.

I’ve published a newsletter for Charlotte startups for over two years.

I’ve attended or co-organized every Charlotte Startup Weekend.

recent public projects

Status updating…

found on

contact at

jim@jimvanfleet.com

Hacker News | That Was One of the Things That Really Surprised Me About the Real World: That B…

- -

Hacker News | That was one of the things that really surprised me about the real world: that b…:

Nostrademons writes:

“That was one of the things that really surprised me about the real world: that big advancement only comes from big lateral jumps. Different companies, different projects, different markets, or different customers. There’s this model of the world we’re taught as schoolkids - at least where I grew up - where you work hard at something, do as your told, and slowly but surely you rise up. And maybe at one level it’s true, but it’s very slow, and you’ll never become the sort of success you read about in the paper that way.

Instead, I’ve found that what usually happens is that you join an organization because you meet some minimum skill baseline that they’re looking for. And then as you practice and learn from the people around you, you end up picking up a bunch of other skills and getting better at your job. But the people around you generally won’t notice. First impressions usually pigeonhole you into a general category, and then people are blind to gradual changes.

So to reap the rewards of everything you’ve learned, you have to expose yourself to new people. Jump ship, and suddenly you seem really valuable to them, because all those skills you’ve picked up which your current organization takes for granted are new and useful.

There’s a leverage effect as well: people try to work with others of roughly the same level. If you’re diligent about practicing, you’ll go from being (hopefully) near the bottom of your team to the top of it. If you then repeat the process, your new teammates better be higher skilled still, and so your team as a whole can tackle more ambitious problems.”


Unless you work very hard at your communications within the organization, this is a very likely outcome. It may even be inevitable. Embrace it.

(Via @peteforde.)

Ben Rockwood on Devops

- -

The Blog of Ben Rockwood:
When I first came in contact with the ‘Devops’ movement I thought it was about better systems administration, a maturing of the craft. It was, I thought, more about Ops and less about dev. Dev had their day in the sun with Agile… now sysadmins were getting theirs. Remember, if you can, when Agile came on the scene and how giddy developers got with eXtreme Programming, then Pragmatic Programmer books are everywhere, and then SCRUM comes along, and its all about this ‘lets do the old thing, in the new way’ excitement. Re-inventing the craft for a new age. I thought devops was that.
I’ve been following Ben for a long time, since he was doing podcasts (ps pipe grep!) with the other Joyent knuckleheads in 2007. I enjoyed reading this post, although it highlights how wide ranging the term “Devops” can be. My background couldn’t be more different. I started by only learning enough system administration to help run the Rails applications I wrote, and now I find myself looking at a trend in the server-side part of the operation that I think is very promising. It’s not in the form of “what Devops means to me” but my post on Chef from about a year ago still captures what I think Devops has to offer the rest of the development stack, leading right up to the business. My experience is that the business is the customer of the developers, and the developers are the customers of ops. Successful devops can use either their experience as developers or their knowledge about the depth and breadth of systems to guide the process of putting together a high quality stack to meet business goals on the budget provided. I personally do not share Ben’s fear of having “hot Devops” take jobs from specialists– specialists are part of the team just the same. With all these differences in approach and background, we still end up with a very similar idea:
As the good news of “devops” spreads it first enlightens, then brings excitement, then dread. If your one of those “specialists”, you can easily feel that your now out-dated. Consider that there is now pride within the devops elite that CIO’s are now talking about having a “devops strategy”. Some even suggest a (I’m paraphrasing) “evolve or die” scenario for operations teams. If your a sysadmin who uses Borne or Korn shell instead of Ruby, look out! I don’t think that’s fair, nor do I think its true for all. Instead, it all makes more sense when you see it as three camps instead of two, with a the culture over the three… that is, applications developers (traditional “dev”), system administrators (traditional “ops”), with a new role in the middle of Systems Engineers that helps glue the camps together. Some of your Systems Engineers will emerge from the dev side, some from the ops side, always having hidden their secret urges to do both. And, as with any emergent role, many will aspire to it but simply not be cut out for it.
I am a “smallest team possible” sort of guy, so I happen to think that considering them three different cultures is a bit much, but I think it should be obvious that more and more recognized roles in engineering are popping up around communication. It’s a good thing!

A Letter to the Editor of Charlotte Magazine

- -

Thank you for your coverage of the regional conference scene in Charlotte in your piece ”Rhetorical Revolution”. This piece touches on some very important areas for the future of Charlotte’s technology culture. To critics of BarCamp labelling its content as “elitist b.s.”, I claim your position is, to be generous, underinformed. No talks are scheduled ahead of time– anyone who wishes to speak must convince the attendees that his or her talk is worth attending. Whoever shows up for the event determines what will be discussed in true democratic style, with every vote counting equally. I’m not aware of a more open, less elitist format for a conference. Indeed, even their technical nature is in question from event to event. Social Media Terrorism and making balloon animals have been among the most popular presentations in the event’s history. The contrast with an event featuring a set of invited speakers and curated attendance list should be obvious. As a community, we should be happy both formats exist here in the city. I’m confused by the article’s conclusion: that these events ought themselves to lead to the incubation of startups. The tension between the desire for the audience not to “be pitched” and to simultaneously result in city-changing startups seems irreconcilable. Although they do not fit the profile of the events listed in your article, if your readers are looking for startup activity in Charlotte, I’d direct them to the Twitter accounts @CLTLaunch and @CollaborateCLT, which both have practical, hands-on advice for all start-ups as a part of their mission. Finally, I’d encourage all Charlotte Magazine readers to attend the events, engage with the speakers, and pitch your own sessions. Participate in this open discussion about your city’s future, and you’ll have an impact.

Marketrol!

- -

The world's first self-marketing medication!Genius.

Internet Age

- -

Would you be shocked?

Vegan Stephen Day!

- -

Vegan Stephen Day!: “You trusted a vegan and look what happened. Look at what happens when you trust Vegan Stephen.”

(Via GIRLS ARE PRETTY.)

I can’t remember the last time I recommended Girls Are Pretty, so here it is again.

Real Software Engineering - Glenn Vanderburg - Lone Star Ruby Conference 2010

- -

Real Software Engineering - Glenn Vanderburg - Lone Star Ruby Conference 2010:

Software engineering as it’s taught in universities simply doesn’t work. It doesn’t produce software systems of high quality, and it doesn’t produce them for low cost. Sometimes, even when practiced rigorously, it doesn’t produce systems at all. That’s odd, because in every other field, the term ‘engineering’ is reserved for methods that work. What then, does real software engineering look like? How can we consistently deliver high-quality systems to our customers and employers in a timely fashion and for a reasonable cost? In this session, we’ll discuss where software engineering went wrong, and build the case that disciplined Agile methods, far from being ‘anti-engineering’ (as they are often described), actually represent the best of engineering principles applied to the task of software development.

This is one of the finest talks I’ve seen in my time going to conferences. This version was given at the Lone Star Ruby Conference, but I had a chance to see it myself at Ruby Hoedown X in Nashville. Glenn and I also worked together on the project that brought me to Charlotte, originally. Thanks, Glenn!

Boompa.com Launch Postmortem, Part 1: Research, Picking a Team, Office Space and Money || kuro5hin.org

- -

Boompa.com Launch Postmortem, Part 1: Research, Picking a Team, Office Space and Money || kuro5hin.org: “Who’s the better shot? Give them the gun.

Ethan and I came up with the ‘Zombie Team’ test for figuring out whether or not someone is ready to work on an intense project, be it a start-up or otherwise. The test is this: If zombies suddenly sprung from the earth, could you trust the perspective team member to cover your back? Would they tell you if they got bit? Most importantly would you give them the team’s only gun if you knew they were the better shot? If the answer is no to any of those questions you need to let them get eaten by the cubicle wasteland of corporate culture, because they aren’t ready for this kind of work.”

(Via 25 Best Startup Failure Post-Mortems of All Time.)

A great excerpt from a great post. Go read it, seriously! As the site no longer resolves, I wonder what became of it.