Programming is boring

I don't get pleasure from writing code. It is actually kinda boring...you've (mostly) already figured out what you're going to do and you're just typing. Most of the time you're fighting against the limitations of whatever programming environment/language/framework you may be using. It's more boring the more familiar I'm with the problem I'm working on.

I get excited when I finish and I see the actual impact of people actually using something I created. Or when I'm in the problem solving mode and I'm learning something new.

That's why I enjoy being a software engineer, not because I spend all day typing on a keyboard.

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.

I imagine we can create artificial scenarios wherein we subject our code to rigged experiments. These experiments can serve to isolate parts of our codebases, pushing known values as inputs to the part and then inspecting the output for what we expect are correct values. We can posit theories about how our code should work, and then test those theories with experiments.

I envision a few benefits to these experiments:

1) isolating our modules to make experimenting easy may help to reduce the complexity of our programs.

2) overall 'correctness', whatever we define that to be, can continue to be verified over time as our programs change and grow as long as we update the expected values in our experiments at the same time or create additional experiments as needed.

3) the experiments themselves will serve as a kind of documentation of the codebase because they will show the code in action in fine detail.

What does everyone think of my idea? I know it sounds like an odd proposition, but science seems to work good in other disciplines. Maybe we can try it in ours?

>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.

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!