3 ms·

This times a thousand. I love programming but I want it to be boring. Boring means no stress, attainable deadlines, repeat ability, the ability to walk away, a

by tomc1985 10y ago

This times a thousand. I love programming but I want it to be boring. Boring means no stress, attainable deadlines, repeat ability, the ability to walk away, and the ability to tell these 10-hours-a-day hacks to fuck off. Boring means 5-nines reliability without a devops team because the design was simple, elegant, and most importantly worked. Boring means you're able to get it right the first time. Boring means being able to have a life, with other passions or hobbies completely unrelated to programming or code or geeks, which frankly everybody needs because we nerds are an unbearable bunch. I want to slap all these Show-HN innovation fetishists that reinvent the same thing over and over again. They make life worse for everyone.

AvenueIngres 10y ago
>I want to slap all these Show-HN innovation fetishists that reinvent the same thing over and over again. They make life worse for everyone. >we nerds are an unbearable bunch. 1/ No one forces you to use what someone show case to the community 2/ Creation is encouraged and this is good. That certainly isn't mutually exclusive with you being cautious about the tools you chose to work with. If you think a pre-alpha physic simulation framework is good to use for your nuclear reactor, you're the one to blame. 3/ Your diatribe on boring-ness is completely off-topic which makes me wonder if you actually read the article or jumped in because the title seemed fitting.
- tomc1985 10y ago
  Did YOU read the article? Dude extolls the virtues of a stable programming environment and I am simply providing examples from my own experiences boring-ifying previously exciting code. And you're right, noone forces anyone to use anything on Show HN. But do you not see anything wrong with a lot of these projects, where a fancy CSS-and-nodeJS-atrocity slides and glimmers around the fact that it's hiding alpha-quality code? (Rehashing production-level ideas no less) Sure we on HN know it's just show-and-tell, but what about others? Just yesterday there was a Show HN that was all web site and no product -- in fact I think it used more screen space to document what their project lacked as opposed to what it had. If what was posted a zip with a readme.txt that'd be one thing, but instead we have ideas masquerading as products. Just as bad are all these security wonks that need to give their vulnerabilities nice, marketable nicknames. It was effective the first time, but now it's just obnoxious -- file a CVE and let the community decide!
jkchu 10y ago
I agree with your notion of the importance of balance in a developer's life. I think work-life balance is important, no matter what your profession is. However, behind every successful, well-crafted software project are still business needs and decisions. And a lot of the time, these businesses' success can rely on being faster than competitors. Obviously it is ideal to have attainable deadlines, but it is not always possible. Inevitably, there will be times of stressful, tight deadlines. With your firm attitude, I'd be curious to see how you might handle those situations.
- tomc1985 10y ago
  I'm able to roll with business deadlines as needed. Programming can actually be a very quick, predictable endeavor once necessary infrastructure and management expectations are in place. As with all jobs, one needs to manage their manager (and management) to make sure expectations are in line with requirements and availability. Built-up influence, gained from prior successes, helps a lot. Also: be in an industry where you're the last man standing and barriers to entry are high. Really helps dealing with competition-influenced deadlines :)
rezashirazian 10y ago
You just described the fixed mindset to a T. https://www.brainpickings.org/2014/01/29/carol-dweck-mindset/ https://www.brainpickings.org/2014/01/29/carol-dweck-mindset...
- tomc1985 10y ago
  How? I've seen this chart and it has very little to do with what is described above. My point isn't that people should reject challenges, or to push back unnecessarily when confronted with pressure, or resist deadlines. The point is that you optimize your environment, methodology, tool usage, workflow, designs for simplicity, and that when you've done so it grants a level of control and predictability over one's work that it would appear you guys think is unattainable. The above mindset embraces challenges by controlling for their parameters, and when confronted with a challenge too large you break it up until the pieces are something that one can assert control over. If that's still too much then you start shaving off requirements, and if that's still too much then yes, you might have to dive in and power through it. But that's where the boring mentality saves you: "diving in" and "powering through it" become more like a light swim than a sprint or marathon. Plus, when the code is simple and predictable its very easy to make estimates and then you can give yourself a larger deadline than you need. Obstacles are confronted and plowed through -- but again this is not as difficult because the system is simple enough that most of it can be held in one person's head. When that fails, though, a little bit of creativity can get one out of a bind. Effort... well you got me there. Less work is always better. Smart work, not hard work. If you are working hard, step back and think for a minute, because you are doing it wrong and you should probably optimize. There are very few scenarios for which this rule doesn't apply. I don't see how my assertions have anything to do with feedback and criticism, other than to say that there is not as much in the bugs department because the boring system generally works. How one handles feedback has little to do with the other components. It should also be noted that my mentality DOES involve a lot of questioning management, but that is because management desperately needs questioning. When a cabal of socializers and non-technical soft-power types try to run a technology-centered business, they require a lot of course correction so that development can continue unhindered and not get distracted with silly little initiatives (or whatever the third-party enterprise sales hacks walked through the door with this week)

