Live data from Hacker News

Busyness is Not a Virtue

blog.idonethis.com

21–30 of 35 posts

Re: Busyness is Not a Virtue

#21
post #8

Earlier quoted context omitted.

I wonder about that kind of argument. I find it super appealing because I would love to work a lot less and yet get more done. Unfortunately I've found that if I work more, I do get more done. Granted, there's a time for stepping back and thinking about a problem rather than continuing to brute force your way through it. And you can get to a point where you spin your wheels and it's better to stop. But generally, mor…

Software development is a created process, like writing fiction. Imagine a fiction writer doing a 60 hour (or hell, even a 40 hour) work week to try and get more work done. It just won't work, certainly not long term.

But you do need to put in the practice time to be able to be productive when you need to be. If your process involves a lot of procrastinating with intermittent bursts of brilliance ,you won't be able to be relied upon when things get tough. Stephen King became the writer he did because his wife would tell him to write a story, the baby needs diapers, and he did.

So before you can work smart, you have to know how to work hard. Otherwise you're just goofing off.

Re: Busyness is Not a Virtue

#22
post #4

My mom always going around telling how busy she is, just annoying as hell...

Mothers, especially those of young children, tend to be legitimaly, significantly busier than most of the other people.

I liked reading this after reading the poll about how old average HN readers are. Different ages have different priorities. Sometimes people aren't busy simply because they want to be important, or feel that they are better than you, or have over extended themselves. Sometimes people are actually busy.

Depending on where you are in life, sometimes you realize that the "Terrible Trivium" is actually the people around you who keep demanding focus.

Re: Busyness is Not a Virtue

#23
post #10

Earlier quoted context omitted.

It's funny, many coders are smart enough to figure out that the solution to an O(n^2) algorithm is typically not more CPU cycles but changing to an O(n*log n) algorithm (or what-have-you). Yet they often refuse to make the same observations when it comes to their own productivity, they just throw more cycles at the same algorithms and expect that to be the optimal solution.

This also applies to "scaling." Scalability seems to be a major boogeyman among tech startups. The way you make something scalable is by improving the big-O of your processing algorithm, and the way you do that is not by throwing money and processing power at it (buying more servers, hiring more developers with "scaling experience," etc.), but by optimizing your application logic to do as little as possible per input…

Not to detract from your metaphor, but I think the main problem with scaling is to make as much as possible parallel, so that you can throw more cores / servers at it. Often this is at the expense of raw big-O efficiency I guess.

I guess in terms of your business metaphor, that would be establishing 'big company' things like written processes, constrained departments, and managers who don't code, so that more people can work for the company than the founders can talk to in a week.

Re: Busyness is Not a Virtue

#24

Less is more, as in coding.

It's funny, many coders are smart enough to figure out that the solution to an O(n^2) algorithm is typically not more CPU cycles but changing to an O(n*log n) algorithm (or what-have-you). Yet they often refuse to make the same observations when it comes to their own productivity, they just throw more cycles at the same algorithms and expect that to be the optimal solution.

I agree. If I spend a week doing more than around 20 hours of work, then I'm usually doing something wrong. The following week, I will spend some time trying to figure out what went wrong. There's usually always a better way.

Programming is the perfect lazy-man's work. If you're really good at changing O(n^2) to O(1), then you can pretty much double the output of other teams while also reducing your work. It's pretty fun.

Also, this applies at scaling. If my business model can't afford to hire more people as the demand for the business grows, then the business model is just a bad idea.

Re: Busyness is Not a Virtue

#25
I think the meaning behind "I am so busy" sometimes is just a true statement and nothing more. I don't automatically assume the person saying it is bullshitting me in some way. That said, I never say it. I'm usually the one complaining about how I'm not busy enough, which is probably just as annoying.

Re: Busyness is Not a Virtue

#26
post #25

I think the meaning behind "I am so busy" sometimes is just a true statement and nothing more. I don't automatically assume the person saying it is bullshitting me in some way. That said, I never say it. I'm usually the one complaining about how I'm not busy enough, which is probably just as annoying.

Agree that we do in reality get busy, and it's a legit thing to say at times. My sense is the perpetually "I'm so busy" types are the subject of the post.

Re: Busyness is Not a Virtue

#29
post #8

Earlier quoted context omitted.

I wonder about that kind of argument. I find it super appealing because I would love to work a lot less and yet get more done. Unfortunately I've found that if I work more, I do get more done. Granted, there's a time for stepping back and thinking about a problem rather than continuing to brute force your way through it. And you can get to a point where you spin your wheels and it's better to stop. But generally, mor…

Software development is a created process, like writing fiction. Imagine a fiction writer doing a 60 hour (or hell, even a 40 hour) work week to try and get more work done. It just won't work, certainly not long term.

Yes, it is a creative process. I think that a better analogy is to a scientist though. Sometimes, scientists spend a lot of time thinking about what an experimental result means and planning out their next set of experiments. But oftentimes, they also have to crank through a bunch of experiments that they've planned. The more time they spend at that point, the further they get.

Re: Busyness is Not a Virtue

#30
post #23
post #10

Earlier quoted context omitted.

This also applies to "scaling." Scalability seems to be a major boogeyman among tech startups. The way you make something scalable is by improving the big-O of your processing algorithm, and the way you do that is not by throwing money and processing power at it (buying more servers, hiring more developers with "scaling experience," etc.), but by optimizing your application logic to do as little as possible per input…

Not to detract from your metaphor, but I think the main problem with scaling is to make as much as possible parallel, so that you can throw more cores / servers at it. Often this is at the expense of raw big-O efficiency I guess. I guess in terms of your business metaphor, that would be establishing 'big company' things like written processes, constrained departments, and managers who don't code, so that more people…

I'm no expert in scalable algorithms, but my rudimentary understanding is that there are a few different ways to handle a problem with n inputs when n becomes a very large number:

1. Run it on a faster processor

2. Rewrite your algorithm so that it can run in parallel and the tasks can be divided among more cores/processors/servers

3. Rewrite your algorithm so that it's non-locking and the tasks can be completed asynchronously

4. Rewrite your algorithm so that each task takes less time (fewer/faster queries, fewer array accesses, fewer object instantiations, etc).

In terms of the analogy, #1 is equivalent to working harder on the problem--just throwing more time/money/energy at it. Staying late at the office. This is the wrong approach in programming and in life, because it does not scale with the size of the problem.

#2 and #3 are basically division of labor and task delegation in order to divide the time that it takes to complete the problem. This gets the job done faster but at a cost--you're paying for more heads to work on the job.

#4 is finding a better/cheaper/faster way to do each individual task or sub-task in the problem. It's improving your big-O. Having a better big-O alone will not make #2 and #3 unnecessary, but it will exponentially increase the effect of #2 and #3. It's what business types call a "force multiplier." It's really just reducing the amount of sub-tasks an individual worker has to do in order to satisfactorily complete a task. It's achieving the same thing by doing less.

Post reply on HN