4 ms·

That sounds kind of fun, can you give some examples?

henrik_w 9y ago
Maybe not exactly, but this was recently in the news: "De-anonymizing programmers from executable binaries" https://news.ycombinator.com/item?id=16598962 https://news.ycombinator.com/item?id=16598962
harel 9y ago
It's quite hard to examplify once I actually think about an example, but I'll try. It's more a global vibe of a piece of code rather then semantics but they do play a part (using Python as example): A young person (say 24), has experience coding of a few years, but very enthusiastic, loves reading programming blogs, a real stickler of doing it the "right" way, and sometimes forgets other people might have to read their code. They are not as pragmatic as they would be 10 years down the road. They would use vim or emacs in vim mode because that's more pro. Their code might have a good few "clever" one liners that do something complex in a very concise manner. Took a while to compress into a single line and will take a week to read back and understand. Clever, but only if it never breaks or never needs maintenance. They write factories, sometimes of factories. They have 110% test coverage, including trivial stuff that doesn't require it. They would refactor a piece of code many times until it feels it's the right shade of clever. I like these coders because I can learn something from them, but if you have tight deadlines they might actually get in the way. Great to have a couple of these in your car, but don't let them drive. from itertools import chain first_set = set(['one', 'two']).union(set(chain.from_iterable([next.key for next in some_yielding_iter()]))) other_value = make_value_factory_factory(first_set).make_value_factory() 10 years down the line these guys realise you write code once and it's read many times over, and the above turns into a more vanilla multi line readable expression of the same idea. A less enthusiastic version of said 24 year old, codes because they knows how to, but has no aspirations to get better at their craft. Less organised individual. Pep8 is a new variation of Pepsi Cola? They are not bad coders, just sloppy. Their code works but can be better. They would benefit pairing with the above person. def someFunction(value): if (type(value) == ThisClass): processObject(value) elif (type(value) == str): processString(value) After pairing, maybe they were inspired a bit. Maybe they refactor to this: from functools import singledispatch @singledispatch def process_value(value): process_object(value) @process_value.register(str) def _(value): process_string(value) def some_function(value): return process_value(value) I think a good exercise is to look at a person you know and try ot match their personality to the code style. Then look at some code which might or might not be theirs and try to assert if it is.
- Insanity 9y ago
  Interesting example to give. I always think it's good to have programmers with quite in-depth knowledge, and programmers who are more superficial in their programming knowledge but get stuff done. In my experience, it's not so much about age, hence I'm not sure if that is relevant in there. (For example, I'm not sure if using VIM is something younger programmers tend to learn, and I'd guess more of the 'older generation' will know it).
  - harel 9y ago
    Yeah age is not relevant really, but I went for a complete example. As for vim, or emacs in particular, I actually met a few of these 20 something programmers with enthusiasm who went there. Some stayed, some came back frightened. But they all tried (and I modelled the exampled on them)
- meuk 9y ago
  I'm not trying to start an offtopic discussion, but the not enthusiastic 24-year old looks like the clearest and best option to me. Personally, I would refactor it to three lines.
  - Jtsummers 9y ago
    Except grabbing types like that in code is usually a code smell. It can become brittle and hard to extend as time goes on. It's suitable when you need something now or you know you'll only ever have a few (less than 4 or 5, preferably no more than 2) cases. But either way you ought to be refactoring to something more like the third example.
    - sevensor 9y ago
      Well, calling type() is usually bad, isinstance() is a little better. But if you're expecting a ThisClass and only falling back on strings, as implied by the example, surely this is the classic example of where duck typing is handy: try: processObject(value) except ValueError: processString(value) Where you've written processObject so that it only works on duck-like objects: def processObject(value): try: value.quack() except AttributeError: raise ValueError('I was expecting something like a duck!')

Maybe not exactly, but this was recently in the news: "De-anonymizing programmers from executable binaries" https://news.ycombinator.com/item?id=16598962 https://news.ycombinator.com/item?id=16598962

harel 9y ago

It's quite hard to examplify once I actually think about an example, but I'll try. It's more a global vibe of a piece of code rather then semantics but they do play a part (using Python as example): A young person (say 24), has experience coding of a few years, but very enthusiastic, loves reading programming blogs, a real stickler of doing it the "right" way, and sometimes forgets other people might have to read their code. They are not as pragmatic as they would be 10 years down the road. They would use vim or emacs in vim mode because that's more pro. Their code might have a good few "clever" one liners that do something complex in a very concise manner. Took a while to compress into a single line and will take a week to read back and understand. Clever, but only if it never breaks or never needs maintenance. They write factories, sometimes of factories. They have 110% test coverage, including trivial stuff that doesn't require it. They would refactor a piece of code many times until it feels it's the right shade of clever. I like these coders because I can learn something from them, but if you have tight deadlines they might actually get in the way. Great to have a couple of these in your car, but don't let them drive. from itertools import chain first_set = set(['one', 'two']).union(set(chain.from_iterable([next.key for next in some_yielding_iter()]))) other_value = make_value_factory_factory(first_set).make_value_factory() 10 years down the line these guys realise you write code once and it's read many times over, and the above turns into a more vanilla multi line readable expression of the same idea. A less enthusiastic version of said 24 year old, codes because they knows how to, but has no aspirations to get better at their craft. Less organised individual. Pep8 is a new variation of Pepsi Cola? They are not bad coders, just sloppy. Their code works but can be better. They would benefit pairing with the above person. def someFunction(value): if (type(value) == ThisClass): processObject(value) elif (type(value) == str): processString(value) After pairing, maybe they were inspired a bit. Maybe they refactor to this: from functools import singledispatch @singledispatch def process_value(value): process_object(value) @process_value.register(str) def _(value): process_string(value) def some_function(value): return process_value(value) I think a good exercise is to look at a person you know and try ot match their personality to the code style. Then look at some code which might or might not be theirs and try to assert if it is.

Insanity 9y ago
Interesting example to give. I always think it's good to have programmers with quite in-depth knowledge, and programmers who are more superficial in their programming knowledge but get stuff done. In my experience, it's not so much about age, hence I'm not sure if that is relevant in there. (For example, I'm not sure if using VIM is something younger programmers tend to learn, and I'd guess more of the 'older generation' will know it).
- harel 9y ago
  Yeah age is not relevant really, but I went for a complete example. As for vim, or emacs in particular, I actually met a few of these 20 something programmers with enthusiasm who went there. Some stayed, some came back frightened. But they all tried (and I modelled the exampled on them)
meuk 9y ago
I'm not trying to start an offtopic discussion, but the not enthusiastic 24-year old looks like the clearest and best option to me. Personally, I would refactor it to three lines.
- Jtsummers 9y ago
  Except grabbing types like that in code is usually a code smell. It can become brittle and hard to extend as time goes on. It's suitable when you need something now or you know you'll only ever have a few (less than 4 or 5, preferably no more than 2) cases. But either way you ought to be refactoring to something more like the third example.
  - sevensor 9y ago
    Well, calling type() is usually bad, isinstance() is a little better. But if you're expecting a ThisClass and only falling back on strings, as implied by the example, surely this is the classic example of where duck typing is handy: try: processObject(value) except ValueError: processString(value) Where you've written processObject so that it only works on duck-like objects: def processObject(value): try: value.quack() except AttributeError: raise ValueError('I was expecting something like a duck!')