I think, as a founder you are missing the point that 99 out of 100 times you are told - explicitly or by work schedule "do not do it in an interesting, performant or elegant way, just get it working somehow and move on"

Oh I know (I also said so in my comment). And that's why I consciously try to distribute the interesting work between my coworkers and I. That way everybody gets a nice mix between "job" and "fun". Does that mean that sometimes I have to do crap? Yes. Does that mean that everybody gets to have fun at times? Yes.

If I can help it at all, I will not be the person responsible for somebody to write the rant that OP has posted.

Very well put, a nice mix between "job" and "fun". Except that most employers want their employees to do the "job" part of everything and do any "fun" parts in their spare time.

I think that good employers want their employees to enjoy their jobs (and hence, have some 'fun'). I manage a few folks, and want them to enjoy their work.

Of course, it's not all sunshine and puppies--there's grunt work that just has to get done, and everyone takes their share.

Crappy employers of programmers just want to exploit employees, just like crappy employers of other kinds of workers.

That's a shitty employer; 1. it's sadistic to require programmers not enjoy their work 2. if you've got a bunch of bored programmers you're going to lose your top-tier men and women to more interesting jobs.

> that 99 out of 100 times you are told - explicitly or by work schedule "do not do it in an interesting, performant or elegant way, just get it working somehow and move on"

Sure, we're in businesses (well, most of us), and there's little room for gilding the lilly or perfectionists who can't deliver.

That said, I've always found that elegant code is easier to maintain, thus reducing technical debt. If your employer doesn't want to reduce technical debt, you're either working for a start-up that's in a mad rush to 1.0, or you're working for someone who doesn't understand or care about the interest you pay on technical debt, and it may be time to move on.

Isn't that a challenge in and of itself? The majority of us are solving business problems, not technological ones.

If I can deliver something, even if not the most interesting or elegant, that gives the sales/marketing people giant, shit-eating grins, well, kudos to me. Usually, that means I'll be given time to go back and make enhancements, add functionality, or placed at the top of the list for the next cool project.

"um yeah nice, just ... remove the comments. And whats that tool? You can use Emacs for that! And we already have a mechanism for that just put a sub in <that> namespace and name it on_db_<whatever>_insert_trigger!"

Then I go home and write pure OO coffescript/C#. The company is great, but we have very different views on how software should be desigened.

I've never been told that. I've been told to get something done. How I achieve that has never been an issue. Interesting, performant, or elegant does not mean it has to be slow. That's part of the challenge. Meeting the demands of the business while meeting the demands of a professional.

In my experience, virtually every coding task takes longer to do "the best way" than the quickest or easiest way. Many times it takes much longer. Either you are a savant-like exception to this rule, or your velocity is (significantly) lower than it could be.

Don't get me wrong, I push for doing things the right way whenever I can, but acting like you can have it all with no compromises seems silly.

Depend on whether you are looking at the immediate time scale, (when "the best way" takes longer), or over the longer term, where it is often a lot better to sped the time up front, and have a good solution, rather than a quick hack.

>How I achieve that has never been an issue.

Lucky you, I have been there too. But at my current position, trying to use more modern technologies (Angular.js for example instead of a 15-year old stack without clean separation between front-and backend) to be more efficient is met with stares.

And I venture to say this happens very often in a lot of shops. At least outside of California.

my (less experienced) team leader is always going for the "just get it working solution". I often fight back to take the time to produce something more elegant, knowing that in two months time, my solution will not need fixing a second time.

Not to say your opinion doesn't count but theres a huge difference between being the founder of your own company and following orders from a pointy haired boss.

True being a boss is not all roses but your problems shift to a higher order, such as how can I build something customers would love... Versus how can I fix this trivial bug because my boss told me to?

I agree whole-heartedly ... There are very few days when I dread what I have to work on, and you can always find something to improve.

The "challenge" strategy can be intensely satisfying, but can also be very frustrating if that challenge is not shared by everyone on your team.

I've approached problems with goals like trying to do everything in a declarative functional style, and not passing nulls to avoid having to check for null. It's worked great, until we hand the code off to somebody else, with a new requirement, and that person breaks all the rules not because it's a particularly hard problem to solve, but just because they don't care.

It's an issue I'm currently working through right now, and I'm not sure if it's something to write a style guide/manifesto for, or if there's a better way to enforce it, or if it's just not a battle I should be fighting when dealing with an outside vendor.

Totally agree, I've done other jobs that are so many orders of magnitude worse than programming that it doesn't bear thinking about. For all its flaws, coding rocks as a career.