Developing Upwards

I've gotten a number of requests lately to contribute only Python related material to the Planet Python feeds and to be honest these requests have both surprised and insulted me, but they've continued. I am pretty sure they've come from a very small number of people, but they have become consistent. This is probably because of my current habit of writing about NaNoWriMo every day and those who aren't interested not looking forward to having the rest of the month reading about my novel. Planet Python will be getting a feed of only relevant posts in the future, but I'm going to be honest: I am kind of upset about it. I don't care if anyone thinks it is unreasonable of me to be upset about it, because the truth is Planet Python means something to me. It was probably the first thing I did that I considered "being part of the community" when I submitted my meager RSS feed to be added some seven years ago. My blog and my name on the list of authors at Plan...

Coders focus on code. Coders focus on toolchains and development practices. Coders focus on commits and line counts. Coders focus on code, but we don’t focus as well on people. We need to take a step back and remember why we write code, or possibly re-evaluate why we write code. Many of us might be doing it for the wrong reasons. Maybe you don’t think there can be a wrong reason, and I’m not entirely sure. What I am certain of is that some reasons to code lend themselves to certain attitudes and weights about the code and other motivations might mandate that you take yourself more or less seriously. We’re taking the wrong motivations seriously and we’re not giving enough attention and weight to the reasons for code that we should. The most valid and important reason we can code is not what hackers think it is. A good hack isn’t good for its own sake. No programming language or tool is inherently better than another. The technical merits of the approach or of the individual ...

We use the word “diversity” and when we use a word we are packing up some concept as a thing . We can put that thing on a shelf and analyze it, talk about it, and use it like a hammer when we find a nail. Diversity, in this way, is defined as something other than the natural order. That is the result of labelling something: we define it as something that needs pointed out as distinct from the normal assumptions. Not that it is positioned as bad but we conceptualize things as the normal every day we’re used to and then diversify as this extra step we can take. Diversity is an added step. Diversity is optional. You should take this extra step, of course, but it isn’t inherent. But, here is where I’m finding I might disagree with the way we use this language because... Diversity is inherent. We live in a world reaching seven billion people and we are nothing close to  homogenous. The human race is colorful and varied and constantly surprising. You will never meet ev...

When you have a problem and you rush to colleagues, or strangers on IRC and mailing lists, you've got to present a problem they'll want to help you fix, and with all the information they need to fix it. You can't give them information they dont need, because any extra work filing through your unrelated code is going to reduce the chances anyone will put in the time to help you. We can state a few rules about seeking help with code. Ask the question clearly and don't be ambiguous about your intentions and requirements. If you need to include code, it needs to include all important context. Present the problem without reference to out-of-context issues. Don't come in with a link to your entire body of code telling us it doesn't work. What doesn't work is asking for help like that. Besides telling us exactly how things don't work, and what they are doing compared to what you are expecting, you need to give us code that specifically and only demonstrates the...