Ask HN: Switching to Developing on Windows from Mac - <AUTHOR> I've been mostly on a mac for the past 6 years professionally and personally. I'm about to switch up my daily driver to a Windows box. I'm looking for any tips when it comes to a 'modern' development toolkit for someone who's been enveloped within the the mac/unix ecosystem for the past few years but is making a switch. I love my tools, and would love to hear what people's kits are comprised of and why.. I feel it'd be useful even if we work on completely different stuff.
More context: I was a windows user and then developer from windows 95->10 and then went mac full-time when I wanted a nice laptop and began dabbling with iOS dev more seriously. Since then I've found myself accustomed to the unix terminal, homebrew, and a ton of other tools and things like that which I use on a daily basis for work and side-projects. Right now mostly node/javascript and other front-end/web stuff.
The new computer arrives later this week so I started googling "windows alternative to x", so figured I'd see if anyone on here recently switched from mac to PC... Any tips? Anything to be super happy about? Any things I'll need to work-around?
Things I'll be taking with me...
- VScode - Creative Suite
Things I know I'll miss...
- homebrew (+ a ton of stuff that I manage w/ this) - iTerm - oh my zsh - spotlight & alfred - iStat Menus - Spectacle - rocket
- native git?
Things I've heard to use... - powershell (how does this compare to how I use iTerm?)
ps. I don't want to use Linux on this computer, and pardon the formatting/braindump for this post. :-) <comment><USER2> Look into Cmder ([http://cmder.net/](http://cmder.net/)) for an alternative to iTerm/zsh. You can also try Babun ([https://babun.github.io/](https://babun.github.io/)).

