Live data from Hacker News

How Paul Graham Is Wrong

ma.tt

171–180 of 206 posts

Re: How Paul Graham Is Wrong

#171

Earlier quoted context omitted.

> sometimes the most productive thing you can do is stop a programmer from writing code. I have little to dispute about this statement, but I disagree that being colocated has any effect on this (unless stopping them 4-5 times a day will truly make the team more productive; at which point a manager needs to step in and fire that person ASAP). > The value of colocated employees is being able to really quickly recogniz…

From personal experience, the most common way this comes up is that you have a casual hallway conversation with a colleague, they ask "So what are you working on these days?", you tell them, and they respond with "You should talk to so-and-so, he worked on that a year ago and may have some insights" or "Have you heard about technology Foo that's designed just for that problem?" And then you follow up on that lead and…

This still makes the assumption that these kinds of watercolor conversations are unable to occur online. They do, either in the form of chat logs, or voice calls prior and after meetings, or just as two people get the desire to BS for awhile after coding.

These behaviors are simply not constrained by the environment, not anymore.

Re: How Paul Graham Is Wrong

#173
post #128
post #75

Earlier quoted context omitted.

Harder problems than the Linux kernel? I've been remote for eight years now and I work on a codebase so huge that no one person understands it all beneath the 10,000 foot level. Nearly all of us are remote (only the managers are "local" to San Jose). Once a quarter we get together and meet up, coming from Vancouver, Toronto, Bangalore, Colorado and northern California.

Yes, kernels are not difficult because most of the problems are purely technical problems, that programmers can just decide for themselves any ambiguities, and many of the parts can be worked on separately. Software with users is 10-100x more difficult. http://c2.com/cgi/wiki?WhyIsPayrollHard

Sorry if I was unclear. I was just using Linux as an example. The product I work on has plenty of users. I don't agree that it's orders of magnitude more difficult but that's beside the point.

Re: How Paul Graham Is Wrong

#174
post #101
post #81

Earlier quoted context omitted.

In my eight years' remote working experience, your statement is false.

What he is saying is that it is harder, not impossible. Are you saying that remote work is as good if not better than being physically-located?

I'm saying that's it's not harder. Thus his statement is false.

Re: How Paul Graham Is Wrong

#175
post #80
post #38

>Use WordPress and P2, use Slack, use G+ Hangouts, use Skype, use any of the amazing technology that allows us to collaborate as effectively online as previous generations of company did offline. I've been a 100% remote worker for 5+ years but I think we have to be honest here. All those teleconferencing/videoconferencing/virtualwhiteboards/etc are not as effective as everyone sharing the same physical workspace. Yes…

Agreed. I don't have a solution, but this frustrates me to no end. As a software engineer that previously worked in an open floor plan I can testify that they absolutely crush individual productivity. Headphones are no solution. I think I'd need a potato sack on my head too. But as a software engineer that currently works with geographically distributed teams, there's no way to deny that certain elements of communica…

What you typically do is work remote and meet in person once in a (long) while. This is how lot of open source projects work.

Re: How Paul Graham Is Wrong

#176
post #140

Earlier quoted context omitted.

I agree with your first paragraph 1000%. One of my old start-ups had white boards everywhere (when we ran out, there were windows...) and ad-hoc bi-lateral marker-of-death struggles would spring up anywhere all day long. That was super handy. I've mostly been an independent lone-ranger type for a long time now, and have rarely met most of my clients face-to-face -- but I do miss at-the-drop-of-a-hat white board sessi…

Did you mean "disagree"? Can't tell what your point is. I like f2f problem solving too - whiteboarding, high energy, etc - it has its place.

I mean "agree". My point is that the hassle is a hassle -- the f2f problem solving sometimes makes it worth it. Not often enough to make the decision cut-and-dried.

Re: How Paul Graham Is Wrong

#178

Earlier quoted context omitted.

Thanks - that's an interesting point of view. If I were running a company with hundreds of employees&contractors that would be a point of concern. However from a bootstrapped startup perspective that probably does not even worth investigating further. Everyone is free to sue for anything. That's the cost of doing business. Hiring foreigners directly as employees has many other risks in addition to having inevitable o…

This is an example of what I think is a common and very damaging metafallacy in startup entrepreneurship: the basic business safeguards we don't pay attention to because they don't seem to matter until our companies get big. But these are some of the worst problems, because they submarine. You pour the money, sweat, and (most importantly) time into an enterprise, risking its total failure. You stick with it, your com…

I don't get it.

There is no reason to sue struggling startup, because if you sue for too much then the startup would simply fold.

That's the main way startup protects itself.

Struggling startup usually does not have funds to lawyer up.

BigCo on the other hand is a very attractive target, but has funds to lawyer up.

If struggling startup successfully transitioned to BigCo then potential exposure from past shortcuts is small (relative to BigCo revenue).

How could "contractor vs employee" shortcuts applied in 4 people startup be a significant problem for BigCo (which already transitioned into lawyered up way of doing business)?

Re: How Paul Graham Is Wrong

#179
post #89
post #60

Meh. Here is the tradeoff. If everyone is co-located, you have inconvenience and higher productivity. If everyone is remote, you have an inherent overhead, but enormous flexibility. If some people are co-located and others are remote, you naturally tend towards a divide where people who are co-located without thinking about it wind up networking with each other and excluding the remotes. If you are a small startup, t…

I think you might be mistaken in the assumption that remote working leads to less productivity than co-located. This is purely up to the team. Sometimes being co-located leads to over meeting and lots of time spent on disruptions and chats, while remote working lead you to be more professional and talk to your co-workers only when necessary for the job.

I think my assumption is justified. To address your suggestion, it is safe to say tht early stage startups which are inclined to over meeting are guaranteed failures no matter what.

Re: How Paul Graham Is Wrong

#180
post #113

Earlier quoted context omitted.

> Real time communication That implies a time zone with a lot of overlap. Rome/Berlin time is 9 hours ahead of San Francisco, meaning there really isn't a lot of overlap. Real time communication also means that you need to consciously set up the call and pay attention to it. Sometimes I overhear something at work, or we talk about something interesting at lunch, or there's an "oh shit" moment (not often:-) when it's…

Yeah, time zones are easily the biggest problem. Even then, however, it's not that hard to find an overlap. I worked successfully with developers from England, Ukraine, and India for several years. Took effort on both of our parts to make it work, but work it did.

> Even then, however, it's not that hard to find an overlap

0900 my time is 2400 west coast time. No overlap there. 1700 here is 0800 west coast time. Granted, I don't leave that early from work, but not all programmers are "in the office by 9" people either. There's not a lot of overlap.

> I worked successfully with developers from England, Ukraine, and India for several years. Took effort on both of our parts to make it work, but work it did.

I don't doubt it's possible, and even the best solution for some people in some situations. But not for everyone.

Post reply on HN