5 ms·

On another hand, many commercial programming tasks or programming roles are relatively mundane or lower-skill, and do not require exceptional levels of programm

by shoo 6y ago

On another hand, many commercial programming tasks or programming roles are relatively mundane or lower-skill, and do not require exceptional levels of programming ability. If an exceptional programmer was dropped into one of these roles, they might quit out of boredom, or try to refashion the role into building tooling or systems to automate away some or all of the drudgery, but perhaps at the cost of not delivering enough immediate business value to justify their employment, or spending 100 hours building a beautifully elegant solution for a class of problem of which there will only ever be a single instance, which can be solved with 1 hour of bad scripting & manual data tweaking in a spreadsheet. Mediocre work performed in situations demanding mediocrity can be sufficient while producing economic value & providing for one's income.

tartoran 6y ago
I agree that an exceptional programmer would not only not be appreciated in a job like this but their work/code will also be misunderstood and create a huge libility for the company. Hence tgh industry dumbed everything down to the lowest denominator (not absolutely lowest but quite low) such that every role is replaceable (hint: it has to look like an ordinary cog in a system)
- orangeoxidation 6y ago
  > I agree that an exceptional programmer would not only not be appreciated in a job like this but their work/code will also be misunderstood and create a huge libility for the company. Writing complicated and unmaintainable code is not the hallmark of an exceptional programmer. Rather it is writing simple code to solve simple problems and writing understandable code to solve hard problems. Code other's cannot wrap their head around is not good code and even the clever author will have a harder time debugging, re-factoring or adapting it. Chances are it would be a liability even on a solo project.
tharkun__ 6y ago
Building something in 100 hours that satisfies a class of problems but will only see use once is definitely not smart. It's called taking advantage of your employer to satisfy your own curiosity. Do that in your free time of your job is not one where that solution will see millions of uses (meaning you are not working for - depending on decade we are talking - Bell Labs, IBM, Microsoft, Amazon etc.). If you are that good but work at a regular company, build an awesomely good script that is maintainable by even a mediocre programmer that comes after you and spend the other 55 minutes of that hour doing the next task. Then go home when everyone else goes for lunch without anyone noticing because you did the work of 2 people already anyway. If you have a good boss they won't care and give you awesome life work balance that you definitely would not get at Bell Lab, IBM, Microsoft or Amazon because they know how to exploit your drive and passion for their own good. No you don't make enough money to get that time of your life back.
- username90 6y ago
  The fact that many intelligent people are still fat means that they like everyone else don't have perfect self control. So any tips on what people should do if they were in perfect control of their emotions doesn't help, knowing how to think rationally and being capable of acting rationally are two separate things.
perl4ever 6y ago
"spending 100 hours building a beautifully elegant solution for a class of problem of which there will only ever be a single instance" That's not an "exceptional" programmer. An exceptional programmer who does mundane stuff has this posted on their cubicle wall: https://xkcd.com/1205/ https://xkcd.com/1205/
- username90 6y ago
  Problem with that comic is that it doesn't take skill acquisition into account. Automating something increases your skills in automating things and therefore can be worthwhile even if automating this specific task isn't. Lets say that automating a task saving you 1 hour takes 10 hours. Is it worth it? No, you'd say. But what if you had 100 such tasks, and the time to automate them goes down as you become a better programmer taking a total 50 hours? Then it would be worth it, but you would never achieve that level of expertise and therefore lose that productivity increase if you followed the advice of that comic, since none of the tasks you'd come across would be worth automating when you got to them.
  - perl4ever 6y ago
    >Problem with that comic is that it doesn't take skill acquisition into account. I'd argue it can help skill acquisition to avoid getting into one thing too deeply, because the more different items you do, the more the commonalities appear; the more chances you have to see if your approach is optimal.
  - smallnamespace 6y ago
    Knowing what’s important, and having the discipline to focus on it is one of the most important skills to acquire.
    - perl4ever 6y ago
      I think "having the discipline to focus on what's important" means consistently and periodically interrupting yourself, and asking "am I doing what's most important". I think there's a tension between this and the deep concentration or "flow state" that people like to talk about on HN. In effect, there are different value systems, and people have a hard time stepping outside of that.
bluedino 6y ago
I agree. Never underestimate a bad, but determined programmer. The worst part is he’ll feel extra smart afterward, because he finally figured out enough of the bugs in his horrible implementation to call it “done”, and he’ll likely be re-visiting this code for a long time to come, as issues pop out that he still doesn’t understand fully.
- chaboud 6y ago
  The energetic stupid programmer is the single most destructive thing you can have on your team and in your codebase. They make messes for everyone else, and a dummy writing bad code can produce more volume than even the best coder writing good code. Eventually, guardrails and processes get put in place to protect against their damage, and the whole team slows down. Good coders walk, and you're left with the dummies, cranking out a high volume of low quality code. It's absolutely tragic. When you build a flexible high-performance templatized system, hand it off, and realize a few weeks later that an energetic stupid coder has "written" more than 50 copied and pasted hard-coded classes from that codebase for the different places it was called from, only to have him and the non-coding manager push hard for sticking with that approach because the work is "nearly done", that's when you brush off the resumé and walk. Teams need workaday coders sometimes, and every coder should know how to just grind out a big refactor or massive change. However, I aim for coders who are lazy enough to find a cleaner way to do it and smart enough to know they can.
  - yarg 6y ago
    But who reflects those values at company wide scales?
  - paulie_a 6y ago
    The codebase is probably not that good to begin with and quite frankly doesnt need to be I think programmers have a chip on their shoulder about the importance of the work they do. You are not painting the sistine chapel Most programming is what you refer to as "workaday"
    - 6y ago
