Kevin LaTona wrote: > Is this thought about Seattle vs the overall Python marketplace?
I was talking nationally as opposed to Seattle in particular. Although that's worth considering: how does Seattle compare to the national average? My own impression is there are not a lot of Python jobs -- certainly much less than Java or .NET or PHP -- but there are enough for anyone who really wants one and tries for a few months. As to whether employers are getting their needs met -- that's what I was asking.We get various job listings on this list but we don't usually hear any follow-ups. On Wed, Nov 23, 2011 at 4:23 PM, Casey Durfee <[email protected]> wrote: > the vast majority of Python-related job postings I've seen in Seattle lately > have looked like they're intentionally trying to find people with very > narrow experience and brittle skillsets. In the cases I was talking about, the requirements are necessary. The person needs to work on a Python project in a team, and they need expertise in some other field like mathematics or mapping or oceanography. Otherwise the project can't be done. > If you self-identify as a "Python Developer" rather than just a developer, > my experience is you probably have a pretty brittle skillset. The stuff you > need to know to be a good developer isn't at all dependent on knowing > Python... I love Django and have used it for years, for instance, but > whenever I see "Django Developer" it's hard not to read it as "Web Developer > Who Doesn't Know Any SQL". > However, I know of at least 3 companies in Seattle hiring for a "Senior > Django Developer" or "Back-End Python Engineer" or some other long string of > modifiers like that right now. They're all small companies, so I don't > think you can blame it on HR cluelessness. It seems to be strongly a > Seattle thing -- jobs for developers who only know one type of development > work, using only one language or framework or whatever. ... > Are there actually good people who self-identify as a "Python Developer" > instead of a developer who happens to know Python? I'm sure there are but > personally I can't imagine considering a position like that -- too much org > chart smell. There are two issues here. One, what the programmer wants to do. Two, having a consistent toolset across an organization. I have worked in other languages and done other kinds of computer work, and in the late 90s it was hard to get a Python job (or my other interest, Linux). But then I got one Python job and then another and another, and they were so fun I couldn't turn them down. So I'll keep doing that until I can't get a Python job, and then I'll do something else. I have seen organizations that have put the (language) cart before the (task) horse, trying to shoehorn a project into a toolset that wasn't suited for it. I've also seen the opposite extreme, where they let developers use whatever they like and end up with a mishmash of dissimilar things. Too much rigidity makes for a bad product. Too much looseness makes for a maintenance nightmare, especially when the person leaves and other people have to maintain their code. It requires a balance between the two. The best balance I've seen is to have one primary language in the organization, and allow one or two others secondarily if (A) the developer prefers it or it has a special niche in the problem domain, *AND* (B) there's forethought about ongoing maintenance and not increasing the total number of languages/environments to an intolerable level. I have heard negative things about "Django jobs" and "Django developers". Like everything, you have to dig deeper to see if there's a legitimate reason for the narrow requirement or the person doesn't know any better. A good developer can convince the boss that another toolset would work just as well or better. But likewise, there are businessmen who know that a language is realistic for the project and want to go with what they like. Both of these are legitimate positions if they're not taken too far. -- Mike Orr <[email protected]>