AvenueIngres 10y ago

>I want to slap all these Show-HN innovation fetishists that reinvent the same thing over and over again. They make life worse for everyone. >we nerds are an unbearable bunch. 1/ No one forces you to use what someone show case to the community 2/ Creation is encouraged and this is good. That certainly isn't mutually exclusive with you being cautious about the tools you chose to work with. If you think a pre-alpha physic simulation framework is good to use for your nuclear reactor, you're the one to blame. 3/ Your diatribe on boring-ness is completely off-topic which makes me wonder if you actually read the article or jumped in because the title seemed fitting.

tomc1985 10y ago
Did YOU read the article? Dude extolls the virtues of a stable programming environment and I am simply providing examples from my own experiences boring-ifying previously exciting code. And you're right, noone forces anyone to use anything on Show HN. But do you not see anything wrong with a lot of these projects, where a fancy CSS-and-nodeJS-atrocity slides and glimmers around the fact that it's hiding alpha-quality code? (Rehashing production-level ideas no less) Sure we on HN know it's just show-and-tell, but what about others? Just yesterday there was a Show HN that was all web site and no product -- in fact I think it used more screen space to document what their project lacked as opposed to what it had. If what was posted a zip with a readme.txt that'd be one thing, but instead we have ideas masquerading as products. Just as bad are all these security wonks that need to give their vulnerabilities nice, marketable nicknames. It was effective the first time, but now it's just obnoxious -- file a CVE and let the community decide!

jkchu 10y ago

I agree with your notion of the importance of balance in a developer's life. I think work-life balance is important, no matter what your profession is. However, behind every successful, well-crafted software project are still business needs and decisions. And a lot of the time, these businesses' success can rely on being faster than competitors. Obviously it is ideal to have attainable deadlines, but it is not always possible. Inevitably, there will be times of stressful, tight deadlines. With your firm attitude, I'd be curious to see how you might handle those situations.

tomc1985 10y ago
I'm able to roll with business deadlines as needed. Programming can actually be a very quick, predictable endeavor once necessary infrastructure and management expectations are in place. As with all jobs, one needs to manage their manager (and management) to make sure expectations are in line with requirements and availability. Built-up influence, gained from prior successes, helps a lot. Also: be in an industry where you're the last man standing and barriers to entry are high. Really helps dealing with competition-influenced deadlines :)

rezashirazian 10y ago

You just described the fixed mindset to a T. https://www.brainpickings.org/2014/01/29/carol-dweck-mindset/ https://www.brainpickings.org/2014/01/29/carol-dweck-mindset...

tomc1985 10y ago
How? I've seen this chart and it has very little to do with what is described above. My point isn't that people should reject challenges, or to push back unnecessarily when confronted with pressure, or resist deadlines. The point is that you optimize your environment, methodology, tool usage, workflow, designs for simplicity, and that when you've done so it grants a level of control and predictability over one's work that it would appear you guys think is unattainable. The above mindset embraces challenges by controlling for their parameters, and when confronted with a challenge too large you break it up until the pieces are something that one can assert control over. If that's still too much then you start shaving off requirements, and if that's still too much then yes, you might have to dive in and power through it. But that's where the boring mentality saves you: "diving in" and "powering through it" become more like a light swim than a sprint or marathon. Plus, when the code is simple and predictable its very easy to make estimates and then you can give yourself a larger deadline than you need. Obstacles are confronted and plowed through -- but again this is not as difficult because the system is simple enough that most of it can be held in one person's head. When that fails, though, a little bit of creativity can get one out of a bind. Effort... well you got me there. Less work is always better. Smart work, not hard work. If you are working hard, step back and think for a minute, because you are doing it wrong and you should probably optimize. There are very few scenarios for which this rule doesn't apply. I don't see how my assertions have anything to do with feedback and criticism, other than to say that there is not as much in the bugs department because the boring system generally works. How one handles feedback has little to do with the other components. It should also be noted that my mentality DOES involve a lot of questioning management, but that is because management desperately needs questioning. When a cabal of socializers and non-technical soft-power types try to run a technology-centered business, they require a lot of course correction so that development can continue unhindered and not get distracted with silly little initiatives (or whatever the third-party enterprise sales hacks walked through the door with this week)