Difference between knowing Python and *knowing* Python
This post talks about Python, but it generalize well to other programming languages and environments. I’m using Python and my own experience here to make a point, this isn’t really a post about Python itself.
I know how to read and write code in Python. By that I mean that I understand the syntax and how to do things in Python. I wouldn’t say that I’m an expert in all the myriad of ways that you can make Python jump on command, but I’m comfortable reading non trivial code bases and I like to use Python for small scripting jobs. I’m also maintaining (personally) the RavenDB Python Client which is just over 11K lines of code and decidedly non trivial.
But I don’t know Python.
Those two statements may seem to contradict one another, but I don’t really think so.
To this day, I find that packaging code in Python to be an unfamiliar territory. I don’t have a good feel for that and even when I follow the guides exactly, something doesn’t work properly more often than not. I also have only the vaguest idea about the Python virtual machine and the internals of the GC.
My few attempts to build Python interfaces on top of ctypes has been… painful. And a task such as creating an application or a package that would embed a native component in Python is likely beyond me without investing a significant amount of time and effort.
This is interesting, because my threshold for understand a language or a platform means that I should have the ability to do non trivial things with the environment, not just with the code.
Packaging is an obvious problem, once you go beyond the simplest of scripts. But the detailed knowledge on debugging, troubleshooting and analysis of the system is also what I would expect to have before I could claim that I’m familiar with a particular environment.
There is often a lot of derision for job requirements such as “Minimum 5 years experience with Xyz”. Leaving aside Xyz being younger than five years. In many cases this is a requirement that came from the HR department and not the technical team.
But when I read a requirement like that, I translate that to the difference between knowing how the code work, and grokking how the whole environment operates.
Note that there is nothing really insurmountable with Python, per se. If I would dedicate enough time (probably in the order of weeks, not months) to study it properly, I would have most of the knowledge that I need. But whenever I run into a stumbling block when using Python, it is always easier to simply forgo using Python and go use something that I am more familiar with. Hence, there has never been enough of a reason to make the jump to really understand the platform.
Comments
In my experience with many interviews trying to find what I consider quality coders, I have found that those who "grok" are actually a very small minority within coders themselves.
I think the issue is that due to all coding being layers of abstraction, and the layering of abstractions upon each other when using pre-written libraries. So when I interview a full-stack candidate who self-rates as 4/5 in pure javascript, it turns out they don't know how to write a loop to iterate over an array. But they are really good at wiring up a telerik component using bind(). And they don't know what new StreamWriter() is actually doing, so they don't realize there may be contention or locking. Also they have years of entity framework experience, self-rate in sql as 5/5, but are unable to write a self-join by themselves.
Basically coders are becoming more and more specialized, unavoidable due to the rapid expansion of tech domains.
Peter,
Some of these I get. But not knowing how to iterate an array? There is a limit here. Not understanding the impact of the locking mechanism of StreamWriter makes sense. It differs by platform and requires multi threading experience.
Not being able to write self join, or not being able to write SQL, no matter how much ORM they use? How can they work with the data? You need to do ad hoc queries just to understand what you'll do all the time
You can have 5 years experience with Xyz, when it was live for 3 years, in case it was another 2 years in development, and you were one of those developers.
Comment preview