Hacker News Reader

Comment by umvi | Hacker News Reader

> As for me personally, without deadlines I tend to procrastinate.

I agree. Deadlines are highly motivating and help me determine scope of work I need to do.

"Make a tool that does X. You have infinite time."

Me: "Great! Maybe I'll implement it in Rust, I've always wanted to learn that. Or maybe I just research for a few days what's out there. And I'll need to think about testing infrastructure of course and benchmarking..."

vs.

"Make a tool that does X. We need it by Friday so we can use it for Y."

Me: "Ok! I can probably whip up something quick and dirty in python that gets the job done!"

View on HN

> "Make a tool that does X. We need it by Friday so we can use it for Y."

> Me: "Ok! I can probably whip up something quick and dirty in python that gets the job done!"

And this, when abstracted across an entire team or company, is what gets us unreadable code and hopelessly buggy software. Productive does not always equal effective.

The converse, when abstracted across an entire team or company gives us architecture astronauts that don't ever actually ship anything that works.

Great so we've established you want to be somewhere in the middle.

Meanwhile "I'll learn a new language to do this" when abstracted across an entire team or company leads to code that no one knows how to maintain when the one person who wrote it leaves.

I feel the same way about "clever" code. Most of the time "clever" code isn't really any more efficient than a naive approach, it's just a way for a developer to code golf at work by abusing / using uncommon syntax or idioms. Which is really a net negative since other people need to be able to read your code

Yep! "Clever" code always reminds me of Kernighan :

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

It seems to me that the smarter someone attempts to appear the less smart they truly are. True intelligence appears as clarity.

This is a problem of incomplete specifications.

"Make me a tool that extracts, collates and graphs data from this spreadsheet. We just need it to run once this friday"

"Done, super fast, slightly buggy python script it is!"

"Every month we need a tool to pull data from multiple sources, and push it to a reporting framework. It needs to be scalable and robust... oh and we need it by friday"

"Well, you're not getting it by Friday."

Deadlines should be a conversation, not a demand.

Fast<->Cheap<->Good/Pick 2 is up there with the second law of thermodynamics in its inviolability.

It's also what gets us great code and reliable software, when done properly. Engineering is all about tradeoffs. A major tradeoff is time versus... just about anything else. Deadlines help you know how to make that tradeoff properly.

One of the best old-school pieces of advice I ever got was "always throw away the first one". (Widely advised on comp.lang.perk.misc back in the 90s... Tom Christiansen is the name I've got mostly attached to it in my head.)

I'd read that as two requests.

1) "Make a tool that does X."

2) "Fast track a tool that does X by Friday so we can do Y."

The use the time prototyping X quickly to learn the entire space around solving the problem X, while mostly aiming to just solve the parts of the problem that will roadblock Y, with the agreement that this is only a prototype and while the Y team may choose to put it into production, there'll also be a much more complete set of requirements and specification of "The X tool", (which may well include Rust evangelism, proper testing infrastructure, performance benchmarking and scaling plans).

(Note: _most_ of the time this does not actually get acted upon, and I've got several hilarious war stories about "quick hacks to get us past next week's deadline" that out survived the company that I implemented it for. But a least I had it in writing...)

> always throw away the first one

That’s a quote from Fred Brooks’ The Mythical Man-Month (1975):

”[…] plan to throw one away; you will, anyhow.”

A deadline gives you the freedom to ship something imperfect.

Reply on news.ycombinator.com