The Meaning of 'su' - <AUTHOR> http://pthree.org/2009/12/31/the-meaning-of-su/ <comment><USER2> Copy pasting the best comment from the article. It basically covers the crux.

</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>== "jonkx using on | May 31, 2010 at 10:22 am | Permalink

I worked with the Unix OS from the early 1980′s (at first we ran early versions on a DEC PDP-11) until 1992. Starting in 1992, I did contract work on proprietary versions based on SVR4.

It was just easier to say the initials "S U" or "super-user" than to say "switch user" or "substitute user". To insist on correctness, whether authoritarian, historical or otherwise seems petty.

Depending on the options used, su can be used to switch user, substitute user or become "super user". Success depends on knowledge of the appropriate password. "sudo" on the other hand may allow one to become any other user (depending on the configuration of sudo and being a "sodoer") knowing only the login password.

On the systems I have used, a sudoer can become root ("super user") using this shell command at a terminal:

sudo su – root

and responding to the prompt with the login password used to sign in the current user.

I think it is important to point out that you cannot become "super user" or root from a shell with the su command alone unless there is a root password and that password is entered at the prompt. </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>=====

<comment><USER3> To all people who type "sudo su - root": the much simpler "sudo -i" accomplishes the same (-i launches an interactive shell).

<comment><USER4> The "-i" option actually means "simulate Initial login" -- the idea being -i will drop you into a shell as if you'd logged in as the user in a fresh session. -s will also give you an interactive shell, but doesn't mess with the environment.

(And both -i and -s can also _not_ give you an interactive shell, if you give it a command to run. The point is that it will run the command in the shell rather than just fork()ing and exec()ing like a bare sudo invocation would do.)

<comment><USER5> Read carefully: "sudo -i" to replace "sudo su - root". You should check the "su" manpage and look for the -/-l/--login option.

<comment><USER4> I'm not objecting to that. I'm objecting to the (perhaps unintended) assertion that "sudo -i" means "give me an interactive shell". It does happen to give you an interactive shell (assuming you don't specify a command), but as a side effect. "-s" gives you an interactive shell too, but the semantics are different.

</comment></comment></comment></comment></comment><comment><USER6> This is a great article and people quoting modern manual pages miss the point. The point is that the meaning of su(8) changed and that is conveyed through an nice anecdote where the author _discovers_ exactly how it changed.

In the research version of Tenth Edition Unix, su(8) is described as:

      su, setlog -- substitute userid temporarily, become super user

Which is an interesting intermediate step from today's (or rather 2.9BSD's)

      su -- substitute user identity

found in BSD derivatives.

Btw, the Tenth Edition manual was written mostly by Douglas McIlroy, inventor of pipes. Even if the 1127 group imported outside code for the VAX versions of research Unix (v8-10), they liked a particular kind of documentation, which the imported code lacked, so they wrote their own. Dare I say the style of research Unix manuals closely matches the style of Go documentation today (unremarkable, considering the pedigree).

<comment><USER7> This comment has it correct. For those of you on a Mac (and I specifically mention a Mac, due to its BSD userland utilities), you can see that this is still defined this way today: type `man su` and you'll see:

        su -- substitute user identity

</comment></comment><comment><USER8> I would recommend against using sudo su -, esp if you have <user> ALL=(ALL) NOPASSWD: ALL or such constructs in your /etc/sudoers file that exempt password requirements from executing sudo commands.

1\. su gives you a root shell. Principle of least privilege dictates you should executes the fewest commands as root as required, not all commands as root because you need one.

2\. sudo su - loses auditability of who executed what/when. All we know is that someone got a sudo shell at some point. When the forensics guys come along post-breach, you won't have a lot of good info to give them.

3\. Loss of a shell (via command injection on a web form) may allow remote Command-and-Control of your machine.

If you need a cron or other headless process (daemons, etc.) then use NOPASSWD in conjunction with a whitelisted set of commands (not /bin/bash) to be executed.

If you need an operator to execute a command as a specific user, then use sudo -u <user> <cmd>. Even if you allow ALL commands, at least your audit logs will know what/when the command was executed.

With all powerful commands comes the responsibility of understanding how to use them safely and what the possible repercussions are.

<comment><USER9> In production, yes. For debugging on a test machine, or during a post-mortem, it's just inconvenient not to. If the majority of your time is spent in the shell of a production machine, you're doing something wrong.

</comment></comment><comment><USER10> When perusing early Unix code, it's striking how concise and down-to-the-point it is. We've really accumulated a lot of cruft (mostly for the sake of compatibility and feeping creaturism) over the years.

</comment><comment><USER11> A bit off topic, but man it really bugs me when people (like this author) say "command" because they don't know the right word.

(A mistake made by this article)

"I wonder why the creat() command doesn't have an 'e'."

(Similar examples I've seen around the web)

"I'm using the printf command." "I was doing assembly programming and I used the jump command."

Syscall! Function! Instruction! Let's be precise people.

<comment><USER12> So to be even more precise ;-) are you treating Syscall, Function and Instruction as synonyms?

<comment><USER13> I don't think he is. He references creat, printf and jump, which happen to be a syscall, function and instruction, respectively.

</comment></comment></comment><comment><USER14>
        q = password;
        while((*q = getchar()) != '\n')
            if(*q++ == '\0')
                return;

Notably, you don't actually need the password... Buffer overflow!

</comment><comment><USER15> My beard is rather short as of yet, but I've always read 'su' as an acronym for 'setuid' (because that's what it does).

</comment><comment><USER16> I think it really stands for "super user", here's its man page from Unix v1 <http://man.cat-v.org/unix-1st/1/su> .

<comment><USER17> > su allows one to become the super--user, who has all sortsof marvelous > powers.

I enjoy how informal that man page is. All of today's man-pages would never get away with "fun."

</comment></comment><comment><USER18>
      $ man su

      NAME
         su -- substitute user identity

<comment><USER19> This.

I thought it meant super user too, but then I put in that command and said "ah". Then I moved on with my life....

<comment><USER20> It does stand for super user. The article cites the su.c code from 1975.

</comment></comment></comment><comment><USER21> Taking 'super-user' to mean 'root' seems like a big assumption. Is there anywhere in the Unixverse where root is specifically referred to as 'super- user'? I sort of thought 'super-user' would refer to any user with higher privileges. Well, really just different privileges, but why would you switch to a user with lesser permission to preform the action you probably just got denied? I assume the presented code was just that way because it covered 99% of use cases and was good enough for then and that root is now the default user for the same reason.

<comment><USER22> I'm not 100% sure where you're going with all that, but there are legitimate reasons for the super-user to "move down" into a specific user's identity -- for example, to be sure that files/directories created during some maintenance are owned by that specific user, and have that user's umask applied. Another instance would be file cleanups when the super-user specifically didn't want to be able to delete arbitrary files. There are lots of other cases.

</comment></comment><comment><USER23> What a cute su.c file!

You should see this beast in Solaris!

