31 ms·

I gotta ask, What do you consider good? There's plenty of working software that's good enough. Made by fair programmers who don't care about lisp or FP. Is yo

I gotta ask, What do you consider good? There's plenty of working software that's good enough. Made by fair programmers who don't care about lisp or FP. Is your scale of good affected by what you see here on HN? Because I feel like the front page of this site has the same effect as Facebook for skewing views of reality.

the_only_law 6y ago
I’m not sure how to express it very well, but I interact a bit with people who I’d consider “good” programmers. I don’t think I’d correlate it with experience or effectiveness at a job, a good many of them haven’t even made it out of school yet. But they tend to be able to internalize programming/mathematics concepts that by many are considered difficult or complex. I know some will disagree with this, arguing that things related to experience like domain knowledge, ability to effectively work and lead in a team, understanding business needs, etc. and I don’t want to diminish the importance of these things in a professional context. However, I think there’s a good bit to programming that’s more purely technical and more related to raw intelligence (IQ or whatever you want). These people are able to easily understand things that I can’t seem to put together in my head very well.
- throwawayboise 6y ago
  I'm not sure how relevant it is today but one litmus test I found years ago was how naturally they grasped the concept of a pointer. If a programmer grokked pointers that was a good indicator that s/he was on the path to being a good programmer. It's probably just a proxy for being able to think at a level of indirection.
  - deleted 6y ago
    [deleted]
  - setpatchaddress 6y ago
    This was one reason I thought programming the classic Mac was great training — the nature of the memory manager, where most data structures were double-indirected pointers and the inner pointer could move at will -— you had to understand pointers or you’d never be able to produce a stable program. Edit to add: and yeah, I’m also not sure it’s relevant outside OS-level programming, which most people never get near at this point.
- scsilver 6y ago
  I wonder, is being able to see a leetcode problem that relies on a generalization of merge sort to solve, never having learned merge sort, and coming up with a merge sorting approach the kind of person who can be a programmer. Does this person even exist(like how many people in the world have that strong of abstract reasoning skills to be able to pull that off).
yarg 6y ago
I generally define things more in terms of "not bad" or "less bad" - to me software development is too rapidly an evolving discipline to allow for a static definition of good. But things like: - don't copy, paste and tweak a piece of code when additional parameters are a better option, - don't grossly overload a definition with parameters instead of breaking up a function. There's nuance there, and the question of what amount of technical complexity is reasonable for a given problem - but if I start thinking about that I'll never stop digressing. I have dealt with an entire office of people who seemed to code purely in bug-filled technical debt: you could tell when they clocked on because the build broke an hour later. As far as FP is concerned, I think that the memory and performance penalties are often too heavy: there's certainly a place for mathematically provable programming - I just don't know what it is.
- User23 6y ago
  > As far as FP is concerned, I think that the memory and performance penalties are often too heavy: there's certainly a place for mathematically provable programming - I just don't know what it is. FP isn't necessary for mathematically provable programing. Dijkstra and Scholten did a ton of work in this area that conclusively demonstrated that. I can't do them justice in a post here, but to a first approximation the trick is that you reason about imperative programs as transformations on a state space, which is to say you think about functions. A simple example: We want the predicate x = 3 to hold for all preconditions. The code "x := 3" establishes that predicate everywhere in the state space. That is to say, no matter what x was before the assignment, afterwards the predicate holds. While plenty of bytes have been spent on discussing why this is totally impracticable for real programs, whatever that means, we also have buzzwords like "defensive programming" that follow the same philosophy: we should write code such that when it has executed no matter what the state of the system was initially, afterwards it satisfies some specification.
  - yarg 6y ago
    Cool.
spicyramen 6y ago
I just had an interview yesterday and took me a long time to solve a problem under pressure (few loops and some dictionaries and list and sorting), later last night at work found some complex issue debugging some packets and code. Is hard to measure what is good. I was thinking that maybe creating a project that is used by hundreds makes you a better one?
mrh0057 6y ago
It's good enough for a time until a competitor comes in with better software and you go bankrupt due to unable to compete on price and usability.
- gonzo41 6y ago
  It's a trade off. But if you spend ages getting to market because your jumping at shadows. Gold-plated software doesn't mean good software. I think we should just try and call good software that which fits time, budget and scope. And works!
