Fear, Uncertainty, and Doubt

The python community thrives on discussion. Like really, long, heated discussion. Python is by far the cleanest and most artistic language I have ever seen, and the CPython API is equally as impressive. I've actually become very entertained the last several months just by reading discussions about language design, most prominently about discussions regarding the GIL. Sometimes the discussions get pretty heavey, and a lot of times participants get a little fired up. Recently I wrote the following response to this blog post, which you may have read on planet python:

Python 3.0: “What’s the Point”

My response:

There are two opposing forces here, and you can see them just as well in discussions about the GIL.

The first one is the progressive and more open-source oriented mentality that promote better features and cleaner code. These are the people that hang out on IRC, write really cool extensions, and generally have a very academic and intimate knowledge of the python api.

The second one is a more practically goal and business oriented mentality, that promotes stability and proliferation. These people are more often than not getting paid to write the specific chunk of code in which they choose to discuss, and are blessed with not having to worry about the imperfections of the code as long as they make their deadlines.

There will always be a compromise between these two forces. I like to fall into the first category, preferring to take my time with unit tests and a detailed understanding of my code, because I do not enjoy going back and fixing concepts that should have been completed the first time. But, I don't get paid for my clean concepts, I get paid to meet deadlines and to be able to maintain the code I've written.

Your code doesn't need to be perfect to have fun AND make money, and your language doesn't either. But, you also need to have that bleeding edge branch to keep the spirit of the craft alive. I've never used ruby, and I'll never write java again, but one thing I can say about the python community is that there is a very large number of people that are involved in discussions across the spectrum, and this is nothing but healthy for the language, just like bleeding edge 3.0 releases and easily maintainable 2.5.1 XServe releases.

Oh yeah, and in the words of the BDFL, "CODE TALKS." This applies to both groups.

Writing and Selling a Small Commercial Product

So let's say you are a smart little developer that has an idea for a small niche software product. You're thinking you could spend X number of hours putting together your nifty tool, and then publish it on your web page with a commercial license, and maybe an open source license as well. What sort of hurdles would you expect to run into? Would bug fixes be too much of a bother? Does publishing your code under an open source license help with these bugs? Just how easy is it to sell your code and publish it for free at the same time? Is it feasable to put into your commercial terms a clause limiting your liability for use of your code? Would selling a well-constructed piece of software make you more attractive to prospective employers? How often has a single person done this (I know Jules did when he wrote juce)? Lot of questions!

Having worked in the audio world for a couple of years I've got a couple of ideas for tools and wrappers I'd like to write and sell for a little extra cash in between jobs, so naturally this idea is interesting.

Does Remote Work Imply Strong Encapsulation?

We have a C++ project with three primary developers. The managing developer #1 is in L.A, developer #2 is in Berlin, and I am in Anchorage. The manager works with the boss and product designers and developer #2. I work with developer #1, and almost never interact with developer #2 in Berlin because of the language barrier and because our work rarely overlaps. I have next to zero interaction with anyone else like the boss or product designers.

The problem is that I am afraid to add new features because the trunk is so fragile. I am constantly stepping on the manager's toes by committing test code right before a beta release, or writing code that doesn't work with this or that platform nuance, and all of these problems happened because I was just plain out of the loop. We have no online forum or dog bowl to establish a sense of community, and what's really bad is that I can't write anything interesting that isn't 100% in line with the manager's current priority 1 bug for fear of getting a stressed out phone call from him. This includes cleaning up our mistakes from the start-up period, and writing example python scripts for our new scripting engine, of which no one understands how to use correctly. All three of our code styles are completely different, and there are strange looking blocks of code that have no comments explaining the obscure bugs they fix. I also haven't been to LA to see them in 1.5 years.

So my question is, does working remotely imply that your role works like a black box, strongly encapsulating your function to avoid conflicts? Should I be given more interfaces to deal with, or should my manager work to provide this encapsulation? If you were to meet with your co-workers every, say 1 out of 6 months, how much would this affect your encapsulation? One month out of the year? As developers we can certainly work remotely, but at what point do you start to lose motivation as minion of many, and what can you do to promote interesting creative, and motivating work? I can't add interesting features or do anything other than feel like a robot intern lapping at the task pellet feeder, and being a motivated programmer I find this mind-numbing, and I want to quit.

What are your experiences? Thoughts?