4 ms·

I feel that there is some naiveté in this perspective, although the OP does touch on it somewhat. A novice most likely would write their code in a very monolit

by gmoes 9y ago

I feel that there is some naiveté in this perspective, although the OP does touch on it somewhat. A novice most likely would write their code in a very monolithic fashion. That same approach fails significantly with larger code bases. As a seasoned developer I have come to realize that one of the most important things to be a good developer is organizational skills. Unfortunately it seems that ways to organize code bases, including things like naming, mutable state, modularization, cohesion/coupling, etc., are not as well developed or understood in general in our industry as they should be. While understanding and knowing the right algorithms is important. I sometimes wonder if our emphasis on the knowing algorithms off the top of your head interviewing process contributes to putting the emphasis on the wrong things in software development.

wellpast 9y ago
As a thought experiment imagine an org that hired for organizational/abstraction skills and landed a single worker good at algorithm design. (This is a distilled/simplistic example but bear to the point.) 10-20% of time in my career building business/productivity application systems have I needed to design & impl a complex algo. Okay so my fictional team abstracts away that need and my algo guy colors in the deets. (In most cases this is possible; in rarer cases the performance of the algo needs to cross-cut.) But the point is what you’re saying—one skill is pluggable, the other is not. Kind of making this less interesting (or more?) is that learning algorithm dev tools/skills is far, far easier than learning the architectural/organizational skills. So no wonder the current prevailing hiring emphasis.
ksk 9y ago
>Unfortunately it seems that ways to organize code bases, including things like naming, mutable state, modularization, cohesion/coupling, etc., are not as well developed or understood in general in our industry as they should be. True, but I think any attempt to standardize or to make it another engineering discipline would mean the end of high programmer salaries. Just follow guidelines and standard procedure in a book and you'll end up with a reasonable solution that is reasonably good and reasonably reliable at a reasonable cost. Most businesses would jump at that... And I'd argue that would be a good thing for all the sectors where programming is important, but no good programmer wants to actually join because its not sexy. (coal mining, medical equipment, etc) > I sometimes wonder if our emphasis on the knowing algorithms off the top of your head interviewing process contributes to putting the emphasis on the wrong things in software development. Yes but no business actually cares about creative solutions, unless algorithms are core to their business (and even then, other human factors outweigh finding the optimal, bestest, fastest solution). They simply want to use computers to solve a business problem. They want a runner to run from A to B, not an Olympic sprinter who is going to break a world record. Do you know a reasonably decent sort algorithm? Good, just use it. Profiling? Optimizing? That's for Olympic sprinters. Design patterns? Blindly apply a GoF design pattern that approximates your problem, etc etc.
- wellpast 9y ago
  I think our industry can come to _understand_ and _articulate_ the skill set without having to standardize/certify it. Civil architects can be wildly creative and artful in their industry which understands its own domain deeply.
  - ksk 9y ago
    Right, but when you hire an architect to design a random office building, you're not expecting a piece of art. My point is the vast majority of programming projects are random office building # 23.
    - wellpast 9y ago
      Then we’re in the realm of automated or at least codified/systematic process, or we should be, no?
      - ksk 9y ago
        Yes, and we should be encouraging more of that. But as programmers (well to my mind anyway) it nags us when we look at inefficient solutions, even those which are reasonably robost/adequate. We tend to scoff at people using Visual Basic to solve a business problem, when its probably the best language for a large chunk of the problem space.
  - gmoes 9y ago
    I would agree that there is an artfulness, for lack of a better term, in engineering. However, there is a lot of science and math i.e. structural engineering that underlies building a structure that is safe and won’t fall down. Admittedly it still does happen from time to time due to mistakes or things that might have been misunderstood, e.g. the Tacoma Narrows Bridge. The field of software engineering is very nascent and is still in need of the underlying science and math foundations like you find in other engineering disciplines. Unfortunately methodologies like Agile and Waterfall seem to have become synonymous with software engineering.
- 9y ago

by gmoes 9y ago

wellpast 9y ago

As a thought experiment imagine an org that hired for organizational/abstraction skills and landed a single worker good at algorithm design. (This is a distilled/simplistic example but bear to the point.) 10-20% of time in my career building business/productivity application systems have I needed to design & impl a complex algo. Okay so my fictional team abstracts away that need and my algo guy colors in the deets. (In most cases this is possible; in rarer cases the performance of the algo needs to cross-cut.) But the point is what you’re saying—one skill is pluggable, the other is not. Kind of making this less interesting (or more?) is that learning algorithm dev tools/skills is far, far easier than learning the architectural/organizational skills. So no wonder the current prevailing hiring emphasis.

ksk 9y ago

>Unfortunately it seems that ways to organize code bases, including things like naming, mutable state, modularization, cohesion/coupling, etc., are not as well developed or understood in general in our industry as they should be. True, but I think any attempt to standardize or to make it another engineering discipline would mean the end of high programmer salaries. Just follow guidelines and standard procedure in a book and you'll end up with a reasonable solution that is reasonably good and reasonably reliable at a reasonable cost. Most businesses would jump at that... And I'd argue that would be a good thing for all the sectors where programming is important, but no good programmer wants to actually join because its not sexy. (coal mining, medical equipment, etc) > I sometimes wonder if our emphasis on the knowing algorithms off the top of your head interviewing process contributes to putting the emphasis on the wrong things in software development. Yes but no business actually cares about creative solutions, unless algorithms are core to their business (and even then, other human factors outweigh finding the optimal, bestest, fastest solution). They simply want to use computers to solve a business problem. They want a runner to run from A to B, not an Olympic sprinter who is going to break a world record. Do you know a reasonably decent sort algorithm? Good, just use it. Profiling? Optimizing? That's for Olympic sprinters. Design patterns? Blindly apply a GoF design pattern that approximates your problem, etc etc.

wellpast 9y ago
I think our industry can come to _understand_ and _articulate_ the skill set without having to standardize/certify it. Civil architects can be wildly creative and artful in their industry which understands its own domain deeply.
- ksk 9y ago
  Right, but when you hire an architect to design a random office building, you're not expecting a piece of art. My point is the vast majority of programming projects are random office building # 23.
  - wellpast 9y ago
    Then we’re in the realm of automated or at least codified/systematic process, or we should be, no?
    - ksk 9y ago
      Yes, and we should be encouraging more of that. But as programmers (well to my mind anyway) it nags us when we look at inefficient solutions, even those which are reasonably robost/adequate. We tend to scoff at people using Visual Basic to solve a business problem, when its probably the best language for a large chunk of the problem space.
- gmoes 9y ago
  I would agree that there is an artfulness, for lack of a better term, in engineering. However, there is a lot of science and math i.e. structural engineering that underlies building a structure that is safe and won’t fall down. Admittedly it still does happen from time to time due to mistakes or things that might have been misunderstood, e.g. the Tacoma Narrows Bridge. The field of software engineering is very nascent and is still in need of the underlying science and math foundations like you find in other engineering disciplines. Unfortunately methodologies like Agile and Waterfall seem to have become synonymous with software engineering.
9y ago