3 ms·

I think there is a de-facto distinction between different kind of programmers, we just need a clear names for them. Like, "builders" for folks who ship products

I think there is a de-facto distinction between different kind of programmers, we just need a clear names for them. Like, "builders" for folks who ship products and see code as an annoying intermediate step and "engineers" for people who build technically sound software.

hellisothers 2mo ago
Or put differently: code as a means to an end vs code as the end. You need both types, the ratio changes as things change, neither is The Way.
- crabmusket 2mo ago
  While I'm sure some people just want to write code for its own sake, I've never met one. What I've seen is coders working in domains that vary in what is economical, coders who have varying understanding of exactly how much rigor is needed at any given time, coders who have quirks of personality that sometimes lead them down unproductive paths. Never have I met someone who thinks the code is valuable for its own sake. But they do misunderstand, or misapply their understanding of, the task before them. I wanted to make this distinction because it changes the approach to managing communications. And it isn't just coders. Sometimes a manager isn't going to tell a developer "stop trying to hard and just slop it out" because the manager also has a self image that doesn't involve shipping swill to their customers. And I do think sometimes it really is difficult to know exactly where to draw the line. What parts of the product need gold plating? Where is stress going to appear, what is going to cause unexpectedly annoying debugging? In hindsight you should have spent more time there, not here. Maybe I've been privileged to work with people who care about real things- I've spent my whole career in relatively small orgs. I've self selected for that. Actually, now I think about it, I do believe I've met (not worked with) someone who was very into the code for its own sake. This was at a research institution, using Haskell, where "experimenting with edgy functional programming" was, if not part of every project, certainly an accepted and deliberate part of the culture.

hellisothers 2mo ago

Or put differently: code as a means to an end vs code as the end. You need both types, the ratio changes as things change, neither is The Way.

crabmusket 2mo ago
While I'm sure some people just want to write code for its own sake, I've never met one. What I've seen is coders working in domains that vary in what is economical, coders who have varying understanding of exactly how much rigor is needed at any given time, coders who have quirks of personality that sometimes lead them down unproductive paths. Never have I met someone who thinks the code is valuable for its own sake. But they do misunderstand, or misapply their understanding of, the task before them. I wanted to make this distinction because it changes the approach to managing communications. And it isn't just coders. Sometimes a manager isn't going to tell a developer "stop trying to hard and just slop it out" because the manager also has a self image that doesn't involve shipping swill to their customers. And I do think sometimes it really is difficult to know exactly where to draw the line. What parts of the product need gold plating? Where is stress going to appear, what is going to cause unexpectedly annoying debugging? In hindsight you should have spent more time there, not here. Maybe I've been privileged to work with people who care about real things- I've spent my whole career in relatively small orgs. I've self selected for that. Actually, now I think about it, I do believe I've met (not worked with) someone who was very into the code for its own sake. This was at a research institution, using Haskell, where "experimenting with edgy functional programming" was, if not part of every project, certainly an accepted and deliberate part of the culture.