Try Wox ([http://www.wox.one/](http://www.wox.one/)) as a replacement for Alfred.

And Chocolately ([https://chocolatey.org/](https://chocolatey.org/)) and Scoop ([https://scoop.sh/](https://scoop.sh/)) to replace Homebrew.

</comment><comment><USER3> The Linux subsystem for windows makes my workflow nearly identical, and is absolutely better than something like putty.

<comment><USER4> I've heard that disk I/O is excruciatingly slow. Has that been your experience?</comment></comment>


The Internet Is Splitting in Two Amid U.S. Dispute with China - <AUTHOR> https://www.bloombergquint.com/technology/the-internet-is-splitting-in-two-amid-u-s-dispute-with-china <comment><USER2> Which zones/ISPs are going with China? As near as I can tell, absolutely nothing good comes from Viet Nam, Turkey and Ukraine ASes. If they go with PRC's Internet, we'll all be better off.</comment>


Three arrested for tweets - <AUTHOR> http://www.thenorthernecho.co.uk/news/10444339.Three_arrested_ahead_of_English_Defence_League_protest_in_Newcastle/ <comment><AUTHOR> Alarm bells should be ringing for Muslims. I strongly suggest they start pro- actively cleaning up their own messes because the street is losing patience.</comment>


Yahoo Acquires Astrid - <AUTHOR> http://techcrunch.com/2013/05/01/yahoo-acquires-to-do-app-astrid/ <comment><USER2> (from <https://news.ycombinator.com/item?id=5642484>)

I don't want to take anything away from Astrid.

I keeps dismissing my ideas as trivial and already done. When I think I have a new idea, my friends would dismiss it as trivial and already done. Take astrid's todo list or task sharing for example. My initial and only thought would be 'does the world need another todo app', 'another list making app' really? If I take the idea to my friends, they would bombard me with companies who do exactly the same thing. And yet here we are with Astrid being acquired. It seems to have some angel investment/funding even. The founders may not be millionaires but they definitely made more money than I did.

Note to self: do something. anything. and get acquired.

<comment><USER3> "Make something people want" is too esoteric?

Astrid was founded in 2008. If step (a) is above, and step (b) is simply "Persevere", then such a note to yourself becomes:

 _Make something people want. Persevere._

Somehow that seems far more likely to end in the manner you'd like.

<comment><USER4> The perseverance component is often overlooked, I personally believe it is the single most important factor determining the eventual success or failure of a business.

</comment></comment></comment><comment><USER5> > _The app will remain online for another 90 days before it's shut down by > Yahoo. In the meantime, it's not accepting any new users._

Well, crap. Any migration path or alternatives? I don't even need 99% of Astrid's bells and whistles, just your basic "add entries and tick 'em off" todo list along the lines of what the Palm V used to do.

<comment><USER6> How about Google Tasks?

I rely on this with Gtasks on Android every day as my main note taking vehicle. I find it especially useful for literally instantaneous syncing between phone, tablet, desktop, and laptop.

Here's a way to access it via its own independent window (I keep this pinned in my browser):

<https://mail.google.com/tasks/ig>

<comment><USER7> I would very much recommend trying this one: <https://mail.google.com/tasks/canvas?pli=1>

<comment><USER8> What does pli=1 at the end do? I can't see any difference from the same url I use (yours) but without that.

<comment><USER7> quite possibly nothing. it just autocompletes from my history that way, and I forgot to clean it up.

</comment></comment></comment></comment></comment><comment><USER9> <sarcasm> I thought Yahoo was in trouble and had a glut of employees. Rather, it seems they have found a pot of gold and don't have enough employees to execute their plan for world domination. </sarcasm>

</comment><comment><USER10> Astrid ran hard to make an app that millions of people use constantly. As a startup, they took a risk, ran hard at an idea, and executed their ass off.

We should all be so lucky.

Regarding this "acquihire" talk:

This is something the naysayers like to talk about. Yahoo's scale present an incredible sandbox for the Astrid team. They are a fully contained, highly functional team (across product and engineering disciplines). They know how to build back-end systems, complex web-apps, and cross-platform mobile apps.

The fact that someone found a higher and better use is not a failure on their part. Yahoo is fortunate to have this team join their ranks.

<comment><USER11> I agree. I left Yahoo during the Scott Thompson time, but see the value in Mayer.

I love Yahoo, always have, but I'm hoping that Mayer cuts out 2-3 layers of management. When I was there, it was embarrassing to talk to my boss, who clearly didn't give a shit about my team or our department.

The dude did nothing but suck up to Sunnyvale. Hopefully they fire folks like him.

</comment></comment><comment><USER12> > Yahoo Acquires 4M-User 'To Do' App Astrid, Will Shut It Down In 90 Days

I'm afraid I'm not familiar with what scale Yahoo operates on, but wouldn't it be more beneficial for them to merge Astrid into whatever their plans are rather than drop them and alienate people who were already users?

Or was it just seen as a potential resource hole (with the value of the users seen as negative)?

Can anyone shed some light on what Astrid's business model was?

<comment><USER13> it's an acquihire. they are not buying any product. (peanut butter spread too thin, etc)

they just have a lot of money to hire, and nobody wants to work there.

So they do the dumbest thing a company can. Spends 10~30million a head, and they are out the door as soon as their contract allows. (case in point, your host. and he was even a case where yahoo wanted to buy the product...)

oh, and they are so sure everyone is leaving, that the new policy (look it up, was on techcrunch) is to give out annual bonuses instead of pay rises and promotions.

</comment></comment><comment><USER14> I used Astrid for a while and just switched over to Google Keep a couple weeks ago. I highly recommend it for people who just want simple synced to-do/notes.

Yes, they could Google-Reader-it at any time, I suppose, but for something transient like todos I'm not too worried about it.

</comment><comment><USER15> Sweet, maybe they can afford to address some of the insane bugs they have accreted. I normally defend developers/software when people I know complain about an app - but this is like a year and a half of really bad/frustrating bugs. Disappearing tasks, duplicated tasks, inability to enter tasks at certain times of the day.... And ultimately not responding to emails regarding these issues. If you are going to provide an app which is in essence an augmentation of someones mind you should take the responsibility seriously.

</comment><comment><USER16> Just checked and saw that Astrid is open source. Not sure if it's the latest version though.

<https://github.com/todoroo/astrid>

Now if only someone would adopt it :(

<comment><USER17> Are the iOS client, web client, and web backend also open-source?

</comment></comment><comment><USER18> While we're suggesting todo apps - I've been using Clear [1] (Mac + iPhone only) for the past month and love it. The UI is beautiful yet very simple as everything is done with touch gestures.

[1] <http://www.realmacsoftware.com/clear/>

</comment><comment><USER19> I run a time management app, and I will develop a Astrid importer if there is enough interest: <http://weekplan.net/import-your-astrid-tasks-into-week- plan/>

</comment><comment><USER20> It seems companies other than people like 37signals and indie game studios don't want to be small and independent? I could be wrong about this analysis, but I find the aquihire trend somewhat depressing.

<comment><USER21> How many companies are acquihired a year? Dozens? Hundreds? Thousands?

Half a million new businesses are started every year in the US (with actual employees, not self-employed working from home).

Most small businesses stay that way.

<comment><USER20> Do you think the numbers are similar in tech?

</comment></comment></comment><comment><USER17> Guess I'm picking a new to-do program, then. Honestly I don't spend as much time with Astrid since I switched to iOS, I really got used to its geofencing capabilities on Android.

Anyone got any suggestions for an iOS/Mac to-do program that can do geofencing for entire lists, instead of single todos like Apple's Reminders?

<comment><USER22> Checkmark does exactly this, and is overall pretty great:

<http://builtbysnowman.com/checkmark/>

<comment><USER17> That looks pretty neat! Sadly it's missing a bigger requirement for me, which is syncing. Thanks, though.

</comment></comment></comment><comment><USER23> The key feature I used Astrid for was the ability to have recurring tasks based on the date of last completion instead of fixed intervals. Does anything else out there do that?

<comment><USER24> "regularly" is free of cost and does that. it has no syncing support with I consider a good thing as it contains very personal data that only concerns myself.

<comment><USER23> That looks really good but I forgot to mention that I am looking for an iOS app.

</comment></comment></comment><comment><USER25> Huge congrats to Jon and Tim! I worked with them in 2011 and it's an amazing team that I'd be honored to work with any day. Yahoo! is lucky to have them.

<comment><USER26> I did AngelPad with them in Winter 2011 and we worked out of the same office building for a year. Awesome guys, great passion, sharp technologists and all around good people. Couldn't have happened to better people.

</comment></comment><comment><USER27> Congratulations Jon Paris and team. Good to see someone you graduated high school with having good luck. Super nice guy and good product.

</comment><comment><USER28> Just goes to show that you shouldn't rely on free apps...oh, wait, nevermind.

</comment><comment><USER29> "Trello trello trello" \- Sung to the tune of Rihanna's Umbrella</comment>


Inconsolata - <AUTHOR> http://www.levien.com/type/myfonts/inconsolata.html <comment><USER2> This is my favorite monospaced font, as its:

1\. Free - it can be used anywhere, on anything, no charge, (which can't be said for proprietary fonts that ship with other OS's)

2\. Looks good on screen and when printed (normally or via fpdf/xetex)

3\. Has 0's and O's that are instantly distinguishably from each other. See also the I, 1 and l characters.

4\. Is valid. You'd be surprised at the number of fonts out there with broken leading, or are in some way corrupt to the point that FontBook throws a fit.

13 point looks particularly good in Terminal.app/gnome terminal or in [g|m]vim.

Highly recommended if you're looking for "your" font.

</comment><comment><USER3> Highly recommended. IMO it beats other good free fonts such as DejaVu Sans Mono, Droid Sans Mono (has problems with zero vs Oh) and Liberation Mono. On Ubuntu is packaged as "ttf-inconsolata".</comment>


My Language Is More Agile Than Yours: A Study of Arc - <AUTHOR> http://docs.google.com/Present?docid=dg93d8cv_68c2xw9jd5&skipauth=true

<comment><USER2>
      >> printIfNotNull(foo.getBar().getName()); // pointless method

      >> in arc ...
      >> ... aif is a macro that expands this code to
      >>
      >>(let it ((foo 'bar) 'name)
      >>  (if it
      >>      (print it)))

Why is a macro not pointless, while a method/function apparently is? I don't think that makes sense personally. Surely a macro is just a function that's been inlined - which may be better, depending on if you're optimizing for speed or size. Anyone explain?

Also, I'm not sure if this was being serious or not:

      >> Priorities in language design
      >> A Language Should ...

If it was serious, it completely depends on what problem you're trying to solve as to what priorities you're going to have.

<comment><USER3> Because aif works with any expression, not just print. Granted, in a functional language like JS, one could say:

        ifNotNull(foo.getBar().getName(), function (it) { print it; });

but "function (it)" and all of the "().{}" are still blub. As PG points out on the arclanguage forums [1], an even simpler way of putting it is:

        (only.print foo!bar!name)

Which, without the Arc-specific syntax sugar, is:

        ((only print) ((foo 'bar) 'name))

So "only" is a modifier that makes a verb (function) happen only if its argument is truthy (think Python decorators).

Note to PG: the dot operator is undocumented, and f.g.h.3 does not at all what I expect - looks like it does (f g h 3), whereas I expected (f (g (h 3))), in the spirit of Python decorators.

1\. <http://arclanguage.org/item?id=9350>

<comment><USER2> In js, if printIt is a function already defined, you don't need the function(it){}

ifNotNull(foo.getBar().getName(), printIt);

Granted, in java passing functions around is more of a pain.

<comment><USER4> Yep, a lot of the features mentioned in the presentation are possible with just first class functions, although the syntax will be messier (but arguably more consistent).

The strength and danger of macros is in allowing you to create new syntax, skipping all the extra blub that made your code conform (consistently) to the original parser. What I'd like to know though is how much humans depend on that blub.

It's one thing to write your own macros and use them consistently, or even for a group of people to come up with macros and use them consistently. But if people work independently, what happens when you read someone else's code and find they've come up with macros to do the same things as yours do, but with different names and different usage conventions?

Wouldn't that be a bit like having every scientist invent their own jargon?

Either humans can learn to translate that kind of thing on the fly, or they can't, and lisp with heavy macro usage will only ever be useful as a solo (or small group) language.

<comment><USER5> _what happens when you read someone else's code and find they've come up with macros to do the same things as yours do, but with different names and different usage conventions? Wouldn't that be a bit like having every scientist invent their own jargon?_

You can replace the word "macros" with "functions" and your point would be the same. Consistency in naming and usage is part of good programming, but the point is orthogonal to macros.

Edit: actually, it's not orthogonal: macros make it easier to be consistent because they let you write less code, so there's less code to contradict itself.

<comment><USER6> macros can introduce new syntax, functions do not.

<comment><USER5> So? If you don't understand what a function does, you read it; if you don't understand what a macro does, you read it. This whole "macros make new syntax so they make code unintelligible" thing is an argument made by the ignorant, for the ignorant.

The vast majority of Lisp macros don't create new syntax anyway. They integrate seamlessly into the s-expression format. That way they blend in nicely with the rest of a program and it's easy to write other macros on top of them. An experienced Lisp programmer would only introduce new syntax when there is a big win in clarity - big enough to justify breaking with the surrounding structure and certainly big enough to make the above objection pointless.

By the way, one of the _real_ problems with Lisp macros is that it can be hard to tell a macro call apart from a function call. (Various techniques have been developed to deal with this, such as indentation and naming conventions.) If macros were so syntactically convoluting this would hardly be an issue.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I think it's impossible to have any kind of meaningful conversation about language design when one side is just writing off everything they don't like as "blub". It's incredibly condescending, no better than people reflexively writing off Lisp users as "lisp weenies".

<comment><USER8> The "blub" argument fairly applies just as much to Lisp as it does to, e.g., Java. For example, (any dialect of) Lisp is my blub language, as I understand Lisp quite well. I do not understand Haskell to anywhere near the same extent. I've tried to learn it several times, but monad transformers consistently make my eyes glaze over. I am perfectly comfortable admitting this, and I intend to try harder to understand programming language concepts with which I am unfamiliar, rather than write off Haskell advocates as condescending.

<comment><USER7> I get what you're saying, but I think dropping the "blub" term would make everybody better off. Using "blub" intrinsically frames the conversation in terms of one language being "the stupid one used by the stupid people", and that's likely to be counterproductive. The word _always_ has that baggage.

It's not a linear continuum, with some "most powerful language" at the top. Different styles of languages have different strong points and weak points.

</comment></comment></comment><comment><USER9> The point about string concatenation is, umm, I don't want to say "wrong" because wrong sounds argumentative so I think I'll pick a circumlocution like "contrary to fact" or "a bedtime story to scare CS101 students with, second only to 'use left shift instead of dividing by two, it is faster'".

Also in modern Java (and Ruby) projects you can typically write:

logger.debug("This is a stupidly expensive calculation: " + stupidlyExpensiveCalculation())

and it will get executed regardless and logged only if your logging settings, which are configured elsewhere and can be toggled with a mouseclick, are set to log the debug level.

Now, don't get me wrong, Arc's solution of defining a macro which checks to see whether your debug setting, which is defined elsewhere and can be toggled with a mouseclick, is on or not is a good idea. Its just not a revolutionary new idea for us wizened Big Freaking Enterprise App Ugly Language Programmers. Nor was it really that new in the halycon days of yore when Log4j crawled out of the primordial ooze.

<comment><USER10> We get this for free in Haskell.

<comment><USER4> Not exactly free ... laziness and the resulting thunks do use up extra processing time and memory. But in many cases it is a price worth paying.

<http://www.cs.chalmers.se/~rjmh/Papers/whyfp.html>

</comment></comment></comment><comment><USER11> If it takes X characters to achieve something in language A, and X*4 to achieve the same thing in BLUB, I don't think this means BLUB is 4 times slower to develop in than A.

When I develop software, most of the big delays, and excuses for procrastination are in forcing my brain into action over the higher level concepts. I find a lot of the extra lines of code required when using BLUB can be written at high speed, with little "hurt" to the brain.

I'm not saying BLUB is just as fast to develop with, I'm just saying the benefit isn't as good as number of lines ratio good.

<comment><USER12> It's not in writing 40 lines that something like "blub" hurts, it's in reading it afterward. As long as you don't end up in Perl one liners, shorter code will tend to better highlight the relevant content (e.g., there are four keys that perform one of four things).

</comment></comment><comment><USER13> I like this PG quote from slide 24 a lot:

       "One way to design a language is to just write down the program you'd
        like to be able to write, regardless of whether there is a compiler that
        can translate it or hardware that can run it."

Test driven really works, even for language development.

</comment><comment><USER3> I like the argument, especially using the word "blub" to describe the cruft that is inherent to the language, but I have to question how much it's preaching to the choir, and how much will penetrate people who don't already agree.

Maybe it's indicative of my crowd and not the community at large, but even the smartest people seem to hit up Haskell-for-fun and Python-in-practice over Arc. It's hard to call them blub-programmers, since they're genuinely curious, hard-working people...

<comment><USER4> Haskell isn't exactly blub; between the first class functions and the custom monads it's quite possible to create custom languages. E.g. the parsing library Parsec:

<http://book.realworldhaskell.org/read/using-parsec.html>

</comment></comment><comment><USER14> Anything Arc does better than Clojure that would be enough to offset the benefit of running on the JVM and full java interop?

<comment><USER15> A Clojure slogan could be "The Java De-Blubber!"

<comment><USER16> I believe it's called flensing.

<comment><USER14> I learned a new word today.

</comment></comment></comment></comment><comment><USER17> Code generation isn't as powerful as late binding. Lisps would be more interesting if you could easily manipulate environments, and set the environment that functions are evaluated in. In this regard, Arc isn't as agile as some OO languages (Io for instance).

<comment><USER18> Does this mean that you can change the meanings of your language's "words" for specific "contexts?" (Context meaning the semantic thing, not a stack frame, though that could be the implementation.)

<comment><USER17> Yes. The meaning of symbols within a closure can't change after creation. They are always bound to the same variable.

In Io, the meanings of symbols are determined when the block is activated.

<comment><USER18> I'll have to take a look at Io. I was just thinking of making contexts into semantic contexts by having users specify what the verbs mean, not just the nouns.

<comment><USER17> Io has no "nouns" or keywords. Everything in Io is a verb (a message send). Also, see <http://news.ycombinator.com/item?id=630906>

<comment><USER18> A "getter" is just a synonym for something that's a noun.

</comment></comment></comment></comment></comment></comment><comment><USER19> Is this similar for all the dialects of Lisp? Because if it is, I might start learning one tonight.

<comment><USER20> The macro definition abilities is mostly similar for most popular lisps around, Common Lisp, Scheme, Clojure

</comment></comment><comment><USER21> A lot of the stuff presented here is mainstream practice in Tcl (e.g., new constructs, dbg evaluation). Tcl is seriously underappreciated language.

In my programming whenever I see myself writing blubber (I like that word), I just factor it out into a separate procedure and give it a descriptive name.

So when I'm reading the code of the calling routine, I rarely see blubber; it's contained in simple routines that are easy to read/verify.

Most of the examples here amount to thoughtful library development. With a good library, C++ and macro processor can also many of these things.

Here's a version of aif that works for most cases (I'm not claiming that C has the expressive power of Lisp):

        #define aif(expr, val, code...) \
          { if ((expr) != (val)) { \
              code ; \
            } \
          }

IMHO, this is good enough for blubber reduction.

<comment><USER22> That's not aif at all. In fact, you can't even do it for "most cases" in C because you don't know what type expr will evaluate to, but if we could cheat and assume it will be an int:

      #define aif(expr, code)  \
         {                     \
         int it = (expr);      \
         if (it)               \
            {                  \
            code;              \
            }                  \
         }

But this is still not close because in a Lisp, if is an expression that returns a value. We can't use the ternary operator because then there's no place to declare the "it" variable. You can't have an expression that declares a variable local to that expression in C no matter how hard you try.

And the above lacks the "do {} while (0)" weirdness needed to make a cpp macro behave syntactically roughly like a function.

<comment><USER21> I agree. My bad. I appreciate the clarificaiton.

</comment></comment></comment><comment><USER23> From the slides, it looks like Arc dumps lots of short words in to one giant global namespace where they can easily collide with local names. Is this correct?

For example, it looks like Arc uses the "t" as a global true value. Is it really safe to assume "t" wouldn't be accidentally used as a local variable?

<comment><USER24> Well, T has been the true value in Common Lisp, at least, and I don't remember it ever causing me a problem. Of course, in CL, you can shadow it in your own namespace, and that hasn't been possible in Arc without writing a namespace library first. :)

</comment></comment><comment><USER25> Some other points of view here: [http://www.reddit.com/r/programming/comments/8nuhn/my_langua...](http://www.reddit.com/r/programming/comments/8nuhn/my_language_is_smaller_than_yours_arc/)

</comment><comment><USER26> This presentation could have been about Clojure instead. Just s/Arc/Clojure/

</comment><comment><USER27> Can't do much without batteries.

</comment><comment><USER28> Original blub code should look like that: frame.addKeyListener(new KeyListener() { public void keyTyped(KeyEvent event) { switch (event.getKeyChar()) { case 'j': drop(); break; case 'h': move(-1); break; case 'k': move(1); break; case 'u': rotate(); break; } }

          public void keyPressed(KeyEvent event) {
          }

          public void keyReleased(KeyEvent event) {
          }
        });

About Arc code:

        (on-key-press frame
          'u     (rotate-shape)
          'j     (drop-shape)
          'h     (move-shape -1)
          'k     (move-shape 1))

Is this code ADDS NEW key event handler OR OVERRIDES old one? When it is invoked - when key is PRESSED or when key is TYPED?

<comment><USER27> ah, events as function calls. How so terribly 50's.

here's a way where events are objects... rather than an invocation. Much more flexible.

a python + pygame example...

cu,

key_handlers= dict(u=rotate, j=drop, h=lambda : move(-1), k=lambda : move(-1))

buttons = {1:'u', 2:'j', 3:'h', 4:'k'}

for e in pygame.event.get(): if e.type == KEYDOWN: key_handlers[e.key]()

        elif e.type == JOYBUTTONDOWN:
            key_handlers[buttons[e.button]]()

        elif e.type in [QUIT, MOUSEBUTTONDOWN, HTTPD]:
            quit()

<comment><USER18> The grandparent code is much easier to understand.

<comment><USER27> The claim is Arc is agile and short... The Arc one has too many ()() all over the place.

The arc one is also less powerful, because it uses different function invocations for different types of events.

It's also likely more people will understand the python+pygame version. More people do currently understand the python version... hardly anyone uses Arc.

You need to understand non-common concepts. You also need to understand how to create functions - rather than just call functions.

Does that Arc one mean when the key down happens, or when a key up happens? Or maybe it means in between the key press and key down. Also, when will that code be called?

It's magic. Will it be called from a separate thread, or some other Magic time... before or after the screen is to be updated? What else is going on at that time in the program? With the Arc version you have no idea... it's not explicit.

Also Arc doesn't have first class events. It could have yes, but it doesn't.

ps. the python code above was mangled by the buggy Arc program running this forum.

Here is the code redone for simplicity without the extra shortness and power expressed in the other version.

.

for e in pygame.event.get():

        if e.type == KEYDOWN:
            if e.unicode == 'u':
                shape.rotate()
            elif e.unicode == 'j':
                shape.drop()
            elif e.unicode == 'h':
                shape.move(-1)
            elif e.unicode == 'k':
                shape.move(1)

Or the declarative python version:

.

dict( u=rotate , j=drop , h=lambda:move(-1) , k=lambda:move(-1))

<comment><USER18> _The arc one is also less powerful, because it uses different function invocations for different types of events._

Actually, that would make it more powerful. You can use polymorphism.

 _It's also likely more people will understand the python+pygame version. More people do currently understand the python version... hardly anyone uses Arc._

Missing the point. Conciseness is not best measured by eyes familiar with the language/library. It's best evaluated from the POV of the uninitiated. I have to parse and run a model to understand your first version. Your second version is as easily understandable as the Arc example in one way, but it's got a lot more pollution and an enforced higher line count.

I am answering as someone not well versed in either Python or Arc. (Actually a little more familiar with Python.)</comment></comment></comment></comment></comment>


Why Lisp Failed. (2009) - <AUTHOR> http://locklessinc.com/articles/why_lisp_failed/ <comment><USER2> This article relies on apocryphal data at best, and seems largely to have been formed by the author's vague impressions.

It's a waste of time to read, and not worth refuting in detail.

<comment><AUTHOR> Disagree. It's still a succint article and right to the point. Plus, the comments below it prove it mattered to people.</comment></comment>


Why Are the Rich So Interested in Public-School Reform? - <AUTHOR> http://ideas.time.com/2011/12/09/why-are-the-rich-so-interested-in-public-school-reform/#ixzz1gMN4dMsd

<comment><USER2> I think Vladimir Lenin said it best:

 _Give me four years to teach the children and the seed I have sown will never be uprooted._

<comment><USER3> Yeah, the Jesuits said something like that, too. Their distinguished pupils included Voltaire and the Castro brothers. One begins to suspect that pedagogues overrate their influence.</comment></comment>


Oracle Must Pay Google $1,130,350 in Costs - <AUTHOR> http://www.groklaw.net/article.php?story=20120904211545683

<comment><USER2> What I take away from this is that a serious court case costs millions of dollars. Which means is that the current patent system erects a massive moat around the entrenched players with large patent portfolios and the cash to put lawyers to work 24/7/365.

From time to time, some small troll wins a few hundred million from Microsoft or whatever, but the real story here is that if you don't have ten million dollars to buy into the game, you can't play. It's almost as if the odd "win" by a bit player is a PR stunt to convince congress that the current system is an incentive for entrepreneurs and dreamers to invent new things.

But it's all bullshit. It's a rigged game.

<comment><USER3> I really like the suggestion of malandrew yesterday on HN:

 _This is one of the main reasons I think that all money spent on lawyers should go into an account that both sides get to draw upon equally to pay legal expenses. You simply cannot have a system capable of meting out justice if money can skew "justice" in your favor._

The two questions which immediately come to mind:

1\. How to bell the cat (how does one actually get this enacted)?

2\. What could possibly go wrong?

<http://news.ycombinator.com/item?id=4475702>

<comment><USER4> > 2\. What could possibly go wrong?

Easy to imagine how this could be abused. Imagine that I have a brother who's a lawyer. I bring a frivolous lawsuit against Google/Apple/Microsoft/etc. knowing that they'll dump a fair amount of money into the account. My brother bills me for legal services, taking roughly half the money from the account. I lose the lawsuit but my brother and I split the money.

<comment><USER3> Courts have been relatively wary of dismissing frivolous suits (at least according to some reports) in recent decades (perhaps in response to an overinclination to do so in the past, further disadvantaging disenfranchised groups). A bit of strengthening of frivolous suit protections, and a waiver of the shared fees in this case, might help.

I'll give you another: there are situations in which pro-bono services may be provided to one party in a suit. Often to increase the equity of a situation, but not in all cases. Should the pro-bono provider be on the hook for the opposing parties reciprocal costs, and how should the PB provider's services be valued?

The SCO v. IBM suit is another in which I could see IBM's legal costs (very high, I'm sure, though I've seen no figures or estimates given) but in which SCO being granted pooled fees would be a miscarriage of justice.

Why is being good so difficult?

</comment></comment></comment></comment><comment><USER5> I guess we'll never know for sure if Steve Jobs egged on his buddy Larry Ellison to throw this sucker punch at Android but given his apoplectic reaction to Android it sure seems likely.

<comment><USER6> I don't believe that's how these things work.

Power player A meets power player B, they discuss what they hope to do in the near future - plans and interests. Perhaps they will have matters of mutual interest - thats great.

Then they seperately take action, happy to know what positions and interests the other players in the game have.

Apple and Oracle were both threatened by Android. No-one needed egging on, no- one needed secret deals. They were open and above board about wanting to screw over Larry and Sergey. :-)

<comment><USER7> I never understood why Android's Dalek would be threatening to Oracle.

</comment></comment></comment><comment><USER8> Also, I'd like to try and point this out again: <http://www.scribd.com/doc/103158031/Google-Shill-List>

I don't think an article mentioning the google bloggers ever reached >10 points, at least by my googling.

<comment><USER9> Here is Oracle's corresponding disclosure: [http://www.scribd.com/doc/103156565/12-08-17-Oracle- Disclosu...](http://www.scribd.com/doc/103156565/12-08-17-Oracle-Disclosures)

I appreciate that it probably wasn't yourself who chose to include the term 'shill' in the Google document name, but your referring to 'the Google bloggers' is a bit misleading. To quote from Google's disclosure:

 _"Neither Google nor its counsel has paid an author, journalist, commentator, or blogger to report or comment on any issues in this case. And neither Google nor its counsel have been involved in any quid pro quo in exchange for coverage or articles about the issues in this case."_

Contrast this to Oracle's retaining Florian Mueller as a paid consultant when he was backing their case on his blog.

(Edit: Clarified Oracle/Mueller relationship)

<comment><USER10> Do you have any evidence that Oracle payed Florian Mueller to promote their case?

<comment><USER11> Google's list is basically "here's a bunch of organizations which we're a member of or make contributions to." Some of the people within those organizations made comments about the case.

Mueller was directly hired and paid by Oracle. Whether or not he was specifically hired to comment on the case or not, that's quite a different kettle of fish to simply belonging to the same organization that Oracle may have contributed to.

Besides, it's not clear what "consulting" he has done for Oracle, but his expertise _is_ patent law...

<comment><USER12> Let's be ultra clear here: Florian has no expertise in anything legal related. He has no law degree, no formal legal training, etc.

His expertise is in _lobbying_.

<comment><USER10> I'm curious why you think it takes a law degree or formal legal training to develop expertise in patent law.

</comment></comment></comment></comment></comment></comment><comment><USER13> If only compensation to Google for Oracle's frivolous litigation were substantial instead of negligible.

</comment><comment><USER14> Just to put this in perspective, Oracle has just over $30B in liquidity.

$1M / $30B = 0.0000333

That's the equivalent of having $300 in your pocket and someone demanding 1 penny.

<comment><USER15> True, but a judge awarding damages to your counterparty hurts, even if the amount of money is insignificant.

</comment></comment><comment><USER16> _Google had asked for $4,030,669, but the judge cut it back, denying the part that was for the work done by the ediscovery vendor. Truthfully, I've never seen a bill of costs that was not cut back, but the bottom line is, Oracle has to pay for bringing this stupid lawsuit about APIs._

</comment><comment><USER17> It seems very little. I'm sure Google paid many more millions of dollars to their lawyers in this lawsuit.

<comment><USER6> That's not what matters. Getting costs is like a TKO in boxing.

They won, the judge knows they won, but they still had to do the road running and the no sex for a month before the match, so its a sunk cost. Lots of sex _after_ the match does not make up for the month before.

<comment><USER18> Too many metaphors. I really don't understand what you're saying.

<comment><USER6> Getting costs in most civil cases is no longer about making financial restitution - the litigants are usually so well funded it does not matter

cost awards indicate not only did the jury agree with you, but your case was so strong the other side should be punished for bringing it. Compare to cads where costs of a dollar are awarded.

As for sex, forswearing sex before a sporting match is / was a common means of getting teams away from disruptive or chaotic marriages by wiley coaches, and could be seen as a sunk cost in winning the match. Even if you were awarded restitution after the match the costs were sunk so it does not matter if costs are awarded or not (see the too well funded to care above)

</comment></comment></comment></comment><comment><USER19> Pocket change.</comment>


Ask HN: Big company looking to acquire us, I'm terrified - <AUTHOR>

First, sorry for the anonymous account. NDA etc..
We're a small, boot-strapped (though fairly established) company. The major company that rules our industry is looking at acquiring or investing. We're really naive at these business aspects, we're engineers..
How much do you disclose on the early talks? We have a document prepared with vague but accurate graphs showing our growth, various comments about how awesome we are and our plans for product development.
I'm afraid of looking too keen for a sale, where I know we'd give up control but it would allow us other benefits of major growth. I feel completely lost here, I've read everything I can on HN but it's hard not knowing what to expect. Is it always this terrifying?
I'd love to hear any stories and advice, thanks for any input. <comment><USER2> Couple of quick points, though this is a very subjective topic so these might or might not apply.

1\. Know that 99% of deals fall through. This one will also, except when it won't. More importantly, the deal is only done when the cash hits the bank. Deals are known to fall through even at very late stage. Falling through is the norm, going through is the exception.

2\. Be open about numbers, growth etc. Be closed(vague) about strategy, execution plan etc. You need to be open about the numbers to give them confidence. You need to be closed about strategy, execution plan because a huge number of deals fall through because the acquirer decides to build the same stuff inhouse (typically prodded on by internal engineering teams)

3\. Build confidence. Talk about how this marriage will be best for both the teams. Reserve the negotiations around cash towards the end of the deal. When you start negotiating about cash, the deal is already done.(Except when it isn't - see point 1). Negotiating the deal is though topic for another post.

4\. Decision making in big companies is slow and hard. The decision to acquire your startup will need to be driven by someone internally in that company. Find out who your 'champion' is in that company. Maintain regular contact with him, though dont push him too much. If some time elapses without any communication, ping him and check with him.

5\. Most deals that go through will go through quickly. The decision in most of the deals which go through is already made. You just need to nod your way along in such cases. In other cases there will be just one big issue that you need to build confidence upon. If the talks get extended, it is likely that the deal will not go through.

6\. The Zen Rule for Deals: Assume that the deal will NOT go through and plan your startup accordingly. The person who is willing to walk away is the stronger person in any deal. Detachment will allow you to negotiate from a position of strength.

<comment><AUTHOR> This is extremely good information, thank you. We have been careful in how to describe to them what our long terms goals are without being specific what technology we have up our sleeves. It's been great reading HN for so long, I feel like I have the basics down - be calm, expect nothing, carry on as usual. But cross fingers.

>Negotiating the deal is though topic for another post.

I would like to read this post :)

<comment><USER2> Thanks for your kind comments.

Im not sure if I would be able to post about negotiations any time soon. Drop me a line when you enter negotiations and if you want an outside perspective. I will be happy to help. You can reach me through the feedback form of the site in my profile.

</comment></comment></comment><comment><USER3> Talk to the founders of companies in your sector who've been acquired recently. Find out who represented them. Then hire that firm. Selling a company is like going to court. You can do it yourself, but when the other side has trained professionals working for them, it makes sense to have the same level of expertise on your side.

<comment><AUTHOR> Thanks, this is great advice. We know we'll need a lawyer very soon and I like the idea of working with someone with a history of working with other small tech businesses. It's a comforting thought!

</comment></comment><comment><USER4> Whatever you do, be willing to walk away from the deal if you don't feel comfortable with the terms. That changes you from negotiating from a weak position to negotiating from a strong position all by itself.

Remind yourself of this: The really bad deals are the ones that you do and regret, those are far worse than the ones that you don't and regret.

Do not negotiate in person during the final phase, get an experienced M&A lawyer to be your front during the negotiations, if you can't afford that then get someone you know that is very well off and has done these kind of negotiations in the past. You are very strongly emotionally tied to the deal and likely to be read like a book by the party on the other side of the table. If you are not an experienced poker player, don't sit down at the table.

Don't decide things 'on the spot' or under pressure, always think them over.

Much good luck! I hope it works out for you and that you will get out of it what you want, beware of stock deals, lock-ins, non-competes, performance clauses and a hundred other things that might come your way, see 'experienced M&A lawyer' above. Oh, and pay your own laywer!!! Never rely on legal advice by the other party.

<comment><USER5> Very good point on the final negotiations. While my father isn't a lawyer (although he did do some law in the Navy), he has earned quite a bit of well deserved money in that negotiating role for the sorts of reasons you've outlined, as well as just taking on a lot of the burden, allowing the owner(s) more time to keep their business going.

</comment></comment><comment><USER6> Lawyer, lawyer, lawyer.

The way you negotiate and approach any deal is going to vary drastically based upon your current situation. As you're not in a position to give away confidential information on HN, you need to speak to someone to whom such information _can_ be given.

I don't know where you are located, but I am under the impression that pretty much every investing hub has lawyers with a focus on startups. I am confident that they will know the ins and outs of acquisitions, and will be able to provide you with advice as to best navigate the deal.

</comment><comment><USER7> Watch this great talk by entrepreneur Hadi Partovi on this very subject: [http://www.seattle20.com/tv/clip/StartupDay-2010-Exit- Strate...](http://www.seattle20.com/tv/clip/StartupDay-2010-Exit-Strategies- for-Startups-by-Hadi-Partovi.aspx)

<comment><AUTHOR> Probably the most sobering, necessary talk I needed right now. Thanks!

</comment></comment><comment><USER8> Here are already a lot of tips about the local/tactical situation dealing with maybe beeing acquired. But what if it falls through (like it happens way too often)? Was it just this? Can we use this situation to get an advantage, if we get a deal or not?

There is where strategy comes in! Yes, you always have to look for alternatives to use this situation for your company.

For that you need to find out WHY they want to acquire you. For example: Google wants to acquire you, because they want to be in your market ([http://bits.blogs.nytimes.com/2010/12/07/google-executive- no...](http://bits.blogs.nytimes.com/2010/12/07/google-executive-no-time-to- build-so-we-buy/?ref=technology), can't find the HN thread for this), then you can ask googles opponents, like facebook, yahoo, microsoft, if they are interested in a deal. That will increase the money you get from anyone and also your chance of beeing acquired.

Because I have no own experience in this matter I will not lead you in the wrong direction by giving you further tips. Maybe other people here can help to give a more strategic view of the situation. How else can an aquisition attempt be leveraged?

Other resources: <http://venturehacks.com/archives#closing> <http://venturehacks.com/articles/diligence> <http://venturehacks.com/archives> <\- Actually just reading most of it is healthy itself for a startup who knows nothing about money things.

</comment><comment><USER9> You don't seem to indicate what I would figure to be a major concern for you right now: Do you or do you not _want_ to sell?

I think you should come to this conclusion within your team before doing anything else. Considering you personally sound pretty conflicted, you're going to have a tough time "winning" this challenge if each one of you has different ideas of the ideal outcome.

Once you understand that - that is, the ideal outcome - work towards that. Don't get sidelined by big companies and big money. As bluethunder says 99.9% of all deals never happen, so they aren't worth putting more than .1% of your daily effort into (figuratively speaking here, of course).

I'd say this as well: Do not for a second believe that being acquired is some sort of growth mechanism for your dreams. It is by definition the exact opposite; the death of your company. No matter what, the company you have, its plans, culture, desires and particulars will cease to exist. This will happen despite everyone's promises and best intentions.

What will exist may or may not be something you can live with, but it won't be the thing you are living right now.

</comment><comment><USER10> I've been in this situation before. I did it all myself - it worked out OK. In hindsight, though, I'd advise a lawyer if you can possibly afford one as it could have gone horribly wrong ;-) (Others here have given better advice on that part.)

If you decide to go it alone anyway, you must first get a good feel for their true intent. It's like dating. Don't give it all up or get heavy on the first date. Keep things cordial and don't act secretive or defensive, but spend time talking to them and feel out what they're gunning for. You'll need some time after to reflect on things they said or impressions you got from their manner. The more people on your side who share in the talks, the better.

Like someone can detect a shady date even if they don't overtly do anything nasty, you should be able to sniff out bad intentions from the buyer. If they're just digging for information or yanking your chain, unless they're _really_ smooth manipulators, you should get a bad feeling in your gut after the first or second serious talk.

</comment><comment><USER11> I struggled with this too. Just be honest--don't hide anything and don't pretend to be something you're not. If you sell they'll find out anyway.

Negotiating is all about the ability to walk away. Focus on your product. If a sale doesn't happen you shouldn't be crushed. Just continue growing as you planned.

<comment><USER12> +1. On more than one occasion I've seen startups flounder around during acquisition negotitions without actually pushing forward. 6 months later they're in trouble. I've even seen big companies use these negotiations as a stalling tactic.

Don't let it happen. Keep your foot on the gas, and make them put-up or shut- up. Get a letter of intent straight away. Due diligence isn't an excuse to stall. Negotiate a schedule and stick to it. If they can't meet their end (without obvious good reasons) forget it and move on.

</comment></comment><comment><USER13> The biggest problem with getting lawyers involved early-on is that it's their purview to protect your interests above all else, including an equitable, workable deal.

It has been my experience that using lawyers too early will put ridiculous clauses in contracts that don't necessarily make good commercial sense or are even in the spirit of whatever negotiations you are trying to make.

Additionally, lawyers are expensive, especially early on.

My advice: sit down, talk with the other side, decide what you both want to get out of the deal, write a heads of agreement whilst reserving your rights (they aren't binding after all) so you both have documentation to ensure you are all on the same page then, and only then, get the lawyers involved to draft up an sale document based on your heads of agreement.

Lawyers are lawyers, not negotiators or entrepreneurs. Ultimately, they aren't the best people to represent you when it comes to working out what you are willing to accept to part with your baby.

<comment><USER14> +1 for the key message here. Lawyers aren't negotiators, and you have to remember _all the time_ that they work for you in this negotiation, not the other way around. They will give you lots of advice, and you should think of it as such, and ask questions about the real risk you might be taking, and make decisions accordingly.

I've watched friends have sales fall through because they didn't trust their own judgment when faced with their lawyer's thoughts. Apply the same confidence you have (or fake) for building your product to the redlines from your lawyers.

<comment><USER15> One that thing that can also cause problems is that in many situations the companies lawyers are acting for the company not the individual interests of the founders - if you have investors or a situation where the founders have different equity stakes then it can get messy as a particular deal may favor some people and not others.

I'd also recommend doing a _lot_ research into the acquiring company - particularly if you are being paid in stack rather than cash. I know from bitter experience what happens when you get acquired by a company that looked healthy during the acquisition process then whose stock plummeted during the lock in period :-|

</comment></comment></comment><comment><USER16> Sometimes when something really big and good starts to happen, even if it's something you've been working hard to achieve, it can be a bit hard to understand. Getting used to the idea that yes, you really did it, might be a good step to helping yourself calm down and gracefully surf this newest big wave coming at you.

You worked for it, now nail it!

</comment><comment><USER17> Hard to give good advice from just the details in your question.

I guess the most important thing to think about is, do you want to be acquired? And if so, what would it take to make you sell? Then, does that number seem at all justifiable from your current trajectory?

<comment><AUTHOR> Yes, we want to be acquired. We're excited to be able to take our skills to where we can compete on an international level - it's not something we feel we have the ability to do by ourselves and we've not met anyone who we thought would be a good fit to come in and do it with us, I think we're too small and you rarely meet people who will drop everything to be part of a 'maybe', when you can't offer massive stock options or salary.

Perhaps it's part of being what we are - loving what we do and being so proud of what we do that we're happy to work hard and see a few customers come in and make us profitable, but being afraid to really build something huge. I don't think I personally have it in me to do that, but I'm up for the idea of working with someone who is. We can only trust in this big company that they believe in what we have, and even if it gets destroyed or forgotten at least we gave it a chance.

</comment></comment><comment><USER18> Get a lawyer. Not someone small that you've been using regularly for the little stuff who's never done this before, but someone that has experience. Be careful about this; there's a lot of dummies that put on a show of competence.

Same thing with a negotiator. Are you in a city that has a lot of startup activity? Reach out to a good COO type who can help you conduct the negotiations. How much they get involved will obviously depend on the amount of money we're talking about. It's just not a good idea to learn about negotiations by doing in circumstances like this.

Be careful who you pick. Money turns heads unfortunately, and a lot of otherwise sensible people become complete pricks.

</comment><comment><USER19> David Cohen of TechStars has written a good post about this -

[http://www.davidgcohen.com/2010/06/18/you-have- acquisition-i...](http://www.davidgcohen.com/2010/06/18/you-have-acquisition- interest-now-what/)

<comment><AUTHOR> Very interesting, thank you.

</comment></comment><comment><USER20> Congrats. I can imagine a hell worse than being acquired!:)

</comment><comment><USER21> I have zero experience with this. But I learned a lot about communicating effectively under pressure while very ill and being jerked around by doctors. If I got all emotional, it was just another excuse to dismiss my very real concerns that I might die if they didn't treat me. I had to keep a very cool head at a time when that was enormously challenging due to pain, fear, how sick I was, etc. I found that doing a few minutes of "meditating" just beforehand -- breathe deeply, clear your mind of prejudices, that sort of thing -- was one of the most effective things I could do.

I would also recommend you pick up a copy of "Getting to Yes" if you aren't familiar with it. It is a quick read and research-based. A meatier book is "The Mind and Heart of the Negotiator". [http://www.amazon.com/Mind-Heart- Negotiator-Leigh-Thompson/d...](http://www.amazon.com/Mind-Heart-Negotiator- Leigh-Thompson/dp/0131407384) But it might be a bit late for that. (EDIT: Both were required texts in a class I had on "Negotiation and Conflict Management".)

Good luck.</comment>


Why corporate IT should let us browse any way we want. - <AUTHOR> http://www.slate.com/id/2226279/pagenum/all/#p2

<comment><USER2> This has already been covered: <http://news.ycombinator.com/item?id=788409>

</comment><comment><USER3> Because if they restrict browsing fewer people might read slate?</comment>


The Dark Art of Bots: How to Make $2 Million Online Without a Human Audience - <AUTHOR> http://www.theatlantic.com/technology/archive/2013/11/the-dark-art-of-bots-how-to-make-2-million-online-without-a-human-audience/281425/

<comment><AUTHOR> I think the medium-term effect of this trend will likely be advertisers buying more space with services like Facebook, where you get a better guarantee that you impression was an actual person with a real profile.</comment>


Ask HN: Cons of Being on a Remote/Distributed Team? - <AUTHOR> I know there are plenty of benefits of working remote such as flexibility. I would love to know about some of the issues you face and how you/your company works to address them. <comment><USER3> \- 1:1 relationships between teammates are harder to build remotely. I've seen that countered with recurring pairing and online coffee/tea hangouts, and making time for 1:1 meetings whenever the team is together.

\- communication issues escalate. The lack of small daily positive interactions make any friction-ful interactions more intense. Direct communication is my only strategy for fixing this. For example, "Hey, I don't like it when you post a ton of comments before I ask for review. I like to put up PRs before I'm 100% done so that people can see what I'm working on, but they're very much works-in-progress." rather than just stewing and being resentful of someone pointing out something I already knew and just hadn't gotten to yet.

\- timezones suuuuuck. A couple hours is manageable, but working with an east coast / west coast / india team was a real problem. We have team quiet hours until noon ET / 9PT a couple days a week, so even though I'm 3 hours behind I don't feel behind when I show up for work.

\- Everyone needs to be a strong and profuse written communicator. If folks aren't in the habit of proactively providing lots of context, people will get left behind and lose context for why decisions were made, and the product suffers. We're used to reading facial expressions and body language to actively gauge understanding in conversation, and it's harder to get that remotely.

<comment><USER4> I completely agree with this. I have been working remotely for different companies for about a decade.

A couple of years back, I had a year-long contract on a remote team and the team leader was a horrible communicator.

It got to the point where I had to almost beg him for information. He would leave things out (not sure if it was intentional) and then make snide, passive-aggressive comments.

The rest of the team (2 people) were also fairly passive and it was extremely difficult to feel any kind of team cohesion.

Daily standups were painful.

I finally gave up and quit.

Managers as well as non-managers need to be excellent communicators for a remote team to work.

</comment></comment><comment><USER5> I think one of the biggest cons is the disappearance of "watercooler" brainstorming. This is more apparent if you're in a creative field like software development. Those casual conversations/brainstormings that you have in an office help you come up with creative ideas and solutions. This is pretty non-existent when working remote.

Of course, there are many pros to remote teams; so it's all about tradeoffs.

<comment><USER6> Gaming helps, although there is a risk of spending time after work with work people that way

</comment></comment><comment><USER7> Loneliness. Working in solitude, with the only communication being written, short snippets of text or an occasional video conference.

It feels liberating at first, but absolutely suffocating if you're not deliberate to get out of the house. And at least personally, an occasional social Slack chat or video conference ends up feeling forced and contrived. It's just not enough - you have to be deliberate in seeing the people you love.

<comment><USER8> This. This. This.

Chances are you need more water cooler social interaction than you could have ever imagined.

I went into remote work thinking I was leaving all that behind - <USER2> riddance!

Turns out it was a very important part of a healthy psyche. Casual conversation, social queues, all that stuff needs to be exercised on a semi- regular basis. It's all too easy to work an entire week and have only made basic trips out of the house to places like grocery stores or a gas station.

Compound that over years, and you'll do a serious number on your mental health. Work environments provide a social outlet that is often taken for granted.

</comment></comment><comment><USER9> My experience so far (small team, one company, partly on-site and partly remote, n=1 and all that) has been that minor communication problems and misunderstandings have a greater tendency to fester and develop into friction between individuals. We all hate being interrupted by someone "dropping by" when we're cranking, but the ability to do that seems to help people get along more easily.

There may also be more of a tendency to sort of... drift off, or lose interest, allowing personal life to creep into work hours.

This seems to be exacerbated if management doesn't really know how to handle fully remote teams. The past chatter on HN seems to suggest that managing remote teams is a distinct skill from more traditional management.

So far my preference is a nice office environment with a part-time remote option > full-time remote > crappy (unproductive or uncomfortable) office environment.

</comment><comment><USER10> Changes to management: today's management and team structure may be friendly towards remote engineers and/or a distributed team, but changes to management or caused by team growth may create a situation where being remote is harder. I've been there: a fully remote team started hiring everybody from the same 2 different cities, then split in two teams where the majority of people on each team was local plus they had a few old-timers being remote.

Processes: things work great when all the process are remote-first. When you have processes that are local-first but have exceptions for remotes, things get worse. For example: one of our meetings used to be phone-only: everybody would dial in, even if they were in the office, since there was no room reserved for it. It worked great for remotes, since everybody was remote in that situation. As soon as things changed and the team was mostly concentrated in a single office, they started reserving the room for the majority of the people and then dialing through the Cisco thing so remotes could participate. It turns our a lot of the communication started using non-verbal channels such as gestures, faces, sometimes people would talk too quiet for the microphone to pickup, so the whole experience for the remotes was very downgraded, to the point they started being second class citizens in the meeting. And from that, things escalate very quickly to 'remotes are second-class employees'.

</comment><comment><USER11> You need to be really chatty on IM channels. I work a lot with distributed teams and got in the habit of basically just bantering on Slack. Like, not just waiting for work topic, but talk about Game of Thrones or how I'm feeling. The kind of things you'd chat about if you were in person. It helps humanize each other and keep conversation flowing.

<comment><USER12> I have to disagree with this. Nothing distracts and annoys me more than watching the bouncing Skype typing indicator and thinking my coworker is deep diving into an important topic and after three minutes of typing all I get is "yeet!"

<comment><USER13> Skype IM does not scale at all. Slack can also be a problem with bad culture or the wrong channel breakdown and etiquette, but it at least offers viable tools/notification controls to tune it so you can have both social interaction as well as heads-down focused time.

</comment></comment></comment><comment><USER14> Communication issues. Therefore we get together 1-2 times a year. It helps to see the other person for real for your online presence. Communication otherwise via Slack, Zoom, Jira, Email, Hangouts

</comment><comment><USER15> I manage a team split evenly between California and Eastern Europe.

In an agile environment with many changes in-flight each sprint, or doing daily hand-offs (for a follow-the-sun support model), the communication overhead becomes significant. It's tough to keep up with what N other coworkers are doing every day, plus do your own work.

In my group I've seen some pretty bad resentments build because of the perception that people were left out of the loop. Or, because someone didn't _over_ communicate his changes and broke something downstream.

Coupled with the fact that there's a 12+ hour turnaround time on even simple communications between the sites, people can feel pretty frustrated.

We use a Slack channel for daily standup updates and changelog; that helps if people are disciplined about it.

The worst thing though is "othering" \-- it's human nature to point fingers at the group across the hall, in the next building, and definitely across the ocean. If you have immature or problematic personalities on the team (don't we all), rifts will occur and deepen without regular face-to-face contact.

</comment><comment><USER16> I work in the NYC satellite office for a Silicon-Valley company, and for the most part it's fine, but there are a few things that I'm still getting used to.

First off, I am historically very bad at reading and checking emails. For companies that are mostly local, this wasn't a huge deal, since people could just come and bother me whenever they needed me, but it's a problem when I'm basically remote. Honestly, the way I've gotten around this is setting a recurring reminder on my calendar to check my email, so that I don't forget.

Also, due to the three-hour time difference, I end up having to dial into a lot of meetings from home during dinner-time. This isn't the worst thing in the world, but it can be annoying.

It's worth it overall, I personally like NY better than California, and that same three hour time difference allows me to show up to work late without anyone really caring, which is really useful if I have to go to the post office or the bank.

</comment><comment><USER17> I work in an org (not typical dev work) that has staff in several offices around my country. Almost all of my projects are run with team members or stakeholders in different cities (and I actually think it works surprisingly well).

However, downsides include:

messenger clients/email are just inherently inefficient. Absolutely necessary, but inefficient. Being there in person will always be better for work that requires in depth discussion. The psychological conditioning of always staying alert for the next message (whether that be chat room, message, phone) is not conducive to sustain concentration and intellectual work. I try to keep to a pattern of two checks through the day, but this is not universally accepted through the workforce. Always on is not healthy.

Time differences ug.

Public holiday and cultural differences.

I am no fan of micromanagement, but it can be hard to on-board new staff and team members. Sometimes junior staff do need supervision and handling, and that can be tough remotely.

And while it's nice to live in fantasy world where everyone gets along, conflict is also harder remotely. When people "go rogue" that's tough.

Also, if people are going off on the wrong track or there is a miscommunication, it's easier for it to stay hidden for longer.

Lastly, its easier for changes and decisions to happen without your input when you're remote. Unless you're just working on a small team which naturally gets along and everyone agrees (and then you risk groupthink), authority structures do exist, and decisions get made where authority lies. Those with proximity to authority have an inherent advantage in getting their way.

How does my org handle it? Well, we have budget/process for travel and a yearly off-site and offices in all key cities in the country. I hate travel for work, so that expenditure is safe on my end, but not all orgs/jobs are going to have all that as an option.

Otherwise you just have to be aware of these issues and figure out a culture, tech, and protocols to deal with them.

</comment><comment><USER18> Timezones. Only time we can meet is end-of-day in Europe and early morning in the US. Hard to do fast ping-ponging on pull requests and design choices without me staying up late.

But a big pro is no messages before 3pm,lots of time to focus!

</comment><comment><USER19> You'll probably hear a bunch of legit things in here, but the root cause is _always_ lack of face to face communication. The proxies for this are getting better, but we have a long way to go

</comment><comment><USER20> In the mishmash that comes with acquisitions, I'm a remote manager who manages a team at the corporate office and few others remotely. On top of this, my team is an internal agency which works across multiple business lines, some of which are at satellite offices.

My biggest business gripe is the lower fidelity and higher friction with collaboration (planned and not) with my team and other departments / businesses. There's a loss of energy, creativity, focus, ease, alignment, etc. that just isn't there for me with email, video/phone, chat, etc. My biggest personal gripe is related. I'm more extraverted and the loss of regular social interactions is tough. I miss going out for lunches, breaks, drinks, walks, etc. with people that I think are interesting without having to do much to set it up.

I come in to the corporate office once a month for about a week. It feels like we get more done, have a good amount of fun, and clear things up faster. Even remote, we're still doing much better than the team before us which was full onsite. I guess that's why they keep me around. But I miss the tighter vibe and will probably soon start looking for something near me.

I've always felt that some hybrid approach would work well. Some days, everybody's in (group stuff); some days, everybody's working from home (crank).

</comment><comment><USER8> This question depends heavily on whether the whole company is remote or not.

If it's not a "remote first" company, then you need to be prepared to be left out of a lot of conversations. Your opportunity to grow beyond engineering is extremely limited. You'll likely never be promoted past engineer. IMO this is the biggest issue you have to face as a remote engineer, the rest is in the noise.

If it IS a "remote first" company, then all the other issues presented are worth focussing on.

<comment><USER21> This is the key issue. If a company is built to be remote -- over documentation; excessive communication; no two people are local to each other; a culture around the online communication tools (to replicate the watercooler); and most importantly 3 - 4 overlap of all teams so you know when meetings can be scheduled. Have that, and you can work extremely well.

If you are "distributed" in the sense there is a HQ full of managers, and a bunch of other offices because that's where people could be found with the right skill set, no set overlap hours, and HQ still has the practices on of non-distributed culture (conversations about important topics happen face to face for instance). Well, then, you have to accept you will be out of the loop and work very hard to be remembered and involved.

</comment></comment><comment><USER22> The worst remote experience I've had was when leadership was not bought-in.

A butts-in-seats manager or VPE or whatever can really ruin it. The lack of trust is really toxic.

</comment><comment><USER23> In reading through these responses, I don't see any that correspond exactly to my experiences in four different remote roles. I'm sure the issues mentioned were legitimate issues, but I have not found them to necessarily be problems inherent in remote work. For example, I have not found there to necessarily be communication issues or problems due to lack of face-to-face interaction. Timezones can be hard, but organizations can be structured to accommodate those. I've also not had a problem brainstorming remotely with colleagues on work issues.

The one thing that I have found to be a predictor of success in each of my remote roles was whether the company was all-in on remote work. If you're one of the handful of guys for whom they tolerate remote work, you're likely to experience all the problems mentioned here. It's different if everyone's on board with remote work. And practically speaking, it's pretty unusual for a company to be all-in on remote work if the company is not 100% remote (or at least very nearly so).

For me, at least, there are essentially no cons and significant pros to remote work.

</comment><comment><USER24> If the company is not a remote-first company, it's a huge pain in the ass, because the culture is not aligned. It's like you're locked in the storage closet. You will shout to try to get someone's attention, but they often aren't there. Occasionally someone will check on you. Meetings can be garbled and difficult. You're left out of everything; your coworkers have ad-hoc conversations and decide things without you. Even pair programming is difficult. And of course, your coworkers will feel like this is all _your_ fault.

The difficulty of getting impromptu questions answered (you always have to schedule meeting time, so you may waste 30mins for an 8 minute question) will eventually lead to office hours if you want to be productive. And it's always fun when people decide to take meetings while working from a coffee shop.

On the plus side, no need to put on pants. (Except in the coffee shop...)

</comment><comment><USER25> Related: The Long-Distance Leader: Rules for Remarkable Remote Leadership > [https://www.goodreads.com/book/show/36162566-the-long- distan...](https://www.goodreads.com/book/show/36162566-the-long-distance- leader)

</comment><comment><USER26> Can't speak for myself but my brother did a stint at a media company working remotely on a distributed team doing backend work in JS. He started at their office in NYC (natives) then moved to cali and worked remotely.

They would fly in to NYC and meet up about 2-3 times per year for a few days to the main office for big milestone stuff. The rest of the time they paired off in groups and worked on tasks. Communication was via slack and skype for voice I believe. Though they mainly just used slack. He rather enjoyed it.

Previously, he worked remotely for a small webdev shop and they micromanaged him until he quit. He said they would call, email and message him at least 8 times a day for progress on even the most mundane of projects. YMMV.

</comment><comment><USER27> doing that right now

you cannot take shortcuts. like I am building for an operation, so I can walk over to the head of ops, or one of the managers and just figure out my problem. For my remote engineers, we gotta spec everything out otherwise they simply can't build it. And timezone issues make that even harder.

My personal preference is to make a team 100% distributed (could be multiple teams in a company) or 100% local. 100% local can solve local problems. Distributed teams can solve problems that don't require interactions with other teams.

The watercooler brainstorming loss that ent101 mentioned is a big loss and I miss it very much.

<comment><USER28> Completely agree with the comment on spec'ing things out. It's almost impossible to make a spec by patchwork evolution. Things don't turn out well, so it is extremely important to think out the details carefully and clearly, then having the engineers ask to clarify things as they come to them makes much more sense.

</comment></comment><comment><USER29> Timezones. A 2 hour difference is managable but 3 hour difference is pushing it. Sure you can counter this by shifting work hours, but from a practical standpoint, most people like to keep local daylight hours.

</comment><comment><USER30> "The real challenges of being remote are more human, than business." Quoting from ghost.org/blog/5

Communication and collaboration is key. It is harder when there is time zone differences, but you have to find a way to bring everyone together online at least a few times per week.

From our experience, regular team standups and brainstorming sessions are a great way to get the whole team in sync, on the same page, and move in one direction as a single unit, and that is why we built Taskade for nimble and distributed teams.

</comment><comment><USER31> Lower visibility. Out of sight, out of mind. Even in small companies (ranging from 5 to approx. 20 people) I still felt like a number most of the time, like I didn't have much say in the company.

It also does a number on your soft skills if you don't get out much. I noticed a sharp decrease in job offer rate for job interviews before and after my first job in a remote team for 2 years. But other factors might have also been at play at the change in offer rate.

</comment><comment><USER32> Communication pains and always missing out on certain information that might help with developing features, projects and your career in general.

</comment><comment><USER33> During our research, we've asked developers to choose the most important difficulties that remote work entails:

Almost half of our respondents say they don't feel boundaries between their work and personal life. Moreover, the opportunity to not go to the office creates temptation or the ability to spend more time working;

A fifth of the respondents feel detached from the team or have difficulties in communication. These aspects emphasize the importance of proper communication with your employees;

Also, 20% of experienced respondents have difficulties with self-organization and loneliness.

It's important to control the overworking compulsion and build strong communication within your team. Don't let your employees feel isolated and try to spot burnout, because it may lead to disastrous effects. The short-term result of increased productivity isn't worth losing a good specialist.

</comment><comment><USER34> One thing that no one has really mentioned so far is that unless your company has many remote / distributed workers you will likely be the easiest one to get rid of should the need arise. Companies like to be centralised mostly because many CEO's feel that this is the most efficient way of working for them.

</comment><comment><USER35> This is situational and will depend entirely on who you work for, who you work with, and the nature of the organization as a whole.

I started out as a freelancer put in charge of the organization's data operations (getting data from point A to point B with processing in-between). I took the legacy system and transformed it into the next generation of data processing tooling. Slowly the situation morphed from me doing all the work (platform and handling business requests with the platform) to bringing on team members to start carrying the vision forward by taking parts of my previous responsibilities.

The high level is that one teammate now takes on platform improvements, and two others handle business requests.

The person I report to is responsible for the broad cultural structure of our tech team. He put me in charge and gave me full autonomy of half of the technical enterprise (the other half is an internal web application produced by two other teams).

Independence and autonomy are important qualities to allow your teammates in a remote environment (for data operations, anyway), this does require finding teammates with an adequate level of competence and agency when hiring.

I find that 1:1 chat based communication creates a casual environment which leads to an easier formation of relationships with my teammates.

I help form relationships overtime between teammates by asking them directly to rely on others for information, code review, and discussion of platform improvements, and training.

I've never worked within an organization remotely on its payroll.

I think a defining quality of what makes my organization work well remotely is that we're all independent freelancers, so I don't have to worry about what motivates my teammates as much, because it's fairly obvious, they are working for themselves and are motivated to make money by billing hours.

It seems counter-intuitive, but for over 3 years now I've watched roughly the same group of people, with the addition of new people, continue to work together without drama or politics.

</comment><comment><USER36> Serendipity is a lot harder when you're distributed. The close proximity of being in the same room and overhearing conversations helps you stay a lot more connected.

</comment><comment><USER37> The ones people mentioned, plus a big one is you have way less chances of advancement if the team isn´t entirely distributed.

Scott Hanselman is one of the highest-profile remote workers, check out his blog entries:

[https://www.hanselman.com/blog/CategoryView.aspx?category=Re...](https://www.hanselman.com/blog/CategoryView.aspx?category=Remote+Work)

</comment><comment><USER38> I've been working remotely for just over 6 months. Haven't had much negatives, all summarised in this blog post [https://ianduffy.ie/blog/2019/09/11/6-months-of-working- remo...](https://ianduffy.ie/blog/2019/09/11/6-months-of-working-remotely-at- scrapinghub.com/)

</comment><comment><USER39> If you work with anyone who isn't remote, you're going to get left out of things and find it more difficult to communicate.

\- They don't have the right equipment (e.g use built in mic in an open office)

\- They won't want to use the tools the remote team uses (e.g. rarely on slack, prefer email for async communication)

We don't address them so much as we power thru them.

</comment><comment><USER40> I have been on a couple of remote/distributed teams and a common concern is that one misses out on the watercooler/hallway discussions happening between the employees.

We have usually gotten around this by saying - "hey , let us take this discussion over slack and may be XXX would have some good ideas to discuss".

</comment><comment><USER41> I don't have experience with remote teams but I imagine data privacy laws could cause some annoying issues. Imagine debugging some issue in Europe where PII is involved. You couldn't share that data outside Europe.

</comment><comment><USER42> Our (fully remote) startup was acquired by a (fully non-remote) company about 18 months ago. My team was fortunate enough to be allowed to remain completely remote, although we have recently onboarded a couple of in-office team-mates. Most of us live/work a few hundred miles apart from each other.

Here are a few things that I miss in our remote team:

Face to face one-on-ones: I have weekly 1-1s with each team-mate. In previous on-site teams I found that fortnightly or even monthly was more than enough, but with the remote team I find that a weekly 30-60 minute catch-up is needed, because one loses a lot of nuance via even good remote tools. Is Bob feeling cranky today? On-site it was trivial to discern but remote is much harder. Then the 1-1s are less effective because one loses a bunch of the subtle organic cues that guide you in a normal 1-1 conversation.

Whiteboards: Sometimes we have long, complex conversations to resolve issues that a simple whiteboard diagram would resolve in 2 minutes. I know there are a bunch of tech tools that could alleviate this, but we don't have the budget for the really slick solutions and the less slick solutions are seriously lacking. We're considering buying a few ipad pros as an experiment - would be great to hear if anyone has had good results with these. I've not found a replacement for the humble whiteboard when it comes to hashing out a workflow or a layout.

Over-the-shoulder pair programming: I've not found a good solution to this. Screen sharing is abou half of the problem. Being able to point, grab the keyboard, etc. is the harder part to solve. VSCode live sharing is about the best option I've found, everything else has been close to useless.

Planning and retrospective meetings seem to take way longer and seem to be less effective than they are IRL. I think engagement is part of it (I'm a stickler for closing laptops/phones during meetings and that is obviously impossible during videoconference meetings). Another part of it is probably just the small size of faces on video calls. When you have 6 other people in a meeting, they each have less than a postcard of screen estate, so expressions are super hard to read, humour becomes harder, etc. Consequently it's super hard to keep meetings energised and on track.

Small acts of kindness: In our previous team, we would often make each other coffee or bring each other lunch. I found these little gestures go a long way towards easing the friction inherent in a team working hard together.

I'm not sure how many of these are caused/exacerbated by living in a country with crappy, unreliable internet. Maybe huge bandwidth would help?

Here are a few things that we found useful to help alleviate the above:

1\. Regular in-person get-togethers: At least once per quarter, we have a 1-2 day session together, with lots of food, some beers. We spend a lot of time on high-level planning and introspection during these sessions, but also get together for detailed work sessions and pairing on hard problems.

2\. Document the shit out of _everything_. Readmes, meeting notes, TIL slack channels, howtos and guides and playbooks for every possible activity. We have a rule that if someone teaches you something you have to document the lesson somewhere for the next person. Its baked into our team culture now and it helps us a lot, because you can't just grab someone to help you when you need it.

3\. Zero tolerance for bad behaviour: Its a million times harder to fix conflicts remotely, so we have to be extra kind and respectful to each other

4\. Shorter iterations: We run week sprints with documented goals and documented review/kaizen every week. It's a high overhead, but it helps keep everyone in sync, as well as highlighting problems quickly

<comment><USER22> > Over-the-shoulder pair programming: I've not found a good solution to this. > Screen sharing is abou half of the problem. Being able to point, grab the > keyboard, etc. is the harder part to solve. VSCode live sharing is about the > best option I've found, everything else has been close to useless.

tmate is great for this so long as you're okay being 100% in-terminal. One person runs tmate which basically opens tmate and gives you an ssh url. Then everyone else just sshes in and is in the same tmate session - identical to if you both sshed into a shared host and entered a mutual tmate session. It has a hosted version but can also be self-hosted.

<comment><USER22> s/tmate/tmux in a few of those places

tmate.io

</comment></comment></comment><comment><USER43> Bonding. You need to make an extra effort to get to know your remote teammates.</comment>


MacOS High Sierra "root" vulnerability: user reported 2 weeks ago on Apple board - <AUTHOR> https://forums.developer.apple.com/thread/79235 <comment><USER2> The funniest part about all of this is Apple's support twitter account; you can see some social media team is copy-pasting their "Hey no problem, let's just talk about it privately" message faster than I ever thought possible.

</comment><comment><USER3> Kinda funny that the user viewed it as merely a solution to another user's account problems, rather than a gaping security hole.

</comment><comment><USER4> and some people are yelling at the guy for not "responsibly" disclosing it!</comment>


Code Length Measured in 14 Languages - <AUTHOR> http://blog.wolfram.com/2012/11/14/code-length-measured-in-14-languages/

<comment><USER2> Interesting, but he does his comparisons based on line count. Only at the end of a too lengthy article does he show the comparisons based on character and token length. And his definition of token is faulty. As far as I can see it is only identifiers and keywords. (I didnt actually read the code.) Token length is good as it normalizes for stylistic differences, but tokens should include symbols as well as identifiers.</comment>


The Emotionally Fit Founder, Part One: What Is Emotional Fitness? - <AUTHOR> https://medium.com/@dremilyanhalt/the-emotionally-fit-founder-part-one-what-is-emotional-fitness-628fceaac145#.rzjhugs6y <comment><AUTHOR> I like where this series is going...mainly around the thesis that a healthy founder creates a healthy culture.</comment>