Forge36 6y ago
My bar for good: willing to read the existing documentation and say "it's terrible".

the_only_law 6y ago

I’m not sure how to express it very well, but I interact a bit with people who I’d consider “good” programmers. I don’t think I’d correlate it with experience or effectiveness at a job, a good many of them haven’t even made it out of school yet. But they tend to be able to internalize programming/mathematics concepts that by many are considered difficult or complex. I know some will disagree with this, arguing that things related to experience like domain knowledge, ability to effectively work and lead in a team, understanding business needs, etc. and I don’t want to diminish the importance of these things in a professional context. However, I think there’s a good bit to programming that’s more purely technical and more related to raw intelligence (IQ or whatever you want). These people are able to easily understand things that I can’t seem to put together in my head very well.

throwawayboise 6y ago
I'm not sure how relevant it is today but one litmus test I found years ago was how naturally they grasped the concept of a pointer. If a programmer grokked pointers that was a good indicator that s/he was on the path to being a good programmer. It's probably just a proxy for being able to think at a level of indirection.
- deleted 6y ago
  [deleted]
- setpatchaddress 6y ago
  This was one reason I thought programming the classic Mac was great training — the nature of the memory manager, where most data structures were double-indirected pointers and the inner pointer could move at will -— you had to understand pointers or you’d never be able to produce a stable program. Edit to add: and yeah, I’m also not sure it’s relevant outside OS-level programming, which most people never get near at this point.
scsilver 6y ago
I wonder, is being able to see a leetcode problem that relies on a generalization of merge sort to solve, never having learned merge sort, and coming up with a merge sorting approach the kind of person who can be a programmer. Does this person even exist(like how many people in the world have that strong of abstract reasoning skills to be able to pull that off).

yarg 6y ago

I generally define things more in terms of "not bad" or "less bad" - to me software development is too rapidly an evolving discipline to allow for a static definition of good. But things like: - don't copy, paste and tweak a piece of code when additional parameters are a better option, - don't grossly overload a definition with parameters instead of breaking up a function. There's nuance there, and the question of what amount of technical complexity is reasonable for a given problem - but if I start thinking about that I'll never stop digressing. I have dealt with an entire office of people who seemed to code purely in bug-filled technical debt: you could tell when they clocked on because the build broke an hour later. As far as FP is concerned, I think that the memory and performance penalties are often too heavy: there's certainly a place for mathematically provable programming - I just don't know what it is.

User23 6y ago
> As far as FP is concerned, I think that the memory and performance penalties are often too heavy: there's certainly a place for mathematically provable programming - I just don't know what it is. FP isn't necessary for mathematically provable programing. Dijkstra and Scholten did a ton of work in this area that conclusively demonstrated that. I can't do them justice in a post here, but to a first approximation the trick is that you reason about imperative programs as transformations on a state space, which is to say you think about functions. A simple example: We want the predicate x = 3 to hold for all preconditions. The code "x := 3" establishes that predicate everywhere in the state space. That is to say, no matter what x was before the assignment, afterwards the predicate holds. While plenty of bytes have been spent on discussing why this is totally impracticable for real programs, whatever that means, we also have buzzwords like "defensive programming" that follow the same philosophy: we should write code such that when it has executed no matter what the state of the system was initially, afterwards it satisfies some specification.
- yarg 6y ago
  Cool.

spicyramen 6y ago

I just had an interview yesterday and took me a long time to solve a problem under pressure (few loops and some dictionaries and list and sorting), later last night at work found some complex issue debugging some packets and code. Is hard to measure what is good. I was thinking that maybe creating a project that is used by hundreds makes you a better one?

mrh0057 6y ago

It's good enough for a time until a competitor comes in with better software and you go bankrupt due to unable to compete on price and usability.

gonzo41 6y ago
It's a trade off. But if you spend ages getting to market because your jumping at shadows. Gold-plated software doesn't mean good software. I think we should just try and call good software that which fits time, budget and scope. And works!

Forge36 6y ago

My bar for good: willing to read the existing documentation and say "it's terrible".