Comment by HeyLaughingBoy | Hacker News Reader

Comment by HeyLaughingBoy | Hacker News Reader

Parent Full thread

That ability to switch it off is very important. A couple months ago, one of my co-workers was asked to do something quickly for an important customer. I would normally be the one to work on that codebase, but I was busy with something else. I gave him some suggestions, made it completely, crystal clear that hacks were allowed since the customer needed it by the next day at the latest and it only had to run for a few hours and we could use the excuse that it wasn't under version control if they wanted changes later.

He's a very good engineer and this was well within his ability, but he became hamstrung by the hackiness. He continually complained that it would be unsupportable (I know), that he would be asked to make changes (no: this was explicitly part of the agreement with the customer) and it was a bad design decision (yes!).

By the time 4 o'clock rolled around, he had made little progress on his well engineered and future-proof solution and I didn't want to be there late, so I offered to take it from him, finished the hack by 4:30 and pushed it to the customer.

Customer loved it; greatly appreciated that "we had dropped all our work to put two engineers on their project" and it did exactly what they needed to demo their own product.

I guess my point is that engineering is about getting stuff done. Sometimes, if you know time is more important than anything else, your only choice is either cut corners or don't ship. Being a day late can be the same thing as never shipping in some cases.

I agree with your approach here. However, there's one interesting problem we always run into with that approach and it's what causes the discontent, I think.

It's when something that is being designed and built with the intention of a short lifespan ends up being around for a long time, and causing problems for longer than it was intended to exist at all.

And I think this happens all the time.

I think you did the right thing (I would have too), but unless you have solid consistency, work ethics and a great memory, you may put in that quick fix and it never gets improved.

If the quick fix stands the test of time, then it was the right fix regardless of how fast it was done.

I guess that is why I have grown into the approach over the years of always.. ALWAYS checking expectations thoroughly, even when it hurts a little.

It's important in the early stages of problem analysis to know - 1) how long do I have to analyze the problem? 2) how long do I have to implement a solution to the problem? and 3) how long does the solution need to last? Of course there are a million other questions, but I think it needs to start there. Of course, while answering those questions, as a service function, we must always be thinking... hands down.. what is in the best interest of the customer (which can be subjective, but it must always be the forefront)?

If you are given constraints for those 3 things, you can more accurately come up with an appropriate solution. My experience with this is hard-earned from just doing and always having to get creative.

Sometimes, I plain ask people - do you want a long-term solution, or a short-term solution? If you can come up with 3 options quickly based on your experience - short/mid/long-term and give the pros and cons, I've found most business users like this approach. Some prefer to just be given an answer and have the issue handled immediately - however, that isn't always the best for them nor the people doing the work. But, as they say, sometimes it comes down to "needs must".

There are few things as permanent as a temporary solution.

When I see yet another “# TODO: this a hack, it’s doesn’t really work but we’ll fix it asap anyway” I like to make bets with myself as for what date I’m going to see in git blame. Today I’ve replaced one such 3yr old todo with another todo that someone else will probably discover three years from now. The reality...

I think if you're a profitable company some percentage of engineering effort should be carved out for continuous refactoring. I'm sure there is a good balance in there somewhere.

it's one of the biggest weaknesses that engineers/programmers/logical, problem-oriented thinkers have. doing something quick and hacky when it doesn't need to be flawless just feels so wrong. you miss that feeling, that rush when a perfectly-engineered solution just snaps into place and works like magic. and that becomes a problem when it begins to interfere with deadlines, like in your story.

i think that's a big part of programming as a career, learning to know when to make something run flawlessly, and when to make it just... run.

Ehh, the problem here seems to be less about logic and more about misaligned priorities in the context of business. There’s a lot to be said about the dopamine rush of making a client happy!

> learning to know when to make something run flawlessly, and when to make it just... run.

Or learning that user has a very different meaning of flawless, and that is almost always the more important definition.

Trying to bootstrap my own startup and doing all the engineering on my own money my engineering philosophy has changed dramatically. Where I used to be guy A, I'm now very much guy B.

nothing like financing yourself resources to understand that time indeed is money

In those cases it should be documented that it is a have and also limited in scope so that other stuff doesn't really on it. If it's a small one off, no biggie.

THIS.

Mediocre now beats great tomorrow more often than not.

I saw a diagram once from an MS programmer, I wish I could find it - it was the evolution of code... and it went something like:

Totally Crap -> Less Crappy -> Just Crap -> Starting to get half decent -> Actually not too bad and working -> EOL

> Mediocre now beats great tomorrow more often than not.

This reminds me of Patton's Law of Program Planning from Akin's Laws of Spacecraft Design[1]:

> 33. (Patton's Law of Program Planning) A good plan violently executed now is better than a perfect plan next week.

[1] https://spacecraft.ssl.umd.edu/akins_laws.html

Engineering is not about “getting stuff done”, but what you’ve described isn’t engineering. The word is thrown around too loosely in the software world.

Reply on news.ycombinator.com