[http://src.opensolaris.org/source/xref/onnv/onnv- gate/usr/sr...](http://src.opensolaris.org/source/xref/onnv/onnv- gate/usr/src/cmd/su/su.c)

</comment><comment><USER24> In Italian it means "up".

<comment><USER25> In Turkish, it is water

</comment></comment><comment><USER26> It's funny how the article and most of the comments here assume that there is one meaning and it is "out there" for all of us to see. Maybe there isn't any one definite meaning: [http://michaelfeathers.typepad.com/michael_feathers_blog/201...](http://michaelfeathers.typepad.com/michael_feathers_blog/2013/02/the- fallacy-of-one-definite-meaning.html)

</comment><comment><USER27> > "su" was written to only change to the root user on the system. It wasn't > designed to switch to any other user that has an account. "su" meant "super- > user". I need to sit down for a second.

It is _slightly_ over dramatized, isn't it ? :)

</comment><comment><USER28> TL;DR: the author doesn't know, and lists the standard possibilities: superuser, switch user, or subshell. From the article: "Well, I wish I had an answer, but I don't."

<comment><USER29> TL;DR: Legacy code with gotos in it.

<comment><USER30> Way to nitpick about goto while completely overlooking the obvious buffer overflow.

<comment><USER31> This was all I could think about when reading that code.

</comment></comment></comment></comment><comment><USER32> To old hands, su has always and will always mean _super user_. The meaning does not "change" (even if the program does).

</comment><comment><USER33> $ man su

SU(1) BSD General Commands Manual

NAME su -- substitute user identity

SYNOPSIS su [-] [-flm] [login [args]]

...

</comment><comment><USER34> Oh, so it isn't an acronym for suit-up?

</barney></comment>


The Lenna (or Lena) picture - <AUTHOR> http://www.cs.cmu.edu/~chuck/lennapg/ The Lenna (or Lena) picture is one of the most widely used standard test images used for compression algorithms. <comment><AUTHOR> Quote: _The Lenna (or Lena) picture is one of the most widely used standard test images used for compression algorithms._</comment>


Ask HN: how to find an interesting internship? - alexis-d

Hello HN readers,
I'm a french student currently studying Computer Science in Dublin (Trinity College), and I would like to know if you have some tips to find & get a good/interesting internship during summer '12.
For the record: - I enjoy mainly C/Python programming but I would be happy to learn something else (like functionnal programming for instance) - I enjoy solving algorithmic/math related problems (like those you can find at Project Euler [1]) - I don't mind if the internship is in a big company like Google or a small start-up. - I want to be useful, not a bring-me-a-coffee intern.
[1] http://projecteuler.net/ <comment><AUTHOR> The monthly "Who's Hiring" threads here on HN are great resources for internships.</comment>


Ghost Lanes: Angled "Scarchitecture" Reveals Historic Urban Roads and Railways - <AUTHOR> https://99percentinvisible.org/article/ghost-lanes-angled-scarchitecture-reveals-historic-urban-roads-railways/ <comment><AUTHOR> Recent spam post here on railroad track gauges set me off looking for the US city where a lazy surveyor cut some blocks in half diagonally, resulting in permanent hypotenuse streets. Thought it was Charleston Or Savannah, but I can find no evidence. Apocryphal?</comment>


Coroutines in C, revisited - <AUTHOR> http://vicsydev.blogspot.com/2016/11/coroutines-in-c-revisited.html <comment><USER3> This is a C++ coroutines framework( [https://github.com/markpapadakis/coros- fibers](https://github.com/markpapadakis/coros-fibers) ), but its trivial to "port" it to C.

I 've also written a few things about coroutines and fibers(e.g [https://medium.com/software-development-2/coroutines-and- fib...](https://medium.com/software-development-2/coroutines-and-fibers-why- and-when-5798f08464fd#.qz59082w0) and [https://medium.com/software- development-2/high-performance-s...](https://medium.com/software- development-2/high-performance-services-using-coroutines- ac8e9f54d727#.1s8lfoswb) ).

Coroutines based on stack manipulation(as opposed to simple FSMs) are extremely powerful and are particularly useful for implementing fair scheduling across runnable 'processes' and concurrent execution contexts. Fair scheduling in particular can be really important in the domain of distributed systems that need to process potentially long-running and/or expensive request which would otherwise stall processing other cheaper requests indefinitely. Combined with async I/O, this gives near optimal concurrency and resources utilisation. Coroutines are often associated (literally and figuratively) with futures/promises. See SeaStar framework for a great implementation of those ideas.

<comment><USER4> >> Coroutines based on stack manipulation(as opposed to simple FSMs) are extremely powerful and are particularly useful for implementing fair scheduling across runnable 'processes' and concurrent execution contexts.

So, isn't this what threads are for? This is not a snarky comment, genuine interest: but isn't this what the OS scheduler and thread implementations are meant to do, and implementing essentially ones own threads and scheduling is the epitomy of 'reinventing the wheel'? Specifically, when going down the route of using a coroutine to essentially duplicate functionality provided by native threads, is there any performance advantage? My understanding is that, nowadays, OS threads and schedulers are very highly optimize for performance.

Other than being able to write concurrent code with yield() and resume(), is there really any reason to NOT use OS level primitives?

<comment><USER3> That's a good question, and the answer has to do with, obviously, the cost of spawning OS threads/processes, context-switching among them, and how all that affects caches (cache hit/miss ratio dominates most workloads nowadays, more so than actual CPU instructions execution). Context switching can be cost on average 30micros of CPU overhead, but can reach as high as 1500micros. (You can reduce that by pinning threads to core, but the savings will likely get may be as much as 20% - maybe). Thankfully now, at least on Linux, AFAIK, a context switch doesn't result in a TLB flush - back in the day that was quite expensive. Whenever the OS scheduler needs to context switch, it needs to save old state(including regs), and restore another state and perform some other kind of book-keeping. This is more expensive and convoluted than doing it yourself -- you also usually don't need to care for all possible registers, so you can reducing switching costs by e.g not caring about SSE registers. Apps that create too many threads are constantly fighting for CPU time - you will end up wasting a lot of cpu cycles practically cycling between threads.

Another hidden cost that can severely impact server workloads is that, after your thread has been switched out, even if another process becomes runnable, it will need to wait in the kernel's run queue until a CPU core is available for it. Linux kernels are often compiled with HZ=100, which means that processes are given time slices of 10ms. If your thread has been switched out, but becomes runnable almost immediately, and there are 2 thread before your threads before it in the run queue waiting for CPU time, your thread may have to wait upto 20ms in a worse case scenario to get CPU time. Depending on the average length of the run queue (reflected in sys.load average), and how length threads typically run before getting switched out again, this can considerable affect performance.

Also, kernels don't generally do a good job at respecting CPU affinity -- even on an idle system. You can control that yourself.

If you are going to represent 'jobs' or tasks as threads, and you need potentially 100s or 1000s of those, it just won't scale - the overhead is too high.

If you control context-switching on your application (in practice that's about saving and restoring a few registers) -- cooperative multitasking -- you can have a lot more control on how that works, when its appropriate to switch etc, and the overhead is far lower.

Oh, and on average its 2.5-3x more expensive to context switch when using virtualisation.

<comment><USER4> >> If you are going to represent 'jobs' or tasks as threads, and you need potentially 100s or 1000s of those, it just won't scale - the overhead is too high.

This seems to be an indictment against containerization (ie docker, kubernetes, etc). How can a single machine, even with containers, scale out if this is true? Do people advocating docker and similar technologies not understand or recognize that their containers should only utilize y threads (where y = (total threads per machine)/(number of containers hosted on that machine))? I personally have never heard this mentioned as a consideration when deploying docker, for example.

<comment><USER5> The advantages of containers are multidimensional. The benefit of running multiple processes on a single node is not solely to increase utilization of a given machine but to also gain advantages in deployment, etc.

Schedulers can take what's being mentioned here into account. You can say "I need at least 2 cores but would like up to 8" or "I need guaranteed 8 cores, evict lower priority containers if necessary" to ensure your containers aren't fighting over resources . You can also classify machines for certain types of workloads and then specify certain containers should run on a particular class of node. Not all container platforms handle this, but Kubernetes does at least.

<comment><USER6> And as we add improved resource management and tuning to Kubernetes you gain those improvements without having to change your deployment pipeline - <USER2> like when a compiler gets better you get more performance for "free".

</comment></comment></comment></comment></comment></comment><comment><USER7> I just created a submission for libco, which I think is the best (fastest and most portable) library for coroutines in C. It's great, I wish it got more love. [https://news.ycombinator.com/item?id=13199581](https://news.ycombinator.com/item?id=13199581)

<comment><AUTHOR> I'm curious, how is libco faster or more portable than the approach described in this post?

<comment><USER8> It's not, they're two separate things. Unfortunately, nobody can agree on terminology for this stuff. I try not to ever use the word 'coroutine' anymore because of this.

libco is what I call a cooperative threading library. It allocates a stack for each thread. This means that thread A can call six functions deep into helper functions, and suspend in the middle of a helper function, and then resume right back at that same point.

Thus, you program libco very similarly to how you do preemptive threading, only you don't ever need any locks, and you have to do your own scheduling (which can be as simple as "co_call and co_return", or "co_jump" in assembly terms.)

The CORO #define wrappers in the article is what I would call a very simple state machine. There is no thread, there is no state machine, there is no user-space context switching going on. You only get the call/ret style behavior, and you can't ret from a subroutine called inside of it. It's far, far less useful.

However, when you can get away with it, CORO will be about ten times faster on average. libco is optimized as much as possible with pure assembler. On ARM, it's literally three instructions. On x86, it's ten. The entirety of the burden is because modern CPUs do not enjoy having their stack pointer changed. Go to older CPUs and the overhead drops substantially, but few people are coding on a 68000 anymore. This also means that libco is _not_ ISO C. It requires an assembly implementation or a platform that lets you poke at jmpbuf from setjmp/longjmp to work. In practice, it'll work anywhere you'd reasonably want. x86, amd64, ppc, ppc64, arm, mips, sparc, alpha; Windows, macOS, Linux, *BSD, Haiku; etc have all been tested. And even if you find something crazy obscure, you only have to write about twenty lines of code to port it.

The magic of libco is that it's about 100 times faster than preemptive threading would be for the context switching overhead. So when you actually need subroutines, and when you don't want to be swamped in locks/semaphores/critical sections, it can eliminate giant swaths of nested state machines (switch tables) by keeping all that state inside each local stack frame, transparently and out of your codebase. Deeply nested state machines are a serious pain in the ass to reason about and maintain, trust me.

Also ... both of these methods have a serious flaw (as does preemptive threading): serialization. If you want to save the state of your program in the middle of working, and restore to that position later (think save states in an emulator) ... it'll be a bit tricky with libco. But since the state is hidden by the #define, it'll be absolutely impossible with CORO, unless you redesigned it to use external state, which would make it even clunkier to use.

In conclusion: both complement each other. I feel C++20 or whatever should add CORO-style stackless state machine wrappers to the language for convenience. But it should definitely leave stack-based cooperative threading out, because that can easily be done as a library. (It can include library functions for that purpose, but it doesn't need language-level primitives.)

There's a hundred cooperative threading libraries, by the way. My aim with libco was to make a library that has four functions (co_create, co_delete, co_active, co_switch) and zero types/structs. As simple and fast as possible, supplying as many optimized backends as possible. Then let people build on top of that. The downside is most people still choose to write their own libraries from scratch, so there's a lot of wheel reinventing going on.

<comment><USER9> > It's not, they're two separate things. Unfortunately, nobody can agree on > terminology for this stuff.

There is standard terminology though. Coroutines allow arbitrarily nested calls back and forth. So-called "stackful" coroutines are the only possibility in C. Other languages perform a program translation into continuation-passing style to support stackless coroutines with the same semantics.

CORO falls under a class of abstractions known as "generators". You can think of it like a degenerate coroutine limited to a single call level, but I don't think conflating the terminology like this is useful.

<comment><AUTHOR> You got it backwards though; all the name means is the subroutine has multiple entry points for suspending and resuming execution, which can be used to implement nonpreemptive threads, generators and other abstractions.

</comment></comment></comment></comment></comment><comment><USER10> How does this work compare with libdill[1]?

[1] [http://libdill.org/](http://libdill.org/)

<comment><USER11> At a glance this just looks like a short, simple coroutine implementation/hack using C macros, whereas libdill does a lot more to extend C syntax in similar manner, but in a much more comprehensive way (I believe with the intention of matching some of Go's concurrency mechanisms). The author compares this to Duff's device so the comparison seems apt.

I would pick libdill for any serious program and keep this on hand as a C snippet in Vim or $EDITOR.

[edit] I should say this could be used in a "serious" program too, but it's nice and short in a way that looks like a great snippet to me

</comment></comment><comment><USER12> I've recently made a similar protothread/coroutine library for embedded systems where local continuations can be either setjmp or goto or case labels. Nothing fancy, but perhaps someone find it useful: [https://github.com/zserge/pt](https://github.com/zserge/pt)

</comment><comment><USER13> This is a rediscovery of contiki's protothreads:

[http://contiki.sourceforge.net/docs/2.6/a01802.html](http://contiki.sourceforge.net/docs/2.6/a01802.html)

<comment><USER14> Which afaik is based on the publication of Simon Tatham:

[http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html](http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html)

Who directly references good old duffs device. The title seems to acknowledge the existence of said article, but I didn't find any reference.

<comment><AUTHOR> I know, I know. Why is it so important that someone else did something conceptually similar once upon a time? Can't you see the value in standing on their shoulders and try to reach further in some direction? We're all in the same boat here, you can't own ideas. In this case I was aiming to simplify API and usage while keeping the performance, and I feel I managed to take at least a few steps in that direction.

<comment><USER15> Well it is useful for others to know the history and have other references. I am sure it is not intended to diminish your work.

<comment><USER14> Exactly that!

Sorry if my comment came across like an insult. Wasn't intended as such. Maybe it was just me hoping to find a direct improvement of Tathams implementation. Which I would call "quirky" at best.

Your implementation seems to be much more "useable" and understandable in comparison.

After reading through more of your library I must say, I like it's style.

<comment><AUTHOR> None of this is personal to me, I have no idea where the inspiration came from; I'm just trying to share the beauty I see in the concepts. So I get a bit frustrated with anything that steals focus from my mission, like history lessons. I don't really care who thought of what first. Sorry if that came across as hurt feelings, there is no conflict here.

I'm glad you like the humble beginnings of the library I've always been wishing for :)

<comment><USER14> This makes your work even more interesting. I don't know if you read the original Mail [1] in which Tom Duff shared his Device, but at the end he's mentioning that he had an idea for something like coroutines:

> It amazes me that after 10 years of writing C there are still little corners > that I haven't explored fully. (Actually, I have another revolting way to > use switches to implement interrupt driven state machines but it's too > horrid to go into.)

He later replied to Simon Tatham, that his coroutines actually where those "horrid" ideas.

Obviously you must had some thoughts similar to those two. Kudos for that. You seem to to have a deep understanding of the concepts that make the C language (and how to twist them) ;).

[1]: [http://www.lysator.liu.se/c/duffs- device.html](http://www.lysator.liu.se/c/duffs-device.html)

</comment></comment></comment></comment></comment></comment></comment><comment> c-smile That appears as a variant of Simon Tatham idea: [http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html](http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html)

Just in case, I've made C++ variant of it: [https://www.codeproject.com/Tips/29524/Generators- in-C](https://www.codeproject.com/Tips/29524/Generators-in-C)</comment>


I'm taking a class on Go and documenting my progress. - <AUTHOR> http://golang.tumblr.com/

<comment><USER2> Am I the only one who though he meant this Go? <http://en.wikipedia.org/wiki/Go_(game)>

<comment><USER3> Web log, March 10th. Today I have become 29kyu. I still lose to my sensei with 13 handicap stones, despite the fact that these are tutoring games. May God have mercy on my soul.

<comment><USER4> One of the few comment where I laughed in real-life. So, LOL :-)</comment></comment></comment>


Quantum Computer Comes Closer to Cracking RSA Encryption - <AUTHOR> http://spectrum.ieee.org/tech-talk/computing/hardware/encryptionbusting-quantum-computer-practices-factoring-in-scalable-fiveatom-experiment <comment><USER2> If I understand correctly, this quantum computer came closer to cracking RSA the same way shifting in your chair gets you closer to Jupiter.

<comment><USER3> Werner von Braun oversaw development of some awfully small crummy rockets [https://youtube.com/watch?v=Ii7uwp1SRIM](https://youtube.com/watch?v=Ii7uwp1SRIM) (imagine the ones even before these!) but also oversaw the Saturn 5 which lifted every person who walked on the moon. We understand the physics, now it's a matter of engineering and funding!

<comment><USER4> Not necessarily. What if entangling each quabit is twice as hard as the previous one? There's a lot of people that suspect physics may prevent quantum computing from scaling up. See also:

[http://phys.org/news/2012-02-quantum-physicist-100k-proof- sc...](http://phys.org/news/2012-02-quantum-physicist-100k-proof-scaled- up.html)

<comment><USER3> But the guy who made that bet doesn't think physics prevents a quantum computer. "Many people assumed I was a QC skeptic, and was offering the prize because I hoped to spur research aimed at disproving QC. Which is actually an interesting misreading" [http://www.scottaaronson.com/blog/?p=902](http://www.scottaaronson.com/blog/?p=902)

<comment><USER4> Yeah I was just pointing out that there is disagreement. I think of it like time travel - nobody has proved that it is impossible, but a lot of people suspect that a "sensible" universe wouldn't allow it.

</comment></comment></comment></comment></comment><comment><USER5> I love it when people tout a result as being "only 15-30 years away." Is there any large scale human technological research project in all of human history which lasted 20 years and actually produced what was promised? There is no incremental path here; any time someone says "20 years" it means they have no idea how to do this thing.

<comment><USER6> The human genome project. Their goal when starting was "this will take 15 years", they completed it in 13. The Apollo program: goal of less than 9 years (end of the decade) when it was proposed in 1961 to land a man on the moon and return him to Earth, completed in 1969.

If you go back quite a ways, I'm willing to bet at least some of the innovation-required Castles and Cathedrals and Pyramids of history were completed "on schedule" with it known up front that they would take many years to finish.

I suspect a lot of projects are accurately classified as 10-30 years away, _given a certain level of funding and a dedicated team_. Absent that, they may very well take twice as long or more. I always like to see what these long- term oriented institutions like SENS and MIRI say they would do if they had x times more money, to see that they've got a plan -- fortunately those ones do give that information.

<comment><USER7> > I suspect a lot of projects are accurately classified as 10-30 years away, > given a certain level of funding and a dedicated team

Precisely. Take fusion for instance:

[http://i.imgur.com/sjH5r.jpg](http://i.imgur.com/sjH5r.jpg)

This is the source of the "joke" that fusion will always be 20 years away. It's because it's been grossly under-funded ever since that prediction was made.

<comment><USER8> This is really interesting! Have you read the source report? I'm curious as to why/how the predicted required budget would fluctuate so much. For such a specialised and frontier based project, surely you'd be aiming for consistent staffing (and thus consistent staff budgets) year on year no?

<comment><USER7> My guess is that is fluctuates because there are a discrete number of new experiments to be constructed, and these don't cost a constant amount during their construction.

<comment><USER9> That was my guess as well. Looking at the graphs, there are about three clear peaks in the maximum, accelerated, and aggressive plans, muddled out a bit in the moderate plan.

What are these three experiments? Which of them have already been done in the existing plan? And what others might need to be added?

Also curious is the expected total cost. Eyeballing each plan average cost and multiplying by the duration, the total costs are 6x14=84, 4x17=68, 3x22=66, and 2.5x29=72.5 billion dollars. The accelerated and aggressive plans are more expensive than the moderate plan!

I suppose there's some additional overhead costs associated with keeping the program running for 29 years instead of 17, but I would have expected all the rush orders, overtime, and extra staff to make the faster programs much more expensive.

</comment></comment></comment></comment></comment></comment><comment><USER10> Nice clickbait, Scott Aaronson on this: [http://www.scottaaronson.com/blog/?p=2673](http://www.scottaaronson.com/blog/?p=2673)

<comment> kenny-log_ins yep. whenever i read anything sensational about QC I immediately head over to his blog to read about what it actually means.

</comment></comment><comment><USER11> The irony that the SSL cert is invalid for the NSA FAQ linked to in the article... [https://www.iad.gov:8443/iad/library/ia-guidance/ia- solution...](https://www.iad.gov:8443/iad/library/ia-guidance/ia-solutions- for-classified/algorithm-guidance/assets/public/upload/CNSA-Suite-and-Quantum- Computing-FAQ.pdf)

<comment><USER12> Not entirely true.

\- Safari; Certificate is fine \- Chrome; Certificate error due to SHA-1 signatures \- Firefox; Unknown issuer

Why is the DoD root certificate in OSX but not in Firefox?

<comment><USER13> Because someone would have filed a bug on Bugzilla arguing for it to be removed on moralistic grounds I bet.

I'm all for having principles, but you have to accept that it'll break for your users.

<comment><USER14> The strong argument here is that if you are giving a lock icon but knowingly allowing decryption by a known bad actor, you are also breaking the experience of your users.

I also agree with the weaker argument that the cert in question is essentially for a local intranet and that the DoD can, for as long as it continues to exist, which I find politically disagreeable, install the cert locally on its own resources.

If it wants to publish material for broader consumption, it can get a cert like everyone else.

<comment><USER15> Trusting the cert does not, precisely, allow decryption by the certificate authority. It rather gives the certificate authority the ability to issue certificates for domains, which _if they are used to establish a connection_ , can encrypt and decrypt traffic _for that connection_.

So yes, if you trust the DoD root certificate, then the DoD as well as every certificate authority in the world could in theory generate a valid certificate impersonating www.google.com or any website. With a sophisticated enough attack, they could do this just for your one visit to one particular website, in such a way that it would be difficult for anyone to realize that it's happening. However, though this is difficult to notice if you're not looking for it, it's actually _really easy_ to notice if you _are_ looking for it. If you use Chrome, then Chrome will report the certificates that it sees back to Google, who track what certs are issued by CAs. This is how Google noticed that Symantec issued fake certificates for Google domains in Symantec's test environment: [https://googleonlinesecurity.blogspot.com/2015/10/sustaining...](https://googleonlinesecurity.blogspot.com/2015/10/sustaining- digital-certificate-security.html)

Anyway, the practical risk of trusting a DoD certificate is pretty low. To decrypt your traffic, they'd have to man-in-the-middle intercept your connection to a web server, and _replace_ the site's valid certificate with their own, which would leave an obvious and flagrant trail to anyone who is looking. This would very obviously "play their hand" and anyone with evidence of being attacked that way by a first world government would be immediate worldwide news in the security community. If they did this even once, they'd need to be extremely careful not to be caught by any of the countermeasures that detect this kind of surveillance.

That kind of attack would be a one time thing, because evidence of being attacked through the DoD cert would cause all browser vendors and OSes to yank support for it. CAs have been revoked for far less justified reasons than _explicitly attacking someone_.

I find it much, much, much more likely that targets of interest will simply be attacked and exploited through regular known security mechanisms - such as software vulnerabilities or built-in back-doors. These things don't leave an obvious trail and smoking gun pointing back to the perpetrator. Someone MITMing your website visits with the DoD root certificate would stir up a shitstorm. "Some anonymous IP broke into my computer with a 0-day and installed a rootkit" is not particularly newsworthy by comparison. Even the recent news of backdoors in networking product codebases is, while newsworthy, not really that surprising these days. Active evidence of DoD interception of someone's network traffic followed by evidence of CA certificate misuse would drop like a nuclear bomb in the security community, _especially_ if for no extremely well justified reason. It would be the proverbial straw that broke the camel's back in terms of government interference with Internet security, and would lead to a digital revolt even more severe than what Snowden's disclosures caused. Government technical experts will be aware of this and will use other methods, at least in any context where it could be plausibly noticed.

To be clear, I completely believe that the government is or could passively conduct surveillance on virtually all electronic communications. I just don't think they'll go as far as actively intercepting and modifying a connection, and inserting a fake certificate, within the borders of the country or in any normal circumstance. Maybe they would do such a thing within the private networks of North Korea, but I'd be highly skeptical of them doing it within the US, and _with the DoD certificate of all things_. It would be too obvious and has too poor of a risk/reward payoff compared to other methods. If they were going to do this, they'd steal the private key from another CA and use it instead. Because that capability could be noticed and "burned", they'd save it for high value targets only.

So, in all practical analysis, I think it is extremely unlikely that the DoD will attack people through their root certificate, though I concede that it's plausible. I would be interested in feedback from others about this reasoning.

</comment></comment></comment></comment></comment><comment><USER16> I have a feeling that we're going to wake up one day and there will be a legitimate breakthrough in quantum computing, leading to RSA no longer being a legitimate standard for security.

My question to HN: Have any of you guys attempted to come up with a plan for if/when this happens? Are there any algorithms in suites like OpenSSL that are quantum-resistant? Is SSL/TLS even compatible with a post-quantum world?

<comment><USER17> There are not, not in OpenSSL. Viable post-quantum encryption is a hot research area right now. There are a number of approaches that seem promising; some of them, like hash-based, lattice-based, and code-based crypto, are actually relatively old concepts that were pushed aside because RSA is more efficient, but which regain their edge if quantum computers become viable.

[https://en.wikipedia.org/wiki/Post- quantum_cryptography](https://en.wikipedia.org/wiki/Post-quantum_cryptography)

The trick with all of this is that there isn't all that much cryptanalysis work of some of the more promising PQ schemes, so trying to preemptively adopt them just in case quantum computers learn to factor numbers bigger than 15 is likely to do more harm, in the short term, than good.

</comment></comment><comment><USER18> I'm familiar with the implications of quantum computing on factorization and thus DEcryption but have heard very little about about quantum computing enabling ENcryption until the last paragraph of this article

("...Chuang expects to see quantum encryption methods that will inscribe sensitive data into the very states of atoms")

Very curious about current state of this research (relative to the current state of quantum decryption)--any experts in the room?

<comment><USER19> Not an expert on Quantum cryptography, but an ex particle physicist here. The basic idea is that using a quantum channel (sadly means new hardware, so not over tcp), eavesdropping becomes impossible without destroying the quantum state of the signal (guaranteed by the laws of Quantum Mechanics). If an eavesdropper intercepted a message, that would be detectable and you can drop that packet. Wikipedia has a good intro: [https://en.wikipedia.org/wiki/Quantum_cryptography](https://en.wikipedia.org/wiki/Quantum_cryptography)

<comment><USER20> And yet, isn't it true that MITM attacks still work, as long as the MITM has the same hardware?

<comment><USER21> Theoretically, if you intercept in the middle, you destroy the pattern that you observe. This is a physical quantum effect, and will happen no matter what hardware you use

Since the intended use is key distribution, a MITM is fine as long as you can detect it reliably: you can keep sending new keys until one isn't eavesdropped upon, and then use that key.

<comment><USER22> But how do you detect it reliably?

<comment><USER23> If someone intercepts the quantum key, it will modify it 25% of the time. If you randomly measure (and verify publicly with the sender) a fraction of your total key and find it unmodified, it means the rest of the key probably is too, up to a certain security factor. By starting with a longer key and measuring more of it (or doing privacy amplification, for example xor-ing multiple keys together), you can get as much security as you want. It also means the security is everlasting, meaning someone cannot retroactively break your key in 100 years using some mega-computer.

</comment></comment></comment></comment></comment></comment><comment><USER24> If you want to know more about Quantum Computation, there is an edX course ([https://www.edx.org/course/quantum-mechanics-quantum- computa...](https://www.edx.org/course/quantum-mechanics-quantum-computation- uc-berkeleyx-cs-191x)). It goes over the Shor algorithm and the quantum Fourier Transform that leads up to the Shor algorithm.

</comment><comment><USER25> I don't think this article implies we are anywhere close to feasible quantum computers but...if I worked on the assumption that sufficiently powerful quantum computers exist (thought experiment), what would be my available and usable options today? Encrypt everything I deem important enough with symmetric encryption?

I have found this: [https://en.wikipedia.org/wiki/Post- quantum_cryptography](https://en.wikipedia.org/wiki/Post-quantum_cryptography)

But am not sure what is considered the state of the art. Stehle-Steinfeld seems like the most promising option from my very uninformed position. Supersingular elliptic curves also seem to have nice properties but I have to admit I don't even fully comprehend them. Would love for a crypto expert to chime in :)

</comment><comment><USER26> Somehow the submitted link got mangled:

[http://spectrum.ieee.org/tech- talk/computing/hardware/encryp...](http://spectrum.ieee.org/tech- talk/computing/hardware/encryptionbusting-quantum-computer-practices- factoring-in-scalable-fiveatom-experiment)

The article has a broken link to the paper abstract, which is " _Realization of a scalable Shor algorithm_ " available here:

[http://science.sciencemag.org/content/351/6277/1068](http://science.sciencemag.org/content/351/6277/1068)

And I'm yet to find a full copy of the paper anywhere, but it sure looks interesting...

Edit: Ah, here it is:

[http://arxiv.org/abs/1507.08852](http://arxiv.org/abs/1507.08852)

There's also " _Compiling quantum algorithms for architectures with multi- qubit gates_ " which cites the above:

[http://arxiv.org/abs/1601.06819](http://arxiv.org/abs/1601.06819)

<comment><USER27> The title is also a bit clickbaity. Yes, QC are "closer" to breaking RSA... but...

"Briefly, the new work uses Kitaev's version of Shor's factoring algorithm, running on an ion-trap quantum computer with five calcium ions, to prove that, with at least 90% confidence, 15 equals 3×5..... So, what's new is that a QC has now factored 15 "scalably": that is, with much less cheating than before." \- (Scott Aaronson).

</comment></comment><comment><USER28> Could anyone point me in the direction of how quantum hardware is currently designed? I'd love a technical explanation.

</comment><comment><USER29> I've always been confused by the claims of quantum computing, I'm hoping one of the clever folk here can steer me to an understanding. Doesn't the very nature of superposition and uncertainty make determining when the process has solved the problem impossible to determine? Its like, when you look at the data, you change it, and if it wasn't solved, you've already forced it into a state, and if it was solved, by observing it you may change it to something else. How are these problems solved with quantum computing?

<comment><USER30> that is in part what this discovery is about: how to read out and disentangle the solution from superposition. the roots of the answer to your question are in "shor's algorithm," which is the original proposal for factoring integers in polynomial time with high probability.

<comment><USER29> thanks akarve, I shall read abot "shor's algorithm"

</comment></comment></comment><comment><USER31> I'm sure we'll be the first to hear when they actually do. /s

</comment><comment><USER32> Anyone know if this is the dwave quantum computer or a different one?

</comment><comment><USER33> After reading "a quantum computer that could someday factor any number, and thereby crack the security of traditional encryption schemes." I understood, that author has no idea what he's talking about.</comment>


Old school sierra adventure games ported to HTML + JS - <AUTHOR> http://sarien.net/

<comment><USER2> I just noticed that King's Quest VI was on the Steam store... I spent _many_ hours in my youth playing that on my Packard Bell 386 (and yes, it ran terribly). That game in particular though required the user manual in order to solve puzzles given the listing of symbols in it - assuming pirates wouldn't have access to a copy machine. I wonder how that and other games that have been put up for sale again handled that?

<comment><AUTHOR> Yeah, that was a common anti-piracy measure for Sierra games. The earlier games had a pretty boring "what is the xth word on page y" quiz, but by KQ3 they realized it was more fun to incorporate in-game puzzles with content in the manual.

As for redistribution... I assume they just provide a PDF of the manual, instead of actually rewriting parts of the game, but I don't really know for sure. I haven't yet checked out the Steam version of KQ6.

<comment><USER2> True true, I hadn't considered the use of a PDF for it. I hope it's good quality.

</comment></comment></comment><comment><AUTHOR> Apparently this has been around for awhile, but its the first I've seen it. A pretty darn impressive (mostly) automated port to javascript -- rendering done using DOM objects instead of inside a Canvas container. Support for multi- player & chat is pretty cool as well.

</comment><comment><USER3> Police Quest, Space Quest, King's Quest, Hero's Quest, Leisure Suit Larry, Black Cauldron, Gold Rush.. best games ever. (I'm probably forgetting some.) Fancy 3D graphics are cool and all.. but some of the best games ever only needed 16 to 256 colors and a keyboard.

</comment><comment><USER4> My father gave a "stone age ax" to Mark Wilden; the coder of Leisure Suit Larry.

([http://groups.google.com/group/alt.support.diabetes/msg/7c00...](http://groups.google.com/group/alt.support.diabetes/msg/7c002a07ce3e742c?hl=en&dmode=source))

> _Someone mentioned IDDT's Bruce Beale a while ago. He's a great guy, and > I've enjoyed his hospitality several times on trips to England. He gave me a > Stone Age axe given him by the Prince of Denmark (and there are pictures to > prove it)._

</comment><comment><USER5> I thought Activision shut down Sarien.net in 2011 because the game content was copyrighted? What changed since then? The Sarien.net forums don't mention any legal change.

<comment><USER6> They have given him permission to host the first game in each series:

[http://martinkool.com/post/13587392285/sarien-net-the- full-s...](http://martinkool.com/post/13587392285/sarien-net-the-full-story)

</comment></comment><comment><USER7> I could never launch the spaceship in space quest. I remember I bought two different walk throughs and spent at least 20 hours but I never got it :-(

I never understood how anyone got past the first hour of gameplay in space quest.

<comment><USER8> Because they were bored and if you wanted to play a game, then that was what you played. So you were either a) reduced to brute forcing puzzles (use xxx look yyyy) or b) called Sierra's hint line.

Thinking back, I think that might be the reason a lot of the puzzles were so obscure - to get you to spend some more $$$ to win the game. Kind of like proto-freemium.

<comment><AUTHOR> Oh man, I definitely brute forced the crap out of those games. And then I called the help line :) Yeah, come to think of it, they were the original Zynga in that respect.

</comment></comment></comment><comment><USER9> My fingers were crossed for "Leisure Suit Larry"...

</comment><comment><USER5> I've dreamed about making a _King's Quest_ MMORPG and Sarien.net comes pretty close. :)

</comment><comment><USER10> Great, there goes my productivity for a week.</comment>


Scientists cook up new recipes for taking salt out of seawater - <AUTHOR> https://phys.org/news/2019-07-scientists-cook-recipes-salt-seawater.html <comment><USER2> Having fancy chemistry as in the article is great, but there already exist thermal desalination solutions that require heat (e.g. geothermal, industrial waste heat) rather than work (e.g. electricity for R.O.). For example MED: <[https://en.wikipedia.org/wiki/Multiple- effect_distillation>](https://en.wikipedia.org/wiki/Multiple- effect_distillation>) or MSF: <[https://en.wikipedia.org/wiki/Multi- stage_flash_distillation...](https://en.wikipedia.org/wiki/Multi- stage_flash_distillation>).

Steam is _not_ required for MED. Hot water < 100C is adequate. Many ocean- going vessels already use the waste heat from their engines and MED to make freshwater from seawater.

ORC driving RO seems to be most efficient in some situations <[https://www.mdpi.com/1099-4300/17/11/7530>](https://www.mdpi.com/1099-4300/17/11/7530>), but MED is a simple, no-moving-parts solution that is also efficient.

</comment><comment><USER3> This is a great paper, the really cool bit is that it seems fairly straight forward to convert this to a larger process. Basically add saltwater, warm it, take the settled part of the solution (which is now desalinated) out of the bottom, and the salt dense water out of the top, cool it and precipitate out the salt. Nothing has to evaporate everything runs at a normal vapor pressure so you aren't struggling with high pressure and low pressure domains.

I'd love to see if you could use spent nuclear fuel (which is an excellent heat source) to just run one of these things continuously for a couple of decades :-).

</comment><comment><USER4> "The current state-of-the-art in RO desalination works very well, but the cost of RO desalination driven by electricity is prohibitive,"

Why is taking salt out of sea water such a challenge?

<comment><USER5> Desalination is cheap in day to day terms, it's the scale of water we use that's the issue.

Sure, we can get ~1,000 gallons of drinking water for 3$ via desalination. That works out to a monthly water bill increase of ~45$ for a family of 5. Unfortunately, crops need incredible amounts of water. So, growing corn etc with desalination would case food prices to ~quadruple.

<comment><USER6> Why do you think that the cost is an increase?

I pay quite a bit more than $3/kgal, and a large fraction of that goes toward funding the SFPUC's massive infrastructure for bringing Hetch Hetchy water to the Peninsula. A desalination plant would be located on the coast or on the bay and would not require this infrastructure.

As far as I'm concerned, the problem is the capital cost of the plant and the plumbing to safely suck in saltwater and discharge brine and has essentially nothing to do with electricity.

The situation isn't helped by the fact that, in average and wet years, demand for desalinated water would be nil, since the Hetch Hetchy infrastructure already exists.

<comment><USER5> Sewage and distribution is not included in these costs. Current systems get water for almost nothing it's mostly distribution and sewage systems that you're currently paying for.

As to why this is, a single pipe carrying 1,000x as much water costs no where near 1,000x much per foot. Each home might only need 1/10,000,000 the water, but it's got to be built for peak demand not average useage. On top of this, people don't live at sea level, so you need to pump that sea water up before you can use it.

PS: Not to mention most distribution systems leak significantly, that 3$ assumes 100% efficiency at 50% it's more like 6$.

<comment><USER6> None of this is at all relevant to my point. SFPUC charges over $4/ccf for wholesale water. This does not include distribution costs, and this is paid regardless of whether the water is sold, leaks, or is used for firefighting. If SFPUC's wholesale customers purchased desalinated water and managed to escape their SFPUC contracts, they would eliminate this expense.

edit: [http://bawsca.org/water/rates/wholesale](http://bawsca.org/water/rates/wholesale)

<comment><USER5> That's not exclusive price just per gallon of water.

[https://sfwater.org/modules/showdocument.aspx?documentid=774...](https://sfwater.org/modules/showdocument.aspx?documentid=7742)

Wholesale untreated water is 1.02$ per 1,000 gallons. Page 16: ( 0.76 per 748 Gallons delivered). Plus a fixed fee for the size of the pipe (22.67$ for a one inch pipe.)

<comment><USER6> Curious. I'm pretty sure my water provider pays the BAWSCA rate. I don't know why it's so different.

edit: You're looking at rate W-24. BAWSCA users seem to pay rate W-25, which is far higher. I don't know exactly what the difference is.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> The paper [https://www.nature.com/articles/s42004-019-0151-2](https://www.nature.com/articles/s42004-019-0151-2)

</comment><comment><USER8> How efficient and robust is the use of a membrane in these kinds of solution? It would seem to me that the membrane is the weakest link, and also expensive.

</comment><comment><USER9> I don't think the problem we should be focusing on is how to remove salt from water, but what to do with the salt after it has been removed.

<comment><USER10> Sell it? Put it back into the ocean?

<comment><USER11> Nobody wants to buy the sludge.

Putting it back would kill ocean life in the area.

<comment><USER10> Just dump it in the great salt lake then

<comment><USER11> uhm, trucking this sludge all the way to Utah seems pretty pointless. Why not just put it in a dump? Why does it need to be put into water?

<comment><USER12> Think of brine as industrial pollution. It wont stay in a dump, it will leak out and poison an area for tens of thousands of years.

<comment><USER11> plenty of industrial pollutants are put into dumps/buried? what do you think we do with them?

From wikipedia

> Other methods [of disposing of brine] include drying in evaporation ponds, > injecting to deep wells, and storing and reusing the brine for irrigation, > de-icing or dust control purposes.</comment></comment></comment></comment></comment></comment></comment>


Tax-Free Storage Wars - <AUTHOR> https://longreads.com/2018/05/29/tax-free-storage-wars/ <comment><USER2> As impressive as digital hackers might be at wielding systems with their mastery over tech dark magic...that pales in comparison to the impact that of the hackers who hack legislation and tax avoidance. I'm constantly astonished (and often saddened) by stories such as these relevant to the 1%-ers.

<comment><USER3> impact is just leverage. Leverage is not just financial.

</comment></comment><comment><USER4> Planet Money did a show about freeports and art storage.

[https://www.npr.org/sections/money/2018/02/09/584555705/epis...](https://www.npr.org/sections/money/2018/02/09/584555705/episode-823-planet- monet)

</comment><comment><USER5> TL;DR: overcomplicated international tax laws lead to deadweight loss for non- productive work in the tax avoidance "industry". Municipalities grant property tax exemptions so that local politicians can hobnob with billionaires.

<comment><USER6> I think your summary misses a main point of this article.

Entrepreneurs set up a very high-security art warehouse in Harlem (New York) with a main selling point that it enjoys a formal exemption from Federal import taxes on fine art. However, no such taxes exist in the U.S. The author believes that the tax exemption provides a kind of cachet for the warehouse even though there is no practical benefit, and that customers may not even realize that they don't get any financial benefit from storing artworks there.

<comment><USER7> Relevant xkcd

[https://xkcd.com/641/](https://xkcd.com/641/)

<comment><USER8> This reminds me of something I read once about pain reliever marketing. 'no other pain reliever acts faster' == 'they all act exactly the same speed'

Lies, damn lies, damn damn lies, and marketing.</comment></comment></comment></comment>


Uber Eats Sticky Header – "Can It Be Done in React Native?" - <AUTHOR> https://www.youtube.com/watch?v=xutPT1oZL2M <comment><USER2> Yes can be</comment>


Did I Discover a Major Hole in the Adblock Plus EasyList Filter? - <AUTHOR> http://www.seolondonsurrey.co.uk/blog/-is-there-a-major-hole-in-the-adblock-plus-easy-list-filter <comment><USER2> It's normal. Some sites can register to AdBlock Plus if they think that theirs ads are "acceptable". It will thus be whitelisted in their database.

If you want to learn more: [https://adblockplus.org/acceptable- ads](https://adblockplus.org/acceptable-ads)

and also some are paying AdBlock Plus: [http://arstechnica.com/business/2015/02/over-300-businesses-...](http://arstechnica.com/business/2015/02/over-300-businesses- now-whitelisted-on-adblock-plus-10-pay-to-play/)

</comment><comment><USER3> What? These ads are on served from the domain, why would they be blocked there?

</comment><comment><USER4> Hardy har har</comment>


The Amish understand a life-changing truth about technology the rest of us don't - <AUTHOR> https://qz.com/1275194/the-amish-understand-a-life-changing-truth-about-technology-the-rest-of-us-dont/ <comment><USER2> >The Amish use us as an experiment. They watch what happens when we adopt new technology, and then decide whether that's something they want to adopt themselves. I asked one Amish person why they didn't use automobiles. He simply smiled and turned to me and said, "Look what they did to your society." And I asked what do you mean? "Well, do you know your neighbor? Do you know the names of your neighbors?" And, at the time, I had to admit to the fact that I didn't. And he pointed out that my ability to simply bypass them with the windows closed meant I didn't have to talk to them. And as a result, I didn't.

I wonder how they feel about online dating.

</comment><comment><USER3> I'd hesitate before taking any moral lessons from the Amish in regards to technology, other than that it's possible and worth it to choose your relationship with it rather than let it control you. But you don't need the Amish to work that out. I wouldn't say they're necessarily better off for what they're doing, and to say otherwise is just idealistic.

They have the same sorts of problems we have, and don't have the ability to tap into the global Internet for insights and solutions. Meanwhile global society continues to evolve as ideas spread ever faster.

There's beauty in that way of life, but much sadness too.

<comment><USER4> You're judging their culture through your moral values.

And "global society continues to evolve" is only true if you believe in "progress".

<comment><USER3> I was careful not to judge their way of life except to state that we shouldn't idealize it. You're the one turning my exhortation into a moral determination.

If you want my moral determination, I would guess that the average Amish person has far superior morals to the average American. If I had to guess how many times the average American Christian has cracked open their Bible, well, let's just say it's not a pretty number.

That said, I wouldn't trade my way of life for theirs, crappy unexamined American morality and all. The Internet just brings more to the table when you get right down to it.

</comment></comment></comment><comment><USER5> It always seems like somewhat of a contradiction but the Amish have a big hand in the American RV industry. They are usually associated with a better quality product.

Newmar with Amish owners makes some of the most technologically packed motor homes with interiors that don't really remind me of the simple Amish life:

[https://www.newmarcorp.com/why-newmar/company- history/missio...](https://www.newmarcorp.com/why-newmar/company- history/mission/)

</comment><comment><USER6> This seems awfully close to the Kevin Kelly interview with Tim Ferriss, including the order the points are raised. I'm surprised he wasn't quoted or at least referenced.

[https://tim.blog/2014/08/29/kevin-kelly/comment- page-2/](https://tim.blog/2014/08/29/kevin-kelly/comment-page-2/)</comment>


Programming as interaction: A new perspective for programming language research - <AUTHOR> http://tomasp.net/blog/2018/programming-interaction/ <comment><USER2> This is not new at all. There have been people studying this (myself only for the last 6 years) for quite some time, generally falling under the field of human-computer interaction. Even in the 70s researchers were studying how people _read_ code.

In fact, there are niche conferences like VL/HCC (human-centric computing), ICPC (program comprehension), and PPIG (psychology of programming) that publish papers in this area each year. Bigger conferences, such as CHI, also publish a handful of papers on novel ways to interact with code each year too.

<comment><USER3> Some specific resources for the interested:

\- Cognitive Dimensions of Notations (Green 1989) [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.128...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.128.270&rep=rep1&type=pdf)

\- Programmers Are Users Too: Human-Centered Methods for Improving Programming Tools (Myers et al. 2016) [http://faculty.washington.edu/ajko/papers/Myers2016Programme...](http://faculty.washington.edu/ajko/papers/Myers2016ProgrammersAreUsers.pdf)

\- Programmer Interrupted (Parnin 2013) [http://blog.ninlabs.com/2013/01/programmer- interrupted/](http://blog.ninlabs.com/2013/01/programmer-interrupted/)

\- Empirical analysis of programming language adoption (Meyerovich and Rabkin 2013) [https://dl.acm.org/citation.cfm?id=2509515](https://dl.acm.org/citation.cfm?id=2509515)

\- Learnable Programming (Victor 2012) [http://worrydream.com/LearnableProgramming/](http://worrydream.com/LearnableProgramming/)

\- Usability of Programming Languages working group at CHI'16 [https://docs.google.com/document/d/1-GUt5oVPpi7rlObbU1WbA5V1...](https://docs.google.com/document/d/1-GUt5oVPpi7rlObbU1WbA5V1OQBX1iaghryLJ6-ND9o/)

<comment><USER2> All great examples! Here are some other great researchers/groups that do research in this area:

\- Brad Myer's Natural Programming Project at CMU (tons of novel tools!): [http://www.cs.cmu.edu/~NatProg/index.html](http://www.cs.cmu.edu/~NatProg/index.html)

\- Andy Ko's work on debugging and learning to code: [http://faculty.washington.edu/ajko/publications](http://faculty.washington.edu/ajko/publications)

\- Emerson Murphy-Hill's work on the usability of dev tools, especially refactoring tools: [https://people.engr.ncsu.edu/ermurph3/pubs.html](https://people.engr.ncsu.edu/ermurph3/pubs.html)

\- Chris Parnin's studies on the cognitive aspects of coding: [http://chrisparnin.me/](http://chrisparnin.me/)

\- Chrsitian Bird's empirical studies of developers: [http://www.cabird.com/wp/publications/](http://www.cabird.com/wp/publications/)

\- Thomas LaToza's work on the collaborative aspects of development: [https://cs.gmu.edu/~tlatoza/papers.html](https://cs.gmu.edu/~tlatoza/papers.html)

\- Bjorn Hartmann's help support in code editors and tutorial generation: [https://people.eecs.berkeley.edu/~bjoern/](https://people.eecs.berkeley.edu/~bjoern/)

\- Philip Guo's tools to support novices with coding: [http://www.pgbovine.net/publications.htm](http://www.pgbovine.net/publications.htm)

\- My dissertation "Human-Centric Tools for Navigating Code": [http://web.eecs.utk.edu/~azh/publications.html](http://web.eecs.utk.edu/~azh/publications.html)

\- Margaret Burnett's work on how people forage for information in code: [http://web.engr.oregonstate.edu/~burnett/reprints.html](http://web.engr.oregonstate.edu/~burnett/reprints.html)

</comment></comment></comment><comment><USER4> Back in 2003 my fundamentals of CS course heavily relied on the interactions window of DrScheme (now DrRacket [https://racket-lang.org/](https://racket- lang.org/)). It was a extremely powerful educational tool. When I started doing web development I found myself frequently putting snippets like `javascript:alert('abc'.substr(1)` into the URL bar. With the advent of the Firebug console it became even easier to try out new snippets. Now a days the Chrome console tab even has autocomplete. I'd be interested to know how these simple interactions contributed to the widespread adoption of JS and other languages.

<comment><USER5> Better completion usually makes me more productive no matter how crap the language is. Looking at you Java with your ginormous standard library with poor docs, and poor completion in eclipse.

</comment></comment><comment><USER6> I always use a debugger, primarily to catch bugs, but I'm also realizing that because of that process, the debugger is a learning tool.

If I'd teach programming education, I'd teach them a language with great debugger support and preferably also support to single step through the machine language as well.

I suppose C is a good language for that. I wish JavaScript would show it's underlying machine code that you could single step through.

</comment><comment><USER7> Sounds interesting from a practical side people might be worried that this info will be immediately streamed into some system used to derive some meaningless KPIs.</comment>


Show HN: Online resume builder with view/download analytics - <AUTHOR> https://standardresume.co <comment><AUTHOR> Hi HN!

After launching Standard Resume almost 2 years ago, it's still the best place to create simple, beautiful, and professional resumes. You don't have to waste time with templates or layouts, just focus on what matters, your content.

With Standard Resume Pro, we've made it easy for you to create and tailor multiple resumes for different applications. You can also track how your resumes do over time, see how many people view them and from where.

Check it out and let us know what you think!</comment>


Ask HN: What are the big differences working at a startup, bigco, old smallco? - <AUTHOR> <comment><USER2> BigCo:

-Better pay, benefits, stock options

-More organized in all regards (sprints, HR, ramp up, training, etc.)

-More "name recognition" e.g. when you tell people where you work, they immediately know/are familiar with the company

-Hours will usually be between 40-60 per week

-Not often mentioned, but with so many people, you're more likely to make "work friends"

-Siloed into your specific role - if there's a new technology or idea you want to implement, there's usually a few levels of approvals you need to go through

-Can feel like you're just a small cog in a big machine

Startup (not "established startup" e.g. multiple rounds of funding):

-Immediate impact -- you're usually defining the direction of whatever you're working on

-You get a chance to "wear many hats" i.e. work on various different projects/tasks

-If there's any equity/options, there's a possibility these become lucrative (although I would assume this is unlikely)

-Usually your hours are more flexible

-Can get "lonely" if the team is small

-Pay is usually below market or if you're a founder...nonexistent

-Can have long hours e.g. 80 hour weeks

SmallCo:

The middle ground of the two. Almost all the pros and cons of the above, but just not as extreme. For example, HR is usually more organized than a startup, but not as organized as a BigCo. Or, you have more of an impact on the product than at a BigCo, but less than at a startup.

<comment><USER3> Slightly off-topic, but I can't believe the long hours you guys in the USA work as standard. In the UK, most jobs these days are 37.5 hours. Only a few do 40.

Of course there may be (rare) occasions where you need to work overtime, but 40-60 hours on a regular basis seems crazy. 80 hours is insane. People here simply wouldn't do it. I doubt anyone gets any more productive beyond around 30 hours a week.

<comment><USER4> Keep in mind that hours don't necessarily translate to productivity.

But yes, Americans work a lot of hours, and in the white collar professions this is especially the cultural norm. Living at the office or being tied to one's computer at home 24/7 (or both) are pretty typical.

<comment><USER5> Does this require a stay-at-home partner? I don't know how I would ever be able to handle my daily life, stuff like cooking, laundry, sleeping, errands, going to the hairdresser, working out, hanging out with my partner... and I didn't even mention the kids!

<comment><USER4> It generally does. The exception would be very well-compensated people in the corporate world who can afford au pairs and nannies, and, effectively, the modern equivalent of household servants. This is how the Sheryl Sandbergs of the world "lean in" and "do it all" — lots and lots of hired help. There is no other way.

I am not rich, and I ended up the single dad of a two year-old recently. So I am still trying to figure that puzzle for myself. Fortunately, I do have the flexibility of being self-employed, but on the other hand, if I don't work (long hours), neither I nor my son will have much to live on.

</comment></comment></comment></comment></comment><comment><USER6> One of the big differences is generalization vs specialization.

If you're at a big company, odds are there is someone for every task that needs to be done. It's not just that someone can pick it up but I mean it's a part of their job description. If you're looking for mentorship from a specialist, it's great.

At a smaller company, the same tasks have to be done but odds are whoever is available with some basic aptitude (or willingness to learn) can pick it up. You'll end up with a broader range of experience. If you demonstrate skill (or at least competence+enthusiasm), you're likely to do it again because most likely it needs to be done.

<comment><USER7> Went from a 120,000 person company to a 12 person company and this is so true.

If you've got great leadership, a small company can be an incredibly fun, almost artistic like experience to work at. A

That being said I really enjoyed my time at Bigco. It teaches you a ton about bureaucracy, the inevitable issues large groups of humans has, there is a built in social network, lots of legal protections, etc.

<comment><USER8> There's a good line in "Accidental Empires" about how, in large companies, appearances and ability to work within the system are more important than actual ability with regard to advancement. In startups, _there is no system_ , which is what makes it "so damn fun." I think that's right, but the flip side is that a big sturdy business has theoretically figured out an angle that they can exploit into the ground in the market, and you can learn a ton by seeing how they do that, how various subgroups within the company navigate the larger system, et al. So both definitely have their benefits from an educational perspective, although I definitely think smaller in general tends to be more fun because of how much you can shape your surroundings and see immediate feedback in changes to the system. But fun isn't necessarily the most important thing always.

<comment><USER9> It is my opinion that Cringeley is a fraud. He did a kickstarter and completely failed to deliver.

Separately if you live your life in service to a bohemeth, learning nonreproducible skills in maneuvering their bureaucracy you are likely to have a miserable pointless career.

There's so much more actual learning and effective transferable skill and power in working to achieve things versus serving an internal bureaucracy that rent seeks.

I'm reminded of the John Boyd line: "Do you want to be somebody, or do something?" Winning the respect of your incestuous peers is hollow outside in the real World if you don't actually deliver real effective results. But so many of these B-Ark people do so well at big companies with minimal actual Skills other than sucking up and dodging blame.

<comment><USER8> I don't have strong feelings about Cringley. He admits in the book he basically wrote an industry gossip mag, so I took the whole thing with a grain of salt and just tried to enjoy it.

That said, I think your other comments are correct but somewhat miss the point. Certain types of work you can pretty much only be exposed to within a large company that can muster the required volume of funds / expertise / reputation. And learning to corral diverse groups of people with competing needs and priorities is pretty much the definition of a transferrable skill.

One example from my own life: I've bounced around financial institutions (mostly banks and credit card companies) for the last several years. To continue building the skills I'm interested in, I need a better understanding of the internals of big banks. It's simply much more difficult for me to try to learn those things in a small company or startup, unless I can get one of the few spots available in a company like Monzo, which would require me to not only get the position but move away from my friends / family / etc. (And then I'm still looking at a small company's new vision of how a thing should work rather than seeing how it actually works in most situations today.) There are always tradeoffs, and sometimes a big company will have positions that are better suited to your current goals.

</comment></comment></comment></comment></comment><comment><USER10> A lot of great answers!

Don't forget the majority of bigcos are not software companies. These are companies like Ford, GM, Coca-Cola, Proctor and Gamble, etc. Basically, these companies use software as part of their business, but are not fundamentally software companies.

The worst jobs I've ever had was being a software person in one of these non- software companies. Few of the positives (e.g. having a great set of great senior software people and practices to learn from) existed, but certainly all of the negatives did. At one of them (I didn't last long there) there was constant talk of us "Being agile like startups" which meant that people did a lot of useless work just so Directors with minimal/no software background could generate 100s of slides to demonstrate how agile and entrepreneurial their groups were.

If you want to work in software and want the positives of a bigco, work for a bigco software company. If not in a software company, in the technology org of a bicgo that actually sees software as a core strength and not just a cost center or value-add.

<comment><USER4> Very good points!

In addition to that, there is a third species of company that seems to be especially common in my industry (telecom): the nominal tech company. This is a company whose business model theoretically makes big engineering demands; it may not be a software company per se, but operating and gluing together tech is unquestionably the core mission behind its products and services. Yet, instead it's an overwhelmingly sales-driven company that mostly just pays lip service to engineering.

This type of company is insidiously bad for an engineering career because it has the outward appearance of being tech-focused. It's only with time that you realise that 80% of the staff hold management titles and do little but parry e-mail and hold meetings, that there are 20 VPs (in a company of a few hundred or a few thousand) who are usually on golf junkets, and the agenda is set mostly by blinged-out, testosterone-amped sales execs and the MBA frat boys who supposedly run sophisticated development and infrastructure groups. A tell-tale sign of such companies is that underneath ten layers of "management", you'll find three H1-Bs stuck somewhere in the back, sharing a cube, who are the only ones in the company who actually know anything about the technology. They are critical to the company, but because of their indentured H1-B status, the company is equally critical to them.

In the short term, working for such companies can be really cool. They usually have severe problems retaining serious engineering talent, so if you walk in there with substantial skills, they'll think you walk on water when you bang out a few lines of Bash or Python for basic housekeeping tasks. But you'll soon notice very high churn, or, at the other extreme, lots of people who have been there 10-20 years and have become deeply entrenched maintenance specialists in the company's internal systems and processes. This looks like tech work to them and others, but robs them of portable marketable skills. The moment they are laid off, they'll find that the world has moved on and that they have vanishingly little to offer other employers.

</comment></comment><comment><USER11> Can we get "Ask HN" prepended to this? I was completely confused when this headline didn't navigate to a blog post.

</comment><comment><USER12> I'm going to frame this a little different... More as the difference between a high growth startup, a big public company, and a small stable company.

The large public company aims for predictability. They thrive based on economies of scale, which are achieved through standards. They work a lot on systems. Decisions frequently seem irrational, because things that look good in a unit get sacrificed for the benefit of the whole. Depending on the company, compensation can be better. Benefits usually are. (Google outpays YC, but Walmart may not outpay a small retailer) There is a long gap between idea and impact, but the impact can be huge. (One person can help a big company cut $20mm in costs - if the PE is 20, that's $400mm in enterprise value) But you may spend months fighting petty battles. Bigger companies tend to be more cost focused. Hours tend to be more predictable. If you're a superstar, you can usually stay employed even if there are ups and downs. (Big companies have layoffs, but the top 10% can usually find work elsewhere inside)

In high growth startups you have a lot of autonomy to make decisions. The distance between idea and implementation is very small. The energy and urgency is much higher, even on things that may seem small. Compensation is much more equity based. Hours are much less predictable. You can do a fantastic job and still get fired if the company implodes.

Small stable companies are usually family businesses, and frequently run as such. You get treated well by the owners, but you'll never be one of them. Benefits can be good, though overall comp will not be outstanding. They can be very friendly places to work, where everyone knows everyone.

</comment><comment><USER13> My recommendation is to do both in your career. Working at a big company can teach you how to work with a lot of stakeholders, big teams, management and often working with mature stuff. It comes often at the price of bureaucracy and a "can't do" attitude. You may also feel underchallenged. In a small company you learn how do things in a more direct way and often have more flexibility.

Both are good things to experience.

<comment><USER14> Exactly my experience after working several years for many big corporations and startups. I would add that might expect much worst work-life balance as a foreign developer working for an american startup.

</comment></comment><comment><USER15> bigco - There's going to be a fair amount of project management and process (which is absolutely needed). Part of the learning curve will be learning how to effectively work across teams/departments. Also you will probably see a reorg/layoff at some point. It won't be as bad as you imagine. Expect at least some training and formal learning opportunities.

old smallco/startup - Can be very ad-hoc. Someone needs a new computer? Run to the store. Some things you might expect may be missing such as HR or tech support. You may not receive much if any training.

startup - Generally longer hours, generally exciting as you're creating something new. product, client launches.

</comment><comment><USER16> My previous job was at a company that fluctuated between 15-25 people, not exactly a startup so you can call it "old smallco". My current job is at a company of 4-5 thousand with multiple offices in different countries. My experience is as follows

Pros of "smallco":

\- Felt like a family business, friendly atmosphere, great relationship with everyone

\- You get to do things outside your job spec and consequently acquire a broad range of skills

\- Design freedom, your input is never dismissed/ignored

\- "Vertical" knowledge of the product (design, manufacturing, testing), familiarity with every component even if completely unrelated to your skills

\- Virtually no bureaucracy, very small time-to-fix (from identifying a problem to deploying the fix)

\- Never boring

Cons:

\- Job insecurity. The company can basically go under any day

\- Salary is not amazing, raises are infrequent and small

\- At some point you are basically the expert in your domain. This means there's none more experienced than you to teach you new things or give you some great insight

\- No rigorous process, minimal documentation, you basically end up hacking together stuff as you go

Pros of bigger company:

\- Higher job security, better salary, benefits and career opportunities

\- Better process, your work is more organized

\- Plenty of people around you that can help you learn and advance your skills

Cons:

\- Little freedom to design, you need to stay in your "lane", improvisation is a no-no. This is not bad per se, it's just not as exciting

\- Months go by and you still don't know 1/4 of the people on your floor. Relationships are more formal

\- Bureaucracy is sometimes infuriating. Need another chair? send an e-mail to the correct department, wait a day or two. Need to use your favorite text editor instead of the company standard? You need approval from your manager.

Never worked in a behemoth like google, ms, intel,etc. but I expect the pros/cons to be even more accentuated.

</comment><comment><USER17> Big companies are a safer bet. The company should be around in a few years, they have established best practices, good compensation, normal hours (~40/week). Even if one later deiced to work at a small company, it helps to have gained the experience and credential of working at the big company first.

</comment><comment><USER18> Other comments have good observations about big vs small.

One of the main markers of a startup is there tends to be One Big Challenge to get the company to The Next Level (generally talked about as a funding round, but that's just a convenience). Initially you're finding product / market fit, then you're figuring out a scalable go-to-market, then you're scaling the product, then you're launching a new product, etc.

It's weird to go through one of these transitions, because you'll need to change your focus pretty drastically. Sometimes you'll feel sidelined, because your department isn't the one primarily on the hook. If you're figuring out how to build a sales team, engineering gets chill and potentially complacent. The most successful startups have leaders that paint a clear picture that gets all departments working autonomously towards the same goal.

This is different than a smallco, because without a war chest of cash, your options are more limited. Because cash flow dictates the cadence of the business, and that's never going to change. This can feel more stable, but does mean you'll have to occasionally make hard choices that delay a valuable project or work on something outside your speciality.

</comment><comment><USER19> If in Smallco or startco, you have toxic co-workers you have toxic or politically aggressive co-workers, you'd better be very savvy on how to deal with them because you can't avoid them. In bigco, it's easier to isolate yourself from politics because you may have co-workers who are more willing to deal with them so you don't have to.

</comment><comment><USER20> Here are some thoughts I wrote up recently comparing my previous work at Google to my current role at YC, written from the perspective of an individual-contributor software developer: [https://corbt.com/posts/2017/10/28/small-companies-and- the-p...](https://corbt.com/posts/2017/10/28/small-companies-and-the- presumption-of-competence.html)

Both workplaces are great, and while I'm personally happier at YC I could see the decision going the other way for somebody with different preferences.

</comment><comment><USER21> Generalized personal observations: Stability: startup, small company, bigco Pay:smallco,startup,bigco Personal growth: bigco,smallco,startup Technical growth:bigco,smallco,startup Hassle:bigco,smallco,startup

</comment><comment><USER22> Piling on...

BigCo: constant criticism and "evaluation" of your performance. Emphasis on meeting whatever deadline was decided internally. Lots of people on your project who you don't know what they do.

<comment><USER10> >Emphasis on meeting whatever deadline was decided internally. Lots of people on your project who you don't know what they do.

The most important defense against this is your manager, who can keep your team away from projects with nonsense deadlines and goals. That's why, when you take any job, you need a good manager and hopefully your manager's manager is good as well. Otherwise all the foolishness from above will roll down to you.

If the entire division is full of these kind of nonsense projects, chances are the good managers will leave. Don't work at these places unless you have no choice.

</comment></comment><comment><USER23> Here's something I've noticed when working at a big company. It's extremely easy to get vendors talking to you. They will always call you back. It's actually kind of a big deal, if solutions from third parties can offer significant benefits to what you're working on and you have budget to spend.

The flip side is that they always call you. You can't stop them calling you, even after you've told them multiple times you're interested.

</comment><comment><USER24> I think this is an artificial separation. There are only 2 kind of companies - those which make money and those which don't. For real experience , imho, I would suggest to work for the 1st.

<comment><USER25> I think you're misunderstanding the question. This is like someone asked what is the difference between beer, wine, and hard alcohol and your reply is "there are only two kinds of drinks: those that get you drunk and those that don't". Duh. They want to know more about the experience of the types, not to be dismissed.

<comment><USER24> My point is, using your analogy, you can get drunk with all 3, but what matters is people you are drinking with.

</comment></comment></comment><comment><USER26> Over 20 years in the workforce, here's my notions from working for:

3 big-corps (over 30,000 employees each)

\- Huge well organized career ladder

\- lots of corporate resources for growing a career

\- more possible to change jobs without changing companies, usually through changes in divisions

\- good places to move up title-wise between smaller companies

\- work tends to be more specialized, you'll end up doing really only one kind of work and if you want to do something else you need to change jobs internally

\- less flexibility and personal touches

\- benefits are usually pretty good

\- you will be not much more than a number to the higher organizational units in the company

\- can get you positioned to work on hugely impactful work that will affect millions of people

\- time to impact can be very long...

\- tend to be very bottom-line focused and conservative

\- lots of processes and procedures

\- as a performer, lower stress, as you move up management ranks gets medium stressed

\- may be a dozen or more layers between the lowest employee and the CEO

\- hiring and recruiting is a well oiled machine

\- these companies decide where they want to be and simply put muscle behind to make it happen

1 med-corp (< 2,000 employees)

\- definitely some aspects of working for a big-corp, mostly bureaucratic nonsense

\- they're trying _really_ hard to become a big-co so more flexibility and risk taking is possible

\- jobs tend to be less specialized in some cases

\- less opportunity to move around, but you'll also find that these are the places with 20+ year employees

\- tend to have better benefits in order to attract talent from big-co, but can't always match on pay (often in denial about the state of the market)

\- feels like several small-corps (~100) in practice due to divisional structure, even the lowest employee is only 5-6 steps from the CEO

\- most tasks are 1-5 people deep, so if one person isn't good, they can usually scrounge up another person who can take it on

\- recruiting is functional, but thin

\- growth desires can sometimes get in the way of sustaining operations

1 small-corp (~100)

\- I didn't actually have a good experience at this place, so I may be colored by it

\- there's often more people available to take on specialized tasks, but still lots of multi-hat wearing

\- most tasks are 1 person deep, so if they aren't good, the entire company feels it and grinds to a halt

\- very easy to get overwhelmed picking up slack for less capable staff

\- everybody knows everybody

\- organizational "feel" will be deeply linked to the personality of the C-level execs, they'll know you by name and have a reputation for you in their mind

\- a good size to put behind one major product push, or 5-6 small ones, but might be too few people to handle

\- are often in the middle of huge growth which means everything is in chaos

6 tiny-cos (<20 staff)

\- imagine every kind of job there is, welcome to doing all of them, often at once

\- in terms of professional capacity, I grew the most in these kind of companies (while career titles grew the most in big-corps)

\- if you have a good team, can be extremely rewarding

\- better than 90% chance that things will go bust and you'll experience hours and stress unlike anything you can imagine

\- everybody is customer support and sales

\- absolutely no room not to pull your own weight

\- company direction is dictated almost entirely by the capabilities of just a handful of core people...who may not even be the C-levels or founders

\- work should be very focused on getting an MVP out the door and getting initial customers, then moving up to the next size

\- often are getting ready to grow very fast which can be very tough

\- everything is always in chaos, but you have huge impact on the company almost every day

\- I love working in these places, but can't do them back to back, the stress is crippling

<comment><USER10> >feels like several small-corps (~100) in practice due to divisional structure, even the lowest employee is only 5-6 steps from the CEO.

I worked for a med-corp (~3000 people) that was like this because they had spent 10 years growing by acquiring other companies, but had done a poor job of really integrating all these disparate products/teams.

One of the best parts of that job was that every org was very different. Some were legacy products that ran on maintenance revenue and technical support. Others were fast paced and were focused on the product/engineering team improving the product. Some orgs had "hero" culture where people would rather put out a fire than prevent it.

I met lots of different people, got to see and work with a lot of different perspectives, and learned a lot. As you said, there were plenty of great people with 10+ years of experience who were 10X multipliers on my own education.

The company eventually paid for their inability to integrate these products and teams by getting acquired by a private equity firm. It was fun while it lasted!

</comment></comment><comment><USER27> I'm not exactly a prolific poster, but if you look at my post history, you can probably get some additional insight on the BigCo situation especially non- tech. One thing I'd like to talk about is the bureaucracy in big companies, which is often criticized but actually has some rationality to it:

To some, the bureaucracy seems like a byzantine game with unwritten rules designed to have you fail, but it's actually a lot simpler and far less nefarious than that. What it really comes down to is that BigCo has a lot of leaders aligned across a lot of functions, and getting large, impactful things that HN-types like to do will generally require buy-in across multiple leaders and their managers. You have to get good at building consensus to get buy-in, and that means thinking very hard about your ideas and the value proposition to the organization as a whole, but then also to the individual stakeholders. Critical thinking and analytic skills are very important for sure, but you need some measure of emotional intelligence and soft skills to see things through. This still matters in a smaller org, but bigger companies tend to get proportionately more top-heavy, and that means more people to influence to get a big idea through.

I've said this on HN before, that it's been my experience that startups and smaller companies take a dim view of big company talent. I'd challenge that, as people who have been successful in getting big things done in a big company likely had to overcome a lot to do it, and that's a set of skills you want as you start to grow and scale.

With all of that said, I'm leaving my management post with a BigCo at the end of this month to join an established startup, hopefully to help them scale the sorts of processes that I'm good at - and is probably at best a lateral in terms of my current level. I've always wanted to try it, and I figure in my mid 30's it's now or never, and somehow I've convinced my family that we should go 2500 miles west to the Bay Area to do it. This isn't to say one is better than the other, but I'm absolutely certain that the variety of experience will make me a better leader going forward. Some of the best advice I ever heard (from a former CFO and current board member of a BigCo), which I will pass on here, is to take advantage of opportunities that will broaden your horizons and make you an overall better leader - even if that opportunity might not have the same "prestige" in its level, job title or brand recognition. There's a lot of competition as we progress in our careers, and sometimes being that person who has "done that" versus some vague exposure in a prior management rotation, will get you ahead. Try on a few different hats, see what fits.

</comment><comment><USER28> From the personal growth perspective;

Bigco can mean being constantly surrounded by experts and having to compete with more experienced coworkers to get the fun projects or extra responsibility that make a job rewarding. It can also mean lots of easy learning from well experienced coworkers.

Smallco can mean less expert coworkers to learn from but lots of room to grow and lots of experience gained from extra responsibility.</comment>


Branding for Startups – Don't forget how people perceive you before - <AUTHOR> https://medium.com/@danielkempe/branding-for-startups-dd724f2ac43a

<comment><AUTHOR> A little article I wrote about branding your startup. Thanks for reading :-)</comment>