I was hoping to play around with some Python graphics tools today and wanted to start with PyGame. I was re-reading my June Python mag with the article on PyGame which is where I got the spark to play.
Then I ran into MacOS 10.5 issues around PyObjC. Still sifting through the posts and official news but this one seems whacky. Ironic that that issue of the Python mag had an article on PyObjC and one on continuous integration.
Monday, July 28, 2008
Tuesday, July 22, 2008
Sliding scale of competence
Throughout most of my bioinf career, the skill level of programmers I've encountered has either been at the level of God or Rob. Those two points being relatively far apart.
Those who were on my level could write simple scripts that could run out of the current directory and relied on the system perl install. Ask us to put something in our path and we showed the confused face and maybe blurted out "I'm more of a biologist, I don't care about a path, just help me get it to work.". God programmers were everyone else who knew what the path was and how to use it.
As I got a bit more skilled, I separated myself a little from the Rob's and assumed I was closing in on God. I recognize these folks now in the mailing lists when they correct the old-timers in such a loving camaraderie sort of way.
As I got a bit further along, I actually became capable of writing software - not much, but it was definitely beyond scripts running out of the current directory. This seems to be where things changed for me. I was now interacting with people that I could place in the "pretty good" category as well as those that I considered God for reasons other than knowing how to add something to PYTHONPATH and why that was different from PATH. On a project that shall remain nameless, I ran into s spectrum of people where I fit somewhere in the middle, but with at least one big outlier...
The dude with the high skill level could write stuff like nobody's business. Unfortunately, it often became nobody's business because no one else could really get it. The code was slick with lots of what people at my level call "magic", and people at his level call "optimized".
At first glance, one would think "what an asset to the project to have that guy on board". That is true to some extent, but that guy also gets bored of acting as the teacher and would rather work with people at their own skill level. The project risks them wandering off or becoming electronically absent. Another risk which could be compounded by this departure is that the less skilled folks become dependent on the God to answer all their questions. As the project wore on, there was a lot of complexity built into the code which was a great experience for those of us learning, but we couldn't actually maintain that code or that pace. A division grew between the teacher and the students and the project suffered.
I was left with the question of what is the best mix of people on a project? Everyone wants to have a situation like what Fog Creek appears to be - everyone at a high skill level, learning even more, making great software. I doubt I'll ever be in that situation so I'm ignoring those sorts of projects. I need to finish this idea later while I chew a bit more on it now...
Those who were on my level could write simple scripts that could run out of the current directory and relied on the system perl install. Ask us to put something in our path and we showed the confused face and maybe blurted out "I'm more of a biologist, I don't care about a path, just help me get it to work.". God programmers were everyone else who knew what the path was and how to use it.
As I got a bit more skilled, I separated myself a little from the Rob's and assumed I was closing in on God. I recognize these folks now in the mailing lists when they correct the old-timers in such a loving camaraderie sort of way.
As I got a bit further along, I actually became capable of writing software - not much, but it was definitely beyond scripts running out of the current directory. This seems to be where things changed for me. I was now interacting with people that I could place in the "pretty good" category as well as those that I considered God for reasons other than knowing how to add something to PYTHONPATH and why that was different from PATH. On a project that shall remain nameless, I ran into s spectrum of people where I fit somewhere in the middle, but with at least one big outlier...
The dude with the high skill level could write stuff like nobody's business. Unfortunately, it often became nobody's business because no one else could really get it. The code was slick with lots of what people at my level call "magic", and people at his level call "optimized".At first glance, one would think "what an asset to the project to have that guy on board". That is true to some extent, but that guy also gets bored of acting as the teacher and would rather work with people at their own skill level. The project risks them wandering off or becoming electronically absent. Another risk which could be compounded by this departure is that the less skilled folks become dependent on the God to answer all their questions. As the project wore on, there was a lot of complexity built into the code which was a great experience for those of us learning, but we couldn't actually maintain that code or that pace. A division grew between the teacher and the students and the project suffered.
I was left with the question of what is the best mix of people on a project? Everyone wants to have a situation like what Fog Creek appears to be - everyone at a high skill level, learning even more, making great software. I doubt I'll ever be in that situation so I'm ignoring those sorts of projects. I need to finish this idea later while I chew a bit more on it now...
Friday, July 18, 2008
APIs and Doctesting
So my student and I (alright my student), are writing a Python version of the Ensembl API as a Google Summer of Code project. She's at a decision point that will require some head-scratching so while that is going on, we're going to do some testing.
My previous place of employment had created an API for this home-grown LIMS system, both of which were written in Perl. They created lots of documentation using POD and included examples of how to use the methods. The problem was that the examples quickly became outdated with new releases and were of ultra-low priority compared to delivering new features.
I was showing my student a bit of how doctests can accomplish this very thing, but because they act as automated tests, they can be kept up-to-date more easily because it's easy to know if they ever become broken. Those who work with doctests have known this for a long time, but I marvel at the match made in heaven when it comes to writing an API. I heart you Python Doctests.
My previous place of employment had created an API for this home-grown LIMS system, both of which were written in Perl. They created lots of documentation using POD and included examples of how to use the methods. The problem was that the examples quickly became outdated with new releases and were of ultra-low priority compared to delivering new features.
I was showing my student a bit of how doctests can accomplish this very thing, but because they act as automated tests, they can be kept up-to-date more easily because it's easy to know if they ever become broken. Those who work with doctests have known this for a long time, but I marvel at the match made in heaven when it comes to writing an API. I heart you Python Doctests.
Subscribe to:
Posts (Atom)
