> "You value clarity and directness in code. You prefer explicit, step-by-step solutions that are easy to understand and debug, even if they require more lines of code"
Also, I'd recommend NOT telling the test taker which dimensions they're getting scored on as it will affect the responses. For example, if you gave me a test telling me that you're gonna score me on Introversion-Extraversion and Neuroticism-Emotional Stability, then I may be more biased to answer questions to score me as an emotionally stable introvert since that's what I identify as.
Oh, and
Abstract ↔ Concrete: 0 Neutral |
Human ↔ Computer Friendly: +11 Human-Friendly
I landed right in the middle - -1, -2. Which seems weird because I’m very opinionated about a lot of this stuff. I like a lot of the questions but a lot of my answers felt like I was arbitrarily picking something. That’s probably why.
Eg for testing, do I want “whatever finds bugs most effectively” or “property based testing”? Well, property based testing is usually the most time efficient way to find bugs. So, yes both of those. Debugging: do I use print statements, or a debugger, or logically think it through? Yes all of those. But if I arbitrarily said I use a debugger in a multiple choice test, I don’t think that tells you much about how I code!
I do - controversially - think some of the answers are naming bad practices. Like abstraction first is a bad idea - since you know the least about your problem before you start programming it up. Abstraction first inevitably bakes in whatever bad assumptions you walked in the door with into your code. Better to code something - anything - up and use what you learned in the process to iterate on your software architecture decisions. I also generally hate modern OO and these days I prefer static types over dynamic types.
But yeah. Interesting questions! Thanks for putting this together.
I tried to finish this quiz but just can’t. Every question I got was a very big, “it depends on context…”
“Do you prefer strong static or dynamic or a mix?” Well… are we teaching 9th graders an intro to coding, writing a quick script to answer a bespoke data question, or writing a data processing library?
“On algorithms I focus on…” Okay, well… do we care about performance? Where is it running? How often will it run? Will the code be disposed of soon or live a decade? Do we need it working today or next week?
I just don’t understand how to even begin formulating an opinion on any of these questions without any context.
To use the compass analogy: shouldn’t you want to best know how to use a compass? What value is there in saying, “my favourite bearing is east-northeast”? That is, the substance in any of this is the “it depends…” portion. Any answers to this quiz are really just a proxy for the kinds of contexts people are solving problems in.
I had that feeling about several questions. The one that stood out to me was
"""
When debugging, I typically:
* Write tests to isolate the problem
* Reason about the code logically first
* Add print statements to understand data flow
* Use a debugger to step through code systematically
"""
and I typically do all 4 of those things. If I don't understand the dataflow yet, I'll start with either print statements or the debugger to understand that. If it's code where I already understand the dataflow, and I can reason about the code already, I'll do that. Otherwise I might first write tests to help me reason about the code. But I generally do all of these things and the order depends on my specific problem.
Yeah, that stood out to me as a virtual tie also. When I got pretty good at debugging was when I began to recognize which of these approaches would likely be most effective in a given situation, and when to back out and use another approach, or mix approaches.
I agree, but would add that it is just one of its problems. Even before we get to the questions, we are told that one of the outcomes will be a score on a “friendliness” axis. What would it mean to be computer-friendly, and why would it matter?
You prefer elegant, high-level solutions that are intuitive and accessible to other developers. You likely favor functional programming, clear abstractions, and code that reads like prose.
You prefer elegant, high-level solutions that are intuitive and accessible to other developers. You likely favor functional programming, clear abstractions, and code that reads like prose.
You prefer elegant, high-level solutions that are intuitive and accessible to other developers. You likely favor functional programming, clear abstractions, and code that reads like prose.
Abstract ↔ Concrete: +4 Abstract
Human ↔ Computer Friendly:+7 Human-Friendly
Concrete and human-readable here, which is exactly what I expected to get coming from IT (with short job cycles, high turnover, comparatively low wages) where my guiding principle is not being a dick to the next person by making sure they understand why I did things a given way, and where time to learn new things is very much a “thrown in the fire” type scenario (e.g., learning Asterisk while your global support line is down and your contractor holds non-regional business hours for support).
It does not display the quiz. I found the JavaScript file, which is compiled from Nim, and I found the source code, and the questions.
For many questions, the answer depends on the specific use, and/or will be something other than what is listed there. (For example, debugging will involve all of the four things that are listed there.)
I am also not so sure that the quiz describes the programming philosophy very well, but this is a general feature of these kind of quiz anyways.
I seem to disagree with many modern programmers about programming philosophy, but some I seem to have more agreement with some people who do some things in the older ways (although not completely).
You prefer elegant, high-level solutions that are intuitive and accessible to other developers. You likely favor functional programming, clear abstractions, and code that reads like prose.
Spot on I'd say; code is the best documentation unless I'm writing some bespoke mathematical algorithms, even then I try to offset it by writing and using clear variables/function names.
You focus on efficiency and performance. You like to work close to the metal, optimize for speed and memory usage, and prefer direct control over system resources.
We write code for machines. For humans we write human-readble media and formats; like document, diagrams, specifications, and ect...
> You value clarity and directness in code. You prefer explicit, step-by-step solutions that are easy to understand and debug, even if they require more lines of code.
You value clarity and directness in code. You prefer explicit, step-by-step solutions that are easy to understand and debug, even if they require more lines of code.
This was fun, and the conclusion was pretty good (slight preference for human-friendly and concrete).
At first I was frustrated that the answers were very much “it depends”, but then I decided that (a) this is low stakes, (b) just pick the closest one as if someone held a gun to your head. End result was fine.
Pretty much what I expected. Probably also depends on what kind of code you write. I assume somebody who writes kernel drivers would lean more towards computer friendly.
57 comments
[ 3.9 ms ] story [ 62.8 ms ] threadHuman ↔ Computer Friendly: -5 Computer-Friendly
> "You value clarity and directness in code. You prefer explicit, step-by-step solutions that are easy to understand and debug, even if they require more lines of code"
Sounds about right.
Feels about right.
Also, I'd recommend NOT telling the test taker which dimensions they're getting scored on as it will affect the responses. For example, if you gave me a test telling me that you're gonna score me on Introversion-Extraversion and Neuroticism-Emotional Stability, then I may be more biased to answer questions to score me as an emotionally stable introvert since that's what I identify as.
Oh, and Abstract ↔ Concrete: 0 Neutral | Human ↔ Computer Friendly: +11 Human-Friendly
Eg for testing, do I want “whatever finds bugs most effectively” or “property based testing”? Well, property based testing is usually the most time efficient way to find bugs. So, yes both of those. Debugging: do I use print statements, or a debugger, or logically think it through? Yes all of those. But if I arbitrarily said I use a debugger in a multiple choice test, I don’t think that tells you much about how I code!
I do - controversially - think some of the answers are naming bad practices. Like abstraction first is a bad idea - since you know the least about your problem before you start programming it up. Abstraction first inevitably bakes in whatever bad assumptions you walked in the door with into your code. Better to code something - anything - up and use what you learned in the process to iterate on your software architecture decisions. I also generally hate modern OO and these days I prefer static types over dynamic types.
But yeah. Interesting questions! Thanks for putting this together.
“Do you prefer strong static or dynamic or a mix?” Well… are we teaching 9th graders an intro to coding, writing a quick script to answer a bespoke data question, or writing a data processing library?
“On algorithms I focus on…” Okay, well… do we care about performance? Where is it running? How often will it run? Will the code be disposed of soon or live a decade? Do we need it working today or next week?
I just don’t understand how to even begin formulating an opinion on any of these questions without any context.
To use the compass analogy: shouldn’t you want to best know how to use a compass? What value is there in saying, “my favourite bearing is east-northeast”? That is, the substance in any of this is the “it depends…” portion. Any answers to this quiz are really just a proxy for the kinds of contexts people are solving problems in.
"""
When debugging, I typically:
* Write tests to isolate the problem
* Reason about the code logically first
* Add print statements to understand data flow
* Use a debugger to step through code systematically
"""
and I typically do all 4 of those things. If I don't understand the dataflow yet, I'll start with either print statements or the debugger to understand that. If it's code where I already understand the dataflow, and I can reason about the code already, I'll do that. Otherwise I might first write tests to help me reason about the code. But I generally do all of these things and the order depends on my specific problem.
Your Programming Philosophy
You prefer elegant, high-level solutions that are intuitive and accessible to other developers. You likely favor functional programming, clear abstractions, and code that reads like prose.
Abstract ↔ Concrete: +3 Abstract
Human ↔ Computer Friendly: +11 Human-Friendly
You prefer elegant, high-level solutions that are intuitive and accessible to other developers. You likely favor functional programming, clear abstractions, and code that reads like prose.
Abstract ↔ Concrete: +4 Abstract Human ↔ Computer Friendly: +9 Human-Friendly
Abstract ↔ Concrete: +4 Abstract Human ↔ Computer Friendly:+7 Human-Friendly
I like "code that reads like prose" :-)
For many questions, the answer depends on the specific use, and/or will be something other than what is listed there. (For example, debugging will involve all of the four things that are listed there.)
I am also not so sure that the quiz describes the programming philosophy very well, but this is a general feature of these kind of quiz anyways.
I seem to disagree with many modern programmers about programming philosophy, but some I seem to have more agreement with some people who do some things in the older ways (although not completely).
Abstract ↔ Concrete: +7 Abstract Human ↔ Computer Friendly: +11 Human-Friendly
Spot on I'd say; code is the best documentation unless I'm writing some bespoke mathematical algorithms, even then I try to offset it by writing and using clear variables/function names.
We write code for machines. For humans we write human-readble media and formats; like document, diagrams, specifications, and ect...
> You value clarity and directness in code. You prefer explicit, step-by-step solutions that are easy to understand and debug, even if they require more lines of code.
At first I was frustrated that the answers were very much “it depends”, but then I decided that (a) this is low stakes, (b) just pick the closest one as if someone held a gun to your head. End result was fine.
Human ↔ Computer Friendly: +21 Human-Friendly
Pretty much what I expected. Probably also depends on what kind of code you write. I assume somebody who writes kernel drivers would lean more towards computer friendly.