poisonborz 6y ago
> a beautifully elegant solution for a class of problem of which there will only ever be a single instance, which can be solved with 1 hour of bad scripting This is a stupidly common problem, and one that is hard to fight against. Why would you decline a good / inspiring part of the codebase, coupled with the unsureness that during the lifetime of the software this would come handy.

by shoo 6y ago

tartoran 6y ago

I agree that an exceptional programmer would not only not be appreciated in a job like this but their work/code will also be misunderstood and create a huge libility for the company. Hence tgh industry dumbed everything down to the lowest denominator (not absolutely lowest but quite low) such that every role is replaceable (hint: it has to look like an ordinary cog in a system)

orangeoxidation 6y ago
> I agree that an exceptional programmer would not only not be appreciated in a job like this but their work/code will also be misunderstood and create a huge libility for the company. Writing complicated and unmaintainable code is not the hallmark of an exceptional programmer. Rather it is writing simple code to solve simple problems and writing understandable code to solve hard problems. Code other's cannot wrap their head around is not good code and even the clever author will have a harder time debugging, re-factoring or adapting it. Chances are it would be a liability even on a solo project.

tharkun__ 6y ago

Building something in 100 hours that satisfies a class of problems but will only see use once is definitely not smart. It's called taking advantage of your employer to satisfy your own curiosity. Do that in your free time of your job is not one where that solution will see millions of uses (meaning you are not working for - depending on decade we are talking - Bell Labs, IBM, Microsoft, Amazon etc.). If you are that good but work at a regular company, build an awesomely good script that is maintainable by even a mediocre programmer that comes after you and spend the other 55 minutes of that hour doing the next task. Then go home when everyone else goes for lunch without anyone noticing because you did the work of 2 people already anyway. If you have a good boss they won't care and give you awesome life work balance that you definitely would not get at Bell Lab, IBM, Microsoft or Amazon because they know how to exploit your drive and passion for their own good. No you don't make enough money to get that time of your life back.

username90 6y ago
The fact that many intelligent people are still fat means that they like everyone else don't have perfect self control. So any tips on what people should do if they were in perfect control of their emotions doesn't help, knowing how to think rationally and being capable of acting rationally are two separate things.

perl4ever 6y ago

"spending 100 hours building a beautifully elegant solution for a class of problem of which there will only ever be a single instance" That's not an "exceptional" programmer. An exceptional programmer who does mundane stuff has this posted on their cubicle wall: https://xkcd.com/1205/ https://xkcd.com/1205/

username90 6y ago
Problem with that comic is that it doesn't take skill acquisition into account. Automating something increases your skills in automating things and therefore can be worthwhile even if automating this specific task isn't. Lets say that automating a task saving you 1 hour takes 10 hours. Is it worth it? No, you'd say. But what if you had 100 such tasks, and the time to automate them goes down as you become a better programmer taking a total 50 hours? Then it would be worth it, but you would never achieve that level of expertise and therefore lose that productivity increase if you followed the advice of that comic, since none of the tasks you'd come across would be worth automating when you got to them.
- perl4ever 6y ago
  >Problem with that comic is that it doesn't take skill acquisition into account. I'd argue it can help skill acquisition to avoid getting into one thing too deeply, because the more different items you do, the more the commonalities appear; the more chances you have to see if your approach is optimal.
- smallnamespace 6y ago
  Knowing what’s important, and having the discipline to focus on it is one of the most important skills to acquire.
  - perl4ever 6y ago
    I think "having the discipline to focus on what's important" means consistently and periodically interrupting yourself, and asking "am I doing what's most important". I think there's a tension between this and the deep concentration or "flow state" that people like to talk about on HN. In effect, there are different value systems, and people have a hard time stepping outside of that.

bluedino 6y ago

I agree. Never underestimate a bad, but determined programmer. The worst part is he’ll feel extra smart afterward, because he finally figured out enough of the bugs in his horrible implementation to call it “done”, and he’ll likely be re-visiting this code for a long time to come, as issues pop out that he still doesn’t understand fully.

chaboud 6y ago
The energetic stupid programmer is the single most destructive thing you can have on your team and in your codebase. They make messes for everyone else, and a dummy writing bad code can produce more volume than even the best coder writing good code. Eventually, guardrails and processes get put in place to protect against their damage, and the whole team slows down. Good coders walk, and you're left with the dummies, cranking out a high volume of low quality code. It's absolutely tragic. When you build a flexible high-performance templatized system, hand it off, and realize a few weeks later that an energetic stupid coder has "written" more than 50 copied and pasted hard-coded classes from that codebase for the different places it was called from, only to have him and the non-coding manager push hard for sticking with that approach because the work is "nearly done", that's when you brush off the resumé and walk. Teams need workaday coders sometimes, and every coder should know how to just grind out a big refactor or massive change. However, I aim for coders who are lazy enough to find a cleaner way to do it and smart enough to know they can.
- yarg 6y ago
  But who reflects those values at company wide scales?
- paulie_a 6y ago
  The codebase is probably not that good to begin with and quite frankly doesnt need to be I think programmers have a chip on their shoulder about the importance of the work they do. You are not painting the sistine chapel Most programming is what you refer to as "workaday"
  - 6y ago

poisonborz 6y ago

> a beautifully elegant solution for a class of problem of which there will only ever be a single instance, which can be solved with 1 hour of bad scripting This is a stupidly common problem, and one that is hard to fight against. Why would you decline a good / inspiring part of the codebase, coupled with the unsureness that during the lifetime of the software this would come handy.