Hacker News Reader

Comment by WalterBright | Hacker News Reader

Some people work effectively only if you micromanage them. Some work effectively only if you're hands off.

There is no one technique fits everyone.

As for deadlines, you cannot manage a complex project with multiple teams without deadlines. After all, if you're building a car, you can't afford to hold up everything while you wait for the wheel department to get around to delivering wheels.

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

View on HN

> 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!"

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

For my own work, I find there's actually only a given quota of 'stuff I actually want to do' on a given day. If I'm not in a good place (health, mental health, etc) this number is much lower than if I were in a good place.

Generally I unconsciously categorize tasks that I remember I need to do* (or that a task list helps me remember) a kind of emotional score relating to their ease of accomplishing, the need to get them done today / sooner vs later, and how big a work slot I feel I have to pack them inside of.

I have noticed that tasks which are perceived as easy or quick to accomplish tend to get fulfilled faster; I can clear the item out of my mental list and it can be squeezed in to moments that would otherwise not be productive.

Tasks with external dependencies (meeting others, scheduling anything at all with anyone else, waiting on external approval processes) are clutter that stuffs up my mental caches, but isn't quite something that I can clear out either.

The inability to clear those things out becomes a type of stress, and creates a negative feedback loop of it's own.

Foreknowledge of those issues, as well as scheduling constraints for doing things, often leads to the estimation that a task which might otherwise be easier (for example if moving fast and breaking things) to cost more (only break things during limited, pre-announced windows).

If a person is self aware enough to know they need to be micromanaged than maybe they could request more hands on management. I think one of the points of the article is that many managers assume there is a need for micromanagement and over all that type of management is demotivating and hurts productivity and creativity. I’d argue most people want to do good work if their needs are met and they are in the right environment

Some people who don't think they need micromanagement actually do. The problem is they keep diverting and working on something else, and need to be continually reset back on to the critical path. A good manager will adapt to what works best for the particular employee.

It'll take some time, though, for a manager to learn that a particular person can be trusted with a hands-off style. I've tended to default to hands-off as a manager, sometimes with expensive results.

I've had the same experience as a hands-off manager. In almost all of those cases I should have let the person go instead of trying to improve how I manage them. Hind sight and all and choosing to let someone go can be difficult, but still

The ultimate guy who didn't need managing was Richard Feynman. Just put him on the payroll, and great things will happen!

I feel like the author is an extraordinary individual, perhaps sharing some traits with someone like Feynman, but is not aware of how far they deviate from the mean. Although this is the recipe for success with high performers, most people have less discipline and will implode.

A good manager shouldn't resort to micromanagement even if the employee requires it. You're not supposed to be their secretary or mommy. A good manager would coach or train them to become more organized. A manager is responsible for supporting their employees' growth, but the employees also have a personal responsibility to develop their skills on their own.

In the long run micromanagement sets them up for failure. You're not going to be there for them forever. If they can't improve their organization skills to a point where they can complete work on their own, then they might not be suited for their job.

You can't deliver the car until the last piece is bolted onto it.

There's only so much value in celebrating having the first half of the car put together. It still won't tell you when it's ready to ship. Especially if you've assembled it in the wrong order...

You can ship a car with an engine that goes 0-60 in 10 seconds. Then you can ship the next car with an engine that does it in 7. If you try to develop an exact thing by an exact date, you're bound to either ship something that's broken on the date, after a lot of heart-ache, or to ship something that works late, after a lot of heart-ache. Then, good luck getting your people to make the next product better. All the cards were played; all the bridges were burned; and you got a shitty product.

Instead: let's ship the best working car we can by <date>! And here's why that date. Who has ideas for how to get an even shittier completely working first-iteration done six months before that? Now, go figure it out and make it happen. I trust you. (To self: and I'll trust you even more as I see each shippable iteration that you enjoyed making.)

It also changes task to task and person to person. I'd very much consider myself a self-starter and self-motivated, but if I'm given a task that's mundane and carries no creative aspect then a one day task can take me a whole week.

Reply on news.ycombinator.com