it might be more impressive to switch to something less ridiculously simple than Python.
Why? Do you get extra points for doing things the hard way? As opposed to: choosing the right tool for the job.
(I am not familiar enough with Python, so this is not a comment endorsing Python, just a reaction to the “less ridiculously simple” part. If two programs do the same thing, what’s wrong with the simpler one?)
I consistently forget to account for the halo effect, and that it may be in part because I wish to believe it does not exist.
Yeah. We programmers are proud of our ability to write complex code, so we wish complex code was the most admired thing about computer programs. Unfortunately, most people are impressed by nice screenshots. (At the first moment. When they use the program for some time, they start caring also about things like working properly, not crashing, etc. But to get them there, you need a nice screenshot first.)
“Why? Do you get extra points for doing things the hard way? As opposed to: choosing the right tool for the job.”
I don’t know what potential employers are looking for (and now I realize that I haven’t even tried to find out), but I would expect them to be more impressed with a thing if I were to do it in a more ‘difficult’ language than if I did the same thing in a language that needed only two lines of code for the job. My focus is on signaling my skill, rather than completing the program itself.
Then again, I’m thinking it would be even more impressive to learn Python’s deepest secrets and exploit them to the max.
Data point, possibly completely irrelevant: When I am looking for a Java programmer job in Slovakia, pretty much the only thing employers care about is how many years did I program in Java and which frameworks did I use. -- Which in my opinion is completely stupid, because I consider the ability to write and understand algorithms much more important; and a new framework is just something you can learn in a month or two, if your algorithmic skills are solid. I guess the problem is with the fact that the employers who make the decision are not coders themselves, so speaking about algorithms is simply too abstract for them, but asking questions like “how many years?” and “are you familiar with XYZ, yes or no?” gives them a false sense of understanding.
More generally, you are a perfect employee if you did something extremely similar to what your new employers wants to do, for the last ten years. So another good question is: what kind of projects are the employers in your target group typically doing? (For Java programmer in Slovakia it is: a database application with a web interface, most likely in finance.) Then do a simple demo, using the “right” framework; which is the one most frequently mentioned in online job searches.
Note: In my case, programming games would be almost completely irrelevant to a real job experience. Although there would be some transferrable skills, such as commenting the code, maintaining a large program, understanding threads, etc. But I would completely miss communicating with the database and creating HTML pages, and knowing hundred specific details (and dozen bugs) of the relevant frameworks, which make most of my daily work.
But the problem is that there will be dozen frameworks doing pretty much the same thing, and new ones are still invented, and the old ones are redesigned. You just won’t have time to keep up with all of them. So the framework-based knowledge is prone to obsolescence, which drives some programmers into despair. You need to be more meta, and instead of “knowledge of framework X” focus on “ability to understand new frameworks”. (But you also need a deeper experience with one or two of them, just to learn what the painful parts are.)
More generally, you are a perfect employee if you did something extremely similar to what your new employers wants to do, for the last ten years.
Thank you, especially for this. I’ve been contemplating “looking good to potential future employers” type things, and it hadn’t occurred to me until just now to frame it as “consider exactly what it is said employer wants, minimise the distance between that and me (as presented by resume / portfolio / etc)”
Why? Do you get extra points for doing things the hard way? As opposed to: choosing the right tool for the job.
(I am not familiar enough with Python, so this is not a comment endorsing Python, just a reaction to the “less ridiculously simple” part. If two programs do the same thing, what’s wrong with the simpler one?)
Yeah. We programmers are proud of our ability to write complex code, so we wish complex code was the most admired thing about computer programs. Unfortunately, most people are impressed by nice screenshots. (At the first moment. When they use the program for some time, they start caring also about things like working properly, not crashing, etc. But to get them there, you need a nice screenshot first.)
“Why? Do you get extra points for doing things the hard way? As opposed to: choosing the right tool for the job.”
I don’t know what potential employers are looking for (and now I realize that I haven’t even tried to find out), but I would expect them to be more impressed with a thing if I were to do it in a more ‘difficult’ language than if I did the same thing in a language that needed only two lines of code for the job. My focus is on signaling my skill, rather than completing the program itself.
Then again, I’m thinking it would be even more impressive to learn Python’s deepest secrets and exploit them to the max.
Data point, possibly completely irrelevant: When I am looking for a Java programmer job in Slovakia, pretty much the only thing employers care about is how many years did I program in Java and which frameworks did I use. -- Which in my opinion is completely stupid, because I consider the ability to write and understand algorithms much more important; and a new framework is just something you can learn in a month or two, if your algorithmic skills are solid. I guess the problem is with the fact that the employers who make the decision are not coders themselves, so speaking about algorithms is simply too abstract for them, but asking questions like “how many years?” and “are you familiar with XYZ, yes or no?” gives them a false sense of understanding.
More generally, you are a perfect employee if you did something extremely similar to what your new employers wants to do, for the last ten years. So another good question is: what kind of projects are the employers in your target group typically doing? (For Java programmer in Slovakia it is: a database application with a web interface, most likely in finance.) Then do a simple demo, using the “right” framework; which is the one most frequently mentioned in online job searches.
Note: In my case, programming games would be almost completely irrelevant to a real job experience. Although there would be some transferrable skills, such as commenting the code, maintaining a large program, understanding threads, etc. But I would completely miss communicating with the database and creating HTML pages, and knowing hundred specific details (and dozen bugs) of the relevant frameworks, which make most of my daily work.
But the problem is that there will be dozen frameworks doing pretty much the same thing, and new ones are still invented, and the old ones are redesigned. You just won’t have time to keep up with all of them. So the framework-based knowledge is prone to obsolescence, which drives some programmers into despair. You need to be more meta, and instead of “knowledge of framework X” focus on “ability to understand new frameworks”. (But you also need a deeper experience with one or two of them, just to learn what the painful parts are.)
Thank you, especially for this. I’ve been contemplating “looking good to potential future employers” type things, and it hadn’t occurred to me until just now to frame it as “consider exactly what it is said employer wants, minimise the distance between that and me (as presented by resume / portfolio / etc)”