How do you recognize a good programmer?
Guido: It takes time to recognize a good programmer. For example, it’s really hard to tell good from bad in a one-hour interview. When you work together with someone though, on a variety of problems, it usually becomes pretty clear which are the good ones. I hesitate to give specific criteria—I guess in general the good ones show creativity, learn quickly, and soon start producing code that works and doesn’t need a lot of changes before it’s ready to be checked in. Note that some folks are good at different aspects of programming than others—some folks are good at algorithms and data structures, others are good at large-scale integration, or protocol design, or testing, or API design, or user interfaces, or whatever other aspects of programming exist.
What method would you use to hire programmers?
Guido: Based on my interviewing experience in the past, I don’t think I’d be any good at hiring in the traditional way—my interview skills are nearly nonexistent on both sides of the table! I guess what I’d do would be to use some kind of apprentice system where I’d be working closely with people for quite some time and would eventually get a feeling for their strengths and weaknesses. Sort of the way an open source project works.
Is there any characteristic that becomes fundamental to evaluate if we are looking for great Python programmers?
Guido: I’m afraid you are asking this from the perspective of the typical manager who simply wants to hire a bunch of Python programmers. I really don’t think there’s a simple answer, and in fact I think it’s probably the wrong question. You don’t want to hire Python programmers. You want to hire smart, creative, self-motivated people.
If you check job ads for programmers, nearly all of them include a line about being able
to work in a team. What is your opinion on the role of the team in programming? Do you still see space for the brilliant programmer who can’t work with others?
Guido: I am with the job ads in that one aspect. Brilliant programmers who can’t do teamwork shouldn’t get themselves in the position of being hired into a traditional programming position—it will be a disaster for all involved, and their code will be a nightmare for whoever inherits it. I actually think it’s a distinct lack of brilliance if you can’t do teamwork. Nowadays there are ways to learn how to work with other people, and if you’re really so brilliant you should be able to learn teamwork skills easily—it’s really not as hard as learning how to implement an efficient Fast Fourier Transform, if you set your mind about it.
Being the designer of Python, what advantages do you see when coding with your language compared to another skilled developer using Python?
Guido: I don’t know—at this point the language and VM have been touched by so many people that I’m sometimes surprised at how certain things work in detail myself! If I have an advantage over other developers, it probably has more to do with having used the language longer than anyone than with having written it myself. Over that long period of time, I have had the opportunity to ponder which operations are faster and which are slower—for example, I may be aware more than most users that locals are faster than globals (though others have gone overboard using this, not me!), or that functions and method calls are expensive (more so than in C or Java), or that the fastest data type is a
tuple. When it comes to using the standard library and beyond, I often feel that others have an advantage. For example, I write about one web application every few years, and the technology available changes each time, so I end up writing a “first” web app using a new framework or approach each time. And I still haven’t had the opportunity to do serious XML mangling in Python.
It seems that one of the features of Python is its conciseness. How does this affect the maintainability of the code?
Guido: I’ve heard of research as well as anecdotal evidence indicating that the error rate per number of lines of code is pretty consistent, regardless of the programming language used. So a language like Python where a typical application is just much smaller than, say, the same amount of functionality written in C++ or Java, would make that application much more maintainable. Of course, this is likely going to mean that a single programmer is responsible for more functionality. That’s a separate issue, but it still comes out in favor of Python: more productivity per programmer probably means fewer programmers on a team, which means less communication overhead, which according to The Mythical Man-Month [Frederick P. Brooks; Addison-Wesley Professional] goes up by the square of the team size, if I remember correctly.
Source of Information : Oreilly - Masterminds of Programming
Guido: It takes time to recognize a good programmer. For example, it’s really hard to tell good from bad in a one-hour interview. When you work together with someone though, on a variety of problems, it usually becomes pretty clear which are the good ones. I hesitate to give specific criteria—I guess in general the good ones show creativity, learn quickly, and soon start producing code that works and doesn’t need a lot of changes before it’s ready to be checked in. Note that some folks are good at different aspects of programming than others—some folks are good at algorithms and data structures, others are good at large-scale integration, or protocol design, or testing, or API design, or user interfaces, or whatever other aspects of programming exist.
What method would you use to hire programmers?
Guido: Based on my interviewing experience in the past, I don’t think I’d be any good at hiring in the traditional way—my interview skills are nearly nonexistent on both sides of the table! I guess what I’d do would be to use some kind of apprentice system where I’d be working closely with people for quite some time and would eventually get a feeling for their strengths and weaknesses. Sort of the way an open source project works.
Is there any characteristic that becomes fundamental to evaluate if we are looking for great Python programmers?
Guido: I’m afraid you are asking this from the perspective of the typical manager who simply wants to hire a bunch of Python programmers. I really don’t think there’s a simple answer, and in fact I think it’s probably the wrong question. You don’t want to hire Python programmers. You want to hire smart, creative, self-motivated people.
If you check job ads for programmers, nearly all of them include a line about being able
to work in a team. What is your opinion on the role of the team in programming? Do you still see space for the brilliant programmer who can’t work with others?
Guido: I am with the job ads in that one aspect. Brilliant programmers who can’t do teamwork shouldn’t get themselves in the position of being hired into a traditional programming position—it will be a disaster for all involved, and their code will be a nightmare for whoever inherits it. I actually think it’s a distinct lack of brilliance if you can’t do teamwork. Nowadays there are ways to learn how to work with other people, and if you’re really so brilliant you should be able to learn teamwork skills easily—it’s really not as hard as learning how to implement an efficient Fast Fourier Transform, if you set your mind about it.
Being the designer of Python, what advantages do you see when coding with your language compared to another skilled developer using Python?
Guido: I don’t know—at this point the language and VM have been touched by so many people that I’m sometimes surprised at how certain things work in detail myself! If I have an advantage over other developers, it probably has more to do with having used the language longer than anyone than with having written it myself. Over that long period of time, I have had the opportunity to ponder which operations are faster and which are slower—for example, I may be aware more than most users that locals are faster than globals (though others have gone overboard using this, not me!), or that functions and method calls are expensive (more so than in C or Java), or that the fastest data type is a
tuple. When it comes to using the standard library and beyond, I often feel that others have an advantage. For example, I write about one web application every few years, and the technology available changes each time, so I end up writing a “first” web app using a new framework or approach each time. And I still haven’t had the opportunity to do serious XML mangling in Python.
It seems that one of the features of Python is its conciseness. How does this affect the maintainability of the code?
Guido: I’ve heard of research as well as anecdotal evidence indicating that the error rate per number of lines of code is pretty consistent, regardless of the programming language used. So a language like Python where a typical application is just much smaller than, say, the same amount of functionality written in C++ or Java, would make that application much more maintainable. Of course, this is likely going to mean that a single programmer is responsible for more functionality. That’s a separate issue, but it still comes out in favor of Python: more productivity per programmer probably means fewer programmers on a team, which means less communication overhead, which according to The Mythical Man-Month [Frederick P. Brooks; Addison-Wesley Professional] goes up by the square of the team size, if I remember correctly.
Source of Information : Oreilly - Masterminds of Programming
|
|
0 comments
Post a Comment