Detecting Android malware by building Markov chains of behavioral models - <AUTHOR> https://www.benthamsgaze.org/2017/03/28/mamadroid-detecting-android-malware-by-building-markov-chains-of-behavioral-models/ <comment><USER2> Wondering if this has anything to do with: [https://arstechnica.co.uk/security/2017/01/virulent- android-...](https://arstechnica.co.uk/security/2017/01/virulent-android- malware-returns-gets-2-million-downloads-on-google-play/)

</comment><comment><USER3> Morning paper also covered this nicely here: [https://blog.acolyer.org/2017/03/09/mamadroid-detecting- andr...](https://blog.acolyer.org/2017/03/09/mamadroid-detecting-android- malware-by-building-markov-chains-of-behavorial-models/)

Love that blog!</comment>


Show HN: How to gain observability across Kafka topics and Elasticsearch - <AUTHOR> https://lenses.io/blog/2020/04/how-to-explore-data-in-kafka-topic-and-elasticsearch-with-sql/ <comment><USER2> Is this using elastic's SQL underneath?

</comment><comment><USER3> Interesting new feature!</comment>


Ask HN: Interesting things to do with old smartphones? - <AUTHOR>

I now have two old Android phones and am looking for ideas of something interesting to do with them. I've had old phones before, but without wifi they've been limited to just games, playing music, or reading ebooks. Now with wifi and some power, there are surely some more interesting things to use them for.<p>So far the best I've come up with is using them as wireless webcams using IP Webcam. They could also be alarm clocks or be used for streaming music or news. But what else? <comment><USER2> Ideas I've had:

-Dedicated bicycle speedometer/route tracking computer (if it has GPS)

-Remote for my music server

-Timelapse camera

-GPS tracking device/bug

-Sleep analyzing alarm clock (if it has accelerometer)

-Media player (obvious)

-Donate to developers to facilitate porting newer releases/ROMS to older devices

-Networked motion sensor alarm? (I assume an app for this exists)

I'm sure there's more I've thought of at one time or another, if I remember, maybe I'll edit and add them here.

EDIT: Also, the Android Open Accesory Development Board[1] would allow you to branch out of what the phone itself is capable of and work with external devices via the USB port. Perhaps robots, for one idea?

[1]<http://developer.android.com/guide/topics/usb/adk.html>

<comment><AUTHOR> I like the idea of putting it on a bot. I was thinking to just use it as a wireless camera there, but with the ADK the phone could drive or even run some lighter computer vision code.</comment></comment>


Bootstrapping a Forth in 40 lines of Lua code (2008) - <AUTHOR> http://angg.twu.net/miniforth-article.html <comment><USER2> If you want to understand Forth, I recommend this article:

A sometimes minimal FORTH compiler and tutorial for Linux / i386 systems by Richard W.M. Jones

"LISP is the ultimate high-level language, and features from LISP are being added every decade to the more common languages. But FORTH is in some ways the ultimate in low level programming. Out of the box it lacks features like dynamic memory management and even strings. In fact, at its primitive level it lacks even basic concepts like IF-statements and loops.

Why then would you want to learn FORTH? There are several very good reasons. First and foremost, FORTH is minimal. You really can write a complete FORTH in, say, 2000 lines of code. I don't just mean a FORTH program, I mean a complete FORTH operating system, environment and language. You could boot such a FORTH on a bare PC and it would come up with a prompt where you could start doing useful work. (...)

Secondly FORTH has a peculiar bootstrapping property. By that I mean that after writing a little bit of assembly to talk to the hardware and implement a few primitives, all the rest of the language and compiler is written in FORTH itself. Remember I said before that FORTH lacked IF-statements and loops? Well of course it doesn't really because such a lanuage would be useless, but my point was rather that IF-statements and loops are written in FORTH itself."

[https://github.com/nornagon/jonesforth/blob/master/jonesfort...](https://github.com/nornagon/jonesforth/blob/master/jonesforth.S)

<comment><USER3> Agreed; also, this book is golden: Threaded Interpretive Languages (R. G. Loeliger)

<comment><USER4> Since it seems to be out of print, and on the internet archive I'll drop this:

[0] [https://archive.org/stream/R.G.LoeligerThreadedInterpretiveL...](https://archive.org/stream/R.G.LoeligerThreadedInterpretiveLanguagesTheirDesignAndImplementationByteBooks1981)

</comment></comment></comment><comment><USER5> I've been in a "retro computing" deep dive lately and it's been fascinating to discover Forth. I was surprised that an entirely novel paradigm was hidden despite much digging over many years. All of the sudden I am seeing it everywhere now too - confirmation bias from growing up skill wise in the age of dot com boom vs right before?

I like the feeling of concatenative languages. I especially seem to like the postfix notation over prefix and largely this creates the paradigm of lisp vs forth at first step - in my opinion.

I've recently dug in to Factor and it's quite an amazing piece of art that is highly usable and up to date despite such a small community. It almost feels like a secret weapon and too good to be true. I'm having a ton of fun hacking on it. It's like Smalltalk and forth had a baby.

I dream of making an OS with Forth/Factor similar to Plan9 and Oberon.

I get a kick out of Forth being made of words and Genesis from the Bible.

At first was the Word, and the Word was with Forth, and the Word was Forth.

[https://factorcode.org/](https://factorcode.org/)

[https://en.wikipedia.org/wiki/Oberon_(operating_system)](https://en.wikipedia.org/wiki/Oberon_\(operating_system\))

Tidbit if anyone cares: I've been obsessing over returning to first principles of computing. I'm bored of the internet and browsers. I want to have fun with software AND hardware and Forth seems like such a perfect language to do exactly that with. Factor is a nice grown up example of that but it's definitely a few steps removed from portability and self bootstrapping behavior like in CollapseOS.

Retro Forth is extremely impressive: [http://forth.works](http://forth.works)

<comment><USER6> Note to Oberon, don't focus on version 1 alone.

Oberon System 3 with its gadgets framework or the current AOS (still used as teaching tool at ETHZ) also have interesting ideas, and better support for systems programming.

The book "The Oberon Companion. A Guide to Using and Programming Oberon System 3" is available as part of the System 3 environment delivered as part of AOS.

[http://cas.inf.ethz.ch/news/2](http://cas.inf.ethz.ch/news/2)

[http://builds.cas.inf.ethz.ch/](http://builds.cas.inf.ethz.ch/)

You can find some old ISOs from here [https://github.com/cubranic/oberon-a2](https://github.com/cubranic/oberon-a2)

<comment><USER5> Thank you. I'm incredibly interested in the UX paradigms demonstrated within Oberon. I'd like to play with that and get some inspiration for a few ideas I've been mulling about. Thanks!

<comment><USER6> See my blog article over Oberon, you will find screenshots for AOS.

Also have a look at Mesa/Cedar, as it was the inspiration for Oberon ideas.

[https://news.ycombinator.com/item?id=24450970](https://news.ycombinator.com/item?id=24450970)

Comments include a link to one hour demo on YouTube with members of the team.

As idea, many of these concepts can be done on modern OSes, on top of something like COM/D-BUS/gRPC/XPC, but none of them go as far as they did.

</comment></comment></comment></comment><comment><USER7> In the 1980s there was a home computer, the Jupiter Ace, that used Forth rather than Basic:

[https://en.wikipedia.org/wiki/Jupiter_Ace](https://en.wikipedia.org/wiki/Jupiter_Ace)

Edit: I never used one (or indeed ever saw one) but for some reason reading about Forth at the time gave me a lingering fascination with Forth type languages - which was useful when I worked on a project for a few years that used PostScript, C & Lisp ...

<comment><USER8> Forth was available for the Acorn Atom (early 80s). Sadly, didn't have the money or time to go down that route then. Had fun with its Basic though...

<comment><USER9> I had the Forth for the Acorn Atom. It was great, a real mind-opener. Still have it in a box upstairs!

</comment></comment></comment><comment><USER10> Something I like about this article is how it helps reveal what Forth's essence is:

Forth is an extensible virtual machine

Most interpreted languages that are implemented with a virtual machine (sometimes known as a bytecode interpreter) have a fixed set of instructions. Modulo some implementation details, writing new Forth words is akin to extending the virtual machine with new instructions.

However, the article's Forth is a more extensible form of this. The entire evaluation of the virtual machine is split into an extensible set of states (starting with only interpret, compile, head, forth, lit), new types of instructions can be introduced by adding to a list of heads (starting with only DOCOL and EXIT), and then words are, specifically, lists of addresses that the forth state interprets, whose evaluation is triggered by a DOCOL seen in the head state.

This opens up possibilities to define other sorts of interpreters for specific purposes. The article gives the example of polynomial evaluation, but you could also do something like have a variant of the forth state for token threaded code in memory-constrained environments. Sort of like how ARM has an additional Thumb instruction set.

More detail for this last idea: you'd have an array of, say, 256 pointers, and in the bforth state you'd read the next byte of the thread, look up the address in the table, push it on the RS, then go into the head state. This gives you perfect interoperability. You'd just need a special bcompiler state that would look up the bytecode for each word.

<comment><USER11> > an extensible virtual machine

I've read similar ideas on Lisp. I don't put much stock in it in either context, but I think Lisp has a better claim to extensibility. All programming languages enable decomposition of a program. Functions/methods/macros/words don't really 'extend' a language.

You can't easily add garbage collection to Forth. You can't easily add static type-checking to Forth. Why call it 'extensible'? It's no more extensible than C.

It may be easier to hack on a Forth implementation than a C compiler, sure.

<comment><USER12> > Why call it 'extensible'? It's no more extensible than C.

Extensibility refers to the ability to extend the compiler directly in the language. Lisp supports this with macros, which are not functions and are different than macros in C because they alter the behavior of the compiler, and Forth supports this with defining words and compiling words, which behave differently from other forth words because they alter the behavior of the compiler. Compare this to a macro in C, which pre-processes the macro into more C prior to compilation rather than at the time of compilation. In this respect, both Forth and Lisp are more extensible than C because facilities to extend the language exist within the language itself.

<comment><USER11> I think I follow, but it seems rather fuzzy. Compile-time functionality doesn't strike me as really extending the language.

How about _BOOST_SCOPE_EXIT_ in C++? [0] Is it extending the language, or just a trivial macro-based hack on RAII? What's the difference?

My other issue with it is that the major features of programming languages that people actually care about, aren't the kinds of things you can implement with clever macros. They tend to rely on serious engineering.

Even in a highly extensible language, you can't easily throw together features like industry-strength garbage collection, or a type system, or borrower- checking. (I considered listing formal verification but that would be unfair, it can't really be added to an existing language.) These things are implemented by compiler engineers, and always will be. (If I'm mistaken about that, and am underestimating anything, I'd be interested to know, but I don't think I am.)

What's the 'killer example' of LISP macros? I can see a pretty neat example at [1].

[0] [https://www.boost.org/doc/libs/release/libs/scope_exit/doc/h...](https://www.boost.org/doc/libs/release/libs/scope_exit/doc/html/BOOST_SCOPE_EXIT.html)

[1] [https://docs.racket-lang.org/guide/pattern- macros.html#%28pa...](https://docs.racket-lang.org/guide/pattern- macros.html#%28part._pattern-macro-example%29)

<comment><USER10> You can add garbage collection to Forth, but for the trivial reason that Forth is a low-level virtual machine to which you can add instructions/words for managed objects, and then you can add some words to help you interact with them more ergonomically -- words that run at compile time to change how code is being compiled. I don't think it's right to think of Forth as a "language" per se, although it's true there is a certain language that Forth programs tend to be written in, the one people call reverse-polish and concatenative.

I can't say anything about adding a type system, because it's unclear what sort of type system would even apply here. But at least in Common Lisp (which incidentally already has a type system), I think the way you'd do it is create your own front-end that interprets and checks all the typing/borrowing information and then passes this to the usual compiler. There's a long tradition in Lisps to define interpreters that extend the base language in some way.

SBCL even lets you hook into the compiler, and I saw some article about someone adding vectorization to SBCL using only user-level code.

Regarding BOOST_SCOPE_EXIT, it's yes or no depending on what extending the language means to you. I think it's more useful to use a definition where the answer is 'yes.' It's true that C macros are not a very powerful interface for language extension, though.

Also, it seems like you're saying that "extensible" means "easily extended" or "doesn't take serious engineering." It just means you can extend it (and, I'd add, in a principled way). Writing good Lisp macros can take serious engineering, but also there are other ways to extend Lisp.

In Lisp, you can (and do) define pattern match destructuring and lvalue assignments entirely using macros. These are features that require a new edition of a language standard, usually.

<comment><USER11> > You can add garbage collection to Forth

Sure, but to do this properly you'd need to get your hands dirty with the implementation. Garbage collection doesn't work well as a bolted-on library, it needs to be handled in the language implementation. Forth is no different from any other language in that regard.

> I can't say anything about adding a type system, because it's unclear what > sort of type system would even apply here.

It's directly analogous to static type-checking in a 'normal' programming- language, except we use the stack for accepting parameters and for returning values.

It would ensure each word manipulates the stack in the expected way, ensuring that the appropriate number of elements are consumed and pushed, and that each element is treated as being the correct kind of data (type-checking should fail if you attempt to dereference an integer).

This has been done in the _Kitten_ programming language. [0] Java bytecode verifiers do something similar.

> SBCL even lets you hook into the compiler, and I saw some article about > someone adding vectorization to SBCL using only user-level code.

Neat. I like the idea of advanced optimisations as libraries, sounds like a good research topic.

> it seems like you're saying that "extensible" means "easily extended" or > "doesn't take serious engineering." It just means you can extend it (and, > I'd add, in a principled way)

Perhaps I seem dismissive, but it just doesn't seem to me like many serious language features can be done properly in extensible languages.

The latest major features in mainstream programming languages are await/async and borrower-checking. I imagine it might be possible to implement await/async using Lisp macros, but I really doubt the same goes for borrower-checking.

> In Lisp, you can (and do) define pattern match destructuring and lvalue > assignments entirely using macros.

That's pretty impressive, but it still seems that there are plenty of useful language-extensions that can't practically be implemented in extensible languages.

[0] [https://kittenlang.org/](https://kittenlang.org/)

<comment><USER10> You seem to be thinking about Forth-the-language, and I've tried to be clear that Forth is referring to a way of programming where you extend the machine, which seems to be what Chuck Moore has meant by Forth. Your program _is_ a language implementation, defining a language in which you can describe the program in the best way. There is no avoiding getting your hands dirty with the implementation. No abstraction layers between your program and the machine.

You can add garbage collection because the Forth program is a language implementation. It probably won't look exactly like ANSI Forth in the end, but that's (theoretically though potentially not in practice) ok.

> It's directly analogous to static type-checking in a 'normal' programming- > language, except we use the stack for accepting parameters and for returning > values.

I'm familiar with type systems for stack languages, but the issue is that this only really could apply to a standardized Forth language. Forth is only incidentally concatenative and stack-based --- this just happens to have both a simple implementation and has good compositional properties. There is nothing stopping you from introducing new programming models in a Forth, and the article gives a few examples. You can add arbitrary bytecode interpreters to a Forth, for example, and easily make it interoperable with the threaded interpreter in the base Forth. Nothing stopping you from adding words so your Forth feels like a register machine, either. It's because of this that any sort of type system seems doomed (other than one that describes state transitions of the CPU...).

> Perhaps I seem dismissive ...

I sort of don't see the point of saying "it's not really extensible if I can't extend it in all possible ways." In any case, Forth and Lisp are, for trivial reasons, languages that let you embed arbitrary other languages within them (it's about as exciting as how Turing completeness seems to be easy to meet -- which is to say, not very). Worst case, the cost is implementing a whole compiler or interpreter for said language, but, still, it's possible. Common Lisp gives you many hooks to change low level behaviors, so there is usually a better way than this worst case.

Something like borrow checking, though, is a pervasive new feature. The issue is that _everything_ needs to know about how ownership is transferred. It's no different from, even in C, changing some basic struct the whole application uses and then having to update everything to account for it. You could add borrow checking to Common Lisp, but it would have to be in demarcated areas in which borrow checking is being done, and, like Rust, you'd have to figure out an 'unsafe' to be able to use all the Lisp (respectively, C and C++) that's already out there.

> formal methods

Being able to bolt on embedded formal methods to a programming language is active research. I think it's unreasonable to expect this of any language right now, other than ones specifically designed for it :-) (Speaking as a Lean user.)

Forth doesn't really seem to be the kind of thing where practitioners would care about formal methods... It's very defensible to say, then, that Forth is wrong because of this (we depend quite a lot on software being correct!). But, I don't see anything about Forth that prevents you from defining words that check formal specifications -- and I don't mean this in the trivial adding-a- formally-checked-language-into-Forth way.

> extensibility

Anyway, I don't think it's good or bad to be extensible. It's just a property, and Forth and Common Lisp happen to be examples of languages that are much more extensible than usual. There are certainly engineering challenges either way when it comes to extensibility. And, with an extensible language, while you might be able to make bespoke solutions, you now have a bespoke (hopefully small) language to maintain, too. Language design ability and programming ability don't necessarily go hand-in-hand, either...

<comment><USER13> The kind of issue I see this thread getting at is what I call the "terrarium problem", which is, to make a whole software ecosystem like a language environment or API mechanisms bounded by a standard, one has to build a sufficiently large terrarium for it and maintain that. The largest, most flexible terrariums we use as developers tend to be operating system standards, browser standards, Internet protocols, etc.; in the case of Forth it's defined by the bootstrapping process, since the bootstrapping code can present a Forth that is near the hardware, or one that is embedded alongside another language environment like Lua. It is even relatively straightforward to have a Forth that generates Lua source code, which the Lua interpreter can then apply its own checks to and evaluate efficiently.

Extensibility by itself doesn't solve the terrarium problem because it doesn't define any standard, so there isn't anything to build on. When presented with extensibility, you still build the terrarium, it's just a customized one, and if you do it ground-up like Forth, you can potentially build it smaller and simpler. But in the end you still have a terrarium with assumed boundaries.

This has led me away from Forth-the-language in the last few months to explore the terrarium problem further, and I hit on the idea of treating this as an organizational issue solved at the level of the core UX. If the problem is defining boundaries in software, we should have better ways of doing that. At first I considered this in terms of selection - selection being one of the pillars of structured programming, and many of our improvements taking the form of easier selection metaphors. This gradually led me to explore the idea of document editing with a binder and sticky notes metaphor, with a supplemental compiler process taking the resulting complex, layered documents and processing them into a linear form for consumption. The presumption is that if I present a rich set of tools for defining types of divisions and groupings defined skeumorphically - pages, bins, tape, wire, guides, stickies, overlays - and then add a bit of labelling and indirection on top, a powerful "thinking tool" should emerge where the organization is easy and the compilation system makes it easy to query and traverse it in a customized way.

If I can finish designing it.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Yea! An informed, intelligent discussion about my now-favourite language. I've been near fanatical about it for the last 3-4 years mainly using Mecrisp Stellaris on the STM32F4xx. I find the elegant simplicity and raw power so refreshing after all the bloatware and nanny-knows-best typed code. Even the stack juggling is absorbing puzzle-solving fun. I've successfully built OLED and MIDI drivers from scratch and am now tackling DSP SIMD assembly FFT routines - stuff I would never normally attempt without this experience. It harks back to the simpler days of the 1980s yet it is really is only limited by one's approach - given some thought, you can adapt it to just about any programming paradigm - should you actually need it, that is. I'm probably not currently considered a full Forthwright yet not having built myself a Forth from scratch (yet). I know Forth is not perfect, but it's the closest I've found yet and deserves a renaissance, if it withered on the vine that would be a travesty - it's too good for that.

</comment><comment><USER15> I've always had an interest in Forth. It's a very powerful tool that I just never got the hang of. When OS/2 was still young, and Microsoft hadn't killed it off yet... I was told that you couldn't write assembler programs in OS/2.... which I took as a challenge. Forth/2 was the result. Under OS/2 V2 it generated native code, and actually got quite a few users once Brian Matthewson wrote a manual for it.

These days, I wonder if it's possible to run Forth inside a VM as the operating system. How hard would it be to stand up a networking stack?

<comment><USER16> Who told you that? The whole of Ed Iacobucci's _OS /2 Programmer's Guide_ was in assembly language.

<comment><USER15> I could have used that book back then. That was life before Amazon and online searches ruled everything. If it wasn't at Borders or Barnes and Noble, I didn't know about it.

</comment></comment></comment><comment><USER17> Here's a comment from a few years ago where I go over how do make a FORTH-like language starting from a simple basic RPN calculator in C [1] and then adding programmability (mostly implemented in the language itself with only a little bit of C support), and finishing with some ways you could optimize it to actually get decent performance.

This would be reasonable afternoon project (except for the optimization stuff).

None of the C code is complex or tricky or big. You could easily do it in assembly instead. That's why these kind of languages are great for a lot of embedded applications. You only need to write a small assembly core to support your language, plus assembly function to support your hardware, and then you can do everything else in your higher level FORTH-like language.

[1] [https://news.ycombinator.com/item?id=13082825](https://news.ycombinator.com/item?id=13082825)

<comment><USER18> I hacked up a quick implementation of your writeup in go just now, as I said at the time your summary was wonderfully direct and "obvious".

[https://github.com/skx/foth](https://github.com/skx/foth)

Thanks again, four years later!

I'll get the compilation phase done tomorrow, barring surprises.

</comment></comment><comment><USER19> An interesting curiosity about Forth is the fact that the final stage of FreeBSD kernel bootstrapping, the loader program, contains a Forth interpreter. If you have a look in the /boot directory on a FreeBSD system, you will see quite a few files named with the extension "4th" there, and in the loader(8) man page we find among other things the following:

> loader [...] provides a scripting language that can be used to automate > tasks, do pre-configuration or assist in recovery procedures. This scripting > language is roughly divided in two main components. [...] The bigger > component is an ANS Forth compatible Forth interpreter based on FICL, by > John Sadler.

> [...]

> BUILTINS AND FORTH

> All builtin words are state-smart, immediate words. If interpreted, they > behave exactly as described previously. If they are compiled, though, they > extract their arguments from the stack instead of the command line.

> If compiled, the builtin words expect to find, at execution time, the > following parameters on the stack:

> addrN lenN ... addr2 len2 addr1 len1 N

> where addrX lenX are strings which will compose the command line that will > be parsed into the builtin's arguments. Internally, these strings are > concatenated in from 1 to N, with a space put between each one.

> If no arguments are passed, a 0 must be passed, even if the builtin accepts > no arguments.

> While this behavior has benefits, it has its trade-offs. If the execution > token of a builtin is acquired (through ' or [']), and then passed to catch > or execute, the builtin behavior will depend on the system state at the time > catch or execute is processed! This is particularly annoying for programs > that want or need to handle exceptions. In this case, the use of a proxy is > recommended. For example:

> : (boot) boot;

> FICL

> FICL is a Forth interpreter written in C, in the form of a forth virtual > machine library that can be called by C functions and vice versa.

> In loader, each line read interactively is then fed to FICL, which may call > loader back to execute the builtin words. The builtin include will also feed > FICL, one line at a time.

> The words available to FICL can be classified into four groups. The ANS > Forth standard words, extra FICL words, extra FreeBSD words, and the builtin > commands; the latter were already described. The ANS Forth standard words > are listed in the STANDARDS section. The words falling in the two other > groups are described in the following subsections.

[https://www.freebsd.org/cgi/man.cgi?query=loader&apropos=0&s...](https://www.freebsd.org/cgi/man.cgi?query=loader&apropos=0&sektion=8&manpath=FreeBSD+12.1-RELEASE+and+Ports&arch=default&format=html)

<comment> yjftsjthsd-h Forth seems to have made its way into a lot of boot environments; it was also used for open firmware

</comment></comment><comment><USER20> noice!</comment>


Cache-Control for Civilians - <AUTHOR> https://csswizardry.com/2019/03/cache-control-for-civilians/ <comment><USER2> That addition of a cache busting header is pretty nice. Not something you want to use, but you'll be glad you have it when you need it.</comment>


A definitive guide to computer-assisted translation - <AUTHOR> http://www.hyperlingo.com/blog/cat-tools-the-definitive-guide/

<comment><USER2> I used to work as a translator and found a little-known CAT-tool which is quite cheap but very comfortable to work with. It's called MetaTexis and unfortunately it works on Windows only as an addition to MS Word. So, if you're a translator and work with MS Word I strongly recommend that you check it out, it has a fully-functional free demo version.

</comment><comment><AUTHOR> Computer Assisted Translation (CAT) tools are productivity tools to automate some aspects of the translation process. Over the past few years, CAT tools have developed rapidly, dramatically increasing translation efficiency.</comment>


After a Two-Year Trek, NASA's Mars Rover Reaches Its Mountain Lab - <AUTHOR> http://www.nytimes.com/2014/09/12/science/space/after-a-two-year-trek-nasa-mars-rover-reaches-its-mountain-lab.html?ref=science&_r=0

<comment><USER2> This story had much attention here a few days ago: [https://news.ycombinator.com/item?id=8307790](https://news.ycombinator.com/item?id=8307790).

You can find whether a story has already appeared by using the Search box at the bottom of most HN pages. Reposts are ok after about a year. If a story hasn't had much attention on HN yet, it's also ok to repost.</comment>


How to Choose a Startup to Work for by Thinking Like an Investor - <AUTHOR> https://triplebyte.com/blog/how-to-choose-a-startup-to-work-for <comment><USER4> The metaphor of early startup employee as investor seems really smart at first but is ludicrous in reality.

It is physically impossible to choose a startup like a VC because you cannot diversify your portfolio like they can. VCs can sprinkle (relatively) small amounts of money across dozens or hundreds of startups. If one fails then the impact to the portfolio is negligible. In fact, VCs expect that most of their portfolio probably won't pan out.

Good luck diversifying as an employee. Working part time at even 2 startups is obviously laughable.

If you're in it for the money, working at a startup is probably not for you. It really is akin to gambling. There may seem to be more information available than gambling, but there is so much unknown and hidden information it's damn near impossible to make a 'rational' decision.

That's not to say you should never work at a startup. Startups are often great learning opportunities because you usually have both broad and deep scope of responsibility. There's also often better alignment between management and employees because people tend to be working stuff that is materially relatable to the bottom line. It can also be a career accelerator if the company grows headcount rapidly and you suddenly become a 'senior person'™. YMMV.

<comment><USER5> The best part is stock options. Not only are you not diversified, now you get to concentrate your portfolio by buying stock in the company that provides your income.

Stock options: for concentrating your income and your investments when you're excited and biased.

<comment><USER6> Decades of experience has taught me that stock options are essentially wallpaper. Sure, if a company wants to give me options, I'll take them -- but they are in no way a substitute for real compensation, and I won't accept them in lieu of something real.

That said, if a startup is doing something that really turns my gears and I like the company, then I'm absolutely willing to work for less pay in order to be a part of that.

<comment><USER7> Something I never understood about this attitude ("... then I'm absolutely willing to work for less pay ...") is: why there are almost no examples of such behavior in other highly paid professions, such as physicians or lawyers? Very rarely you'll find physicians saying "I really want to become a brain surgeon, I'll happily take 40% less than my market rate". You'll certainly find physicians doing volunteering, but that's another thing.

In software instead, that's incredibly common: several of my coworkers (late stage private company) are in mostly for the thrill of working on our technology since we operate in some interesting niche, and I know for a fact they are paid much less than me (30%+), even if they have a bigger impact than me on the company (and they are also older, with more experience!).

It's so common that many times employers use it at their advantage, by preferring people that can be sold purely on the tech rather than the tech AND the market rate for the position.

To me, both the financial aspects and the technical challenges must be absolutely satisfied in order to join a company. Maybe I'm too practical because I'm not a trust fund kid and grew up dirt poor, so I know that in my limited ~20y engineering career (assuming ageism) I need to make enough so that I will be able to retire comfortably, while making sure I work on stuff that stimulates me so I can give my very best.

<comment><USER8> I think there are. Teachers (pretty much as a whole) and public defenders seem to fit here.

I know multiple photographers whose passion is landscapes/nature and only grudgingly supplement that income with weddings/portraits.

<comment><USER7> With regards to teachers or photographers, that's not a fair comparison in my opinion: in those cases, low wages are mostly dictated by high supply vs low demand, so from an economic point of view it "makes sense". That's much different than software engineering or medicine, where there is a scarcity of supply (and the only reason why software salaries are in the 6 figures).

In other words, teachers are not willingly giving up a portion of the compensation that they could otherwise be making doing the same job somewhere else. In software instead, that happens ("Oh, you work on FOO v2.0, I'll happily take 40% less than what I could otherwise be making doing this job in another company").

I don't know about public defenders, you might have a point there.

<comment><USER9> From my perspective it looks like a good amount of teachers decided to give up a portion of the compensation _earlier_ (i.e. they gave up good pay not when they're looking for another job in an industry they're already in, but they decided to give up good pay upon joining the industry).

It's like how artists/writers/game developers/etc. decide to go into their field even though they know that they could be making much more money in any other field.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> I worked at three startups before taking the current break I'm on - one I left before my stock was worth anything (would have paid out a small amount in an acquisition), another, the stock is now worth zero, and the third has a shot at being worth about a year's salary if current late-stage valuation is to be representative of a potential buyout/IPO (I'd say odds are alright this will happen). While I try not to think about it, because honestly the experience was worth it, I would have made far more over the last eight years of my career staying put at BigCo.

With that being said...

All three times, despite considering myself a pretty rational person, I got this strange psychological delusion when joining the startup that it was going to somehow magically make me rich. I think it's probably the "honeymoon" stage of joining any company. Things are awesome! The culture is fast-paced, chaotic, and offers plenty of opportunity! This is a rocket ship! It kind of matches the "what if" feeling of buying a lotto ticket. It's impossible not to imagine what _might_ happen.

I think if I jump back into startupville, my cynicism toward the "get-rich- fast with these private options" will outweigh the bright-eyed, bushy-tailed sensation of my 20s.

<comment><USER11> IMO there's only two paths that really makes sense now when considering a private co. Either a) join super early (e.g. penny strike price) with a meaningful % of total company (at least 10 bps) OR b) join late stage growth co that offers RSUs over options (e.g. "Softbank" stage cos).

Joining a "middle" stage co where you are offered expensive options is the worst, since you've missed out on the early upside and you take on a ton of risk due to cost of exercising.

<comment><USER12> I wouldn't consider 10 bps (0.1%) meaningful. Early stage is very, very risky.

<comment><USER13> Depends if it's pre- or post-product/market fit.

Joining a startup that's overwhelmed with demand for its product - particularly if you can see the usefulness of this product yourself - <USER2> usually a good move even at 0.1%. Joining a startup that's still iterating on the product (and maybe has a couple customers but just lost a big one and they have to work really hard to sign the next one) may be a bad move even at 10%, because there's a good chance that equity will be worthless.

The article doesn't really mention it, but a great question to ask any potential employer is "What are your biggest problems right now?" Scaling is a _great_ problem to have, because it indicates lots of demand and has solutions that are relatively well-known in the industry. Customer service is a pretty good one - it shows that the company has customers who care enough to want service, and if the CEO is willing to admit this is a problem it'll probably get fixed. Hiring, code quality, internationalization, testing, service outages, brain-dead tech stack, anything that's specific to the problem domain itself - these are also pretty decent problems to have as long as the CEO is attentive to them. Unhappy customers or staff turnover is a caution - <USER3> should dig into this further to see _why_ they're leaving, and if it looks like the problem is solvable. Same with financing - many hot companies run low on cash at various points, and you only need to make sure the company isn't going to die, but if the company loses more money than it makes on each transaction that's a huge red flag. The biggest problems (particularly for an engineer) are anything to do with sales, marketing, partnerships, or "growing the business", because the root cause of this is often that customers don't really want what you're making, and nothing short of a major pivot fixes that.

As a side bonus, asking this question is often a big positive signal for the hiring manager, because it shows you're serious about solving problems rather than just collecting a paycheck.

<comment><USER12> Yes, I agree. I was assuming "pre-market fit" "few or no customers." In this case, 0.1% is hardly worth the risk.

</comment></comment></comment></comment></comment><comment><USER14> Best risk-reward is VP or SVP level at Series C or D company which gets you options for 1-2% of the company... switch every 18 months to diversify and build a portfolio but negotiate 10 year exercise window on your options when you leave rather than the standard 90 days.

Thousands of execs doing that around Silicon Valley working through Daversa and other executive recruiters (who themselves get $85K-$100K per executive hire).

<comment><USER15> Or you could just take a non startup job for higher pay and buy 0.1% of a bunch of late stage startups on EquityZen or Equidate. No need to wait 10 years...

<comment><USER7> I would advise against that, I tried to dabble with both platforms, but the markup at which those shares are sold is often incredibly high: common shares of most companies on those platforms are actually sold at prices higher than the preferred (crazy), even if such company just went through a very recent round of funding, meaning that the preferred price is pretty much the very top investors valued the company at.

I honestly don't know who would buy that, the idea I got by doing some basic due diligence on those deals is that who puts them online thinks "let's see if we can attract some dumb money to give us some liquidity at an insane premium". If you sell things at a fair price (e.g. selling common shares at the preferred price * 0.8, depending on the current stage of the company), investors will want to give you liquidity way before your offer on equityzen gets accepted and pollutes the cap table (I speak from direct experience), so what's left on those crowdsourced platforms is many times overpriced garbage.

<comment><USER15> well, getting shares as an employee is even worse. You still get common shares, usually with some trade restrictions / lock up period on top of it... The price / premium on the secondary markets is a market price, and in a market that is more efficient than it used to be. Also, the person selling those shares may be an early employee who has many other reasons to sell than screwing the buyer...

</comment></comment></comment></comment><comment><USER16> An aside to this article: along with thinking like an investor, you can also reach out to investors who will often be willing to help with your job search.

For example, as a seed VC there are now about 80 companies at various stages that my fund works with. If someone emails me and says, "I'm a good engineer who wants to join a Series A startup in SF or Oakland that has characteristics X, Y, and Z," there's a good chance I can make a few useful recs.

There's nice incentive alignment here: the VC doesn't get any compensation, they just want their companies and the prospective employee to do well. That means 1) we won't recommend a bad fit to an employee because we want the employee to join and be happy and get their friends to ask us for company recs; 2) we won't recommend a bad fit to a company because we want founders to like us and not feel distracted by us. We're going for quality, not quantity -- and you're welcome to ignore our suggestions. So if you're good at what you do and are looking to join a startup, consider soliciting recs from a few investors with large portfolios.

I wrote a short post about this a few years ago: [https://www.codingvc.com/using-investors-to-find-the- ideal-s...](https://www.codingvc.com/using-investors-to-find-the-ideal- startup-job/)

I might regret posting this invite on HN, but if you want to join a startup and want recs, my email is in my blog's header.

</comment><comment><USER17> > However you will learn significantly more, build a stronger network, and > accelerate your career trajectory much faster by joining a successful > startup than an average one.

 _smack forehead_ Yes, what ever could I have been thinking before! Yes, yes, I should only be joining a _successful_ startup, not an average one!

> steep career trajectories, like Jeff Dean, Marissa Mayer or Chris Cox.

Yes yes! New plan: be Jeff Dean!

> Next, you need to evaluate the strength of the team and market

Unfortunately, this is not realistically possible for most non name-brand candidates. The company is not going to entertain the amount of inquiry (due diligence) you would need to pursue.

> Evaluating the relationship between founders is as important as evaluating > the founders themselves.

Indeed it is! Good luck getting access to do that ...

This article is just more hyperbole from triplebyte. I wonder how their business is doing ...

[https://triplebyte.com/careers](https://triplebyte.com/careers):

> We've already achieved profitablity

But if I may quote from this article:

> one thing we learned at YC was not to be fooled by large absolute numbers. > What matters most is the growth rate.

triplebyte, put your money where your mouth is and advertise your top line growth rate, not the fact that you are profitable. When your fee is on the order of $30k per hire and your infra and operating costs are low, I expect you to be profitable.

<comment><USER18> Evaluating the strength of the team and the market is something you can do with zero involvement from the company, and you probably shouldn't depend on them to tell you either even if they offered.

Getting a sense of founder dynamics can be harder, depending on stage, but it's easy if you're early enough. I interviewed at Dropbox when it was 20 people and it was obvious what roles Drew and Arash played, as an example. At a larger stage this is harder, but you have more public sources of information at that point.

Regarding Triplebyte's profits, you should be asking how fast they're growing.

Finally, we should all be Jeff Dean. :)

</comment></comment><comment><USER19> Probably one of your main considerations should be how you are left if the startup dies. There's plenty of good advice here about how to pick a startup that might succeed.

So there's a few considerations:

\- Have you got some savings, in case it dies suddenly? You need to be able to pay rent until you find another job. Hopefully the startup is located near these other jobs.

\- Does it allow you to build on existing experience? If you can claim you're in the same industry, you're not losing much (perceived) seniority by trying your luck for a bit.

\- Does it give you an easy promotion? This is probably one of the main things a startup can offer. Just being able to add "Senior" to your name or "Team Lead" a few years before you would in BigCo might be worth it.

\- Do you get to work with the tech that you want for your CV? You probably have an idea of what's hot to have on a CV, and a startup is relatively new, so maybe you can direct things that way?

</comment><comment><USER20> > It's also only by joining a successful startup early that you can get > remarkably steep career trajectories, like Jeff Dean, Marissa Mayer or Chris > Cox.

The number of people with these sort of "career trajectories" is vanishingly small. This reminds me of what Phil Greenspan wrote (2006?), mocking the college student's career evaluation process:

"I can't decide if I want to be a scientist like James Watson, a musician like Britney Spears, or an actor like Harrison Ford."

</comment><comment><USER21> Even top VCs need a portfolio of companies to produce a return. If you asked a VC to bet a whole fund on a single company :) and these are people who's full time job is to pick companies

<comment><USER22> Yeah, a key strategy for investors is to diversify, and that's exactly what startup employees cannot meaningfully do.

<comment><USER23> Startup employees could pool their risk by creating their own shared investment fund which held all their shares/options in trust and spread out the winnings. The reward would be far less but more predictable. I doubt many would have the foresight to commit to something like this.

<comment><USER24> Neat idea, but how would you choose who qualifies to join?

<comment><USER23> Probably the same way a VC chooses startups.

</comment></comment></comment></comment></comment><comment><USER25> TripleByte is a hiring agency with a financial interest in placing people with startups of all sizes and financial states. This information should be taken with a grain of salt.

<comment><USER26> And in my experience they focus solely on tech IC candidates, which is not for everyone.

<comment><USER25> I'm out of the loop. What do you mean by tech IC candidate?

</comment></comment></comment><comment><USER27> By working at twenty of them, expecting 15 to fail, 4 to not completely fail, and one to go big?

<comment><USER28> This is about my career. 8 startups, earlish employee at 6. 1 mediocre IPO, and 1 very successful IPO.

The rest basically failures or zombies that made me no extra money.

Probably a little more lucky than most.

<comment><USER25> Tons more lucky than most. My last startup job misclassified me when funds got tight. A friend of mine who joined later never got paid (good luck filing a wage claim in WA state if L&I's system still thinks you're a contractor).

<comment><USER28> Perhaps also luck, but I've managed to have a spidy sense for when things are going the wrong way, and got out / moved on before it got that bad.

<comment><USER29> What are some of the signs/symptoms that trigger your spidy sense?

<comment><USER25> The big one for me was realizing that my boss had lied about knowing how to code. Other red flags include code and documentation quality, how the business sells itself to potential customers (does it greatly oversell it's abilities), the expiration date of the coffee/tea in the break room (I got food poisoning when I drank the startup's three year expired tea - the founders were still wondering why they felt like crap all the time when I left), etc.

It's really a bunch of little things that, when seen as off all at once, will trip your spidey sense to jump ship.

</comment></comment></comment></comment></comment></comment><comment><USER30> Naive question: why not work for a FAANG, try to make close to half a million after enough time, promotions and jumping ship between the different firms, then just invest whatever you're not spending into the stock market or whatever other assets you choose? Take the 400k you're not spending and dump into Tesla and friends, or whatever other sexy stock du jour?

Seems like a much healthier risk profile unless you ONLY want a huge Google- like unicorn outcome as an early employee.

<comment><USER31> It is much easier to get a job at a growing VC-backed startup than a FAANG.

<comment><USER30> I suppose so. That could be one's foot in the door for a FAANG role later down the line?

</comment></comment></comment><comment><USER32> I accepted early on that working for a startup will probably not make me rich. Quite the opposite, I may wake up one day and find out that I no longer have a job or my next salary isn't coming. I'm not the kind of person who believes in gambling. Working and living in Europe doesn't really help with the vision that I might join a European unicorn startup, whose stocks might not be worthless one day.

However I do see a lot of benefits that come with working for a startup. You can voice your opinion and be heard. Pushing code to production on your first day. Owning what you do and being able to make decisions. Creating your own environment in which you can learn and become a better developer.

And, most importantly, startups are more open to remote than BigCo Inc.

Monetary compensation might be less, but freedom has a price. If I'm able to work remotely, I can move to a place that is cheaper to live.

<comment><USER33> Most of the startups I've come across in Europe usually pay at or near to market rates. Maybe it's just my experience (I've mostly been working as a contractor), but I find this somewhat surprising, given that the social structures here mean that taking a risk by working unpaid/lower pay for a startup isn't such a big issue.

</comment></comment><comment><USER34> I think the author should produce some data showing this is a viable strategy before he gives people advice that could lose them hundreds of thousands of dollars. Other people have pointed out the statistical problems with this strategy so I won't restate them.

The author may sincerely believe in his own advice, but we should note that he did not, himself, get rich this way.

A dropout from elite UK universities, he founded a startup and exited for a small amount of money. Since then he has worked for Y Combinator, invested, and also founded a few companies.

Taggar has never, himself, been anything like a startup employee. And great for him; he seems extremely talented and maybe that route isn't for him. But his company (TripleByte) profits from directing talented people into these kinds of companies.

</comment><comment><USER35> This is how I've approached joining the last two companies I've signed on with. In the hiring process I ask to speak with finance and the founders to see if the company has the legs to be a real rocket ship. Remember that an interview is just as much about them interviewing you as it is for you to interview _them_.

<comment><USER36> How likely is it that you as a potential employee get to see the books and know what's going on like that these days?

Honest question; seems like it's a tougher thing to get access to than for a VC, but maybe I'm wrong.

<comment><USER37> That depends on what the company is looking for in you. If you're going to do mission critical stuff or they want you for an important role they might even enjoy showing you their internals. And if they don't want to show you then that's a pretty good indication that you are probably better off elsewhere. Transparency in an early stage start-up is good for everybody, including the founders. If founders are not willing to share their position they are effectively asking you to buy a cat in a bag.

<comment><USER38> No private company I have ever worked for as an employee has agreed to let me look at their balance sheet or income statement. Most would not even discuss valuation in terms other than # of shares in my offer, which is meaningless.

One CEO I recall even laughed when I asked at the interview (that should have been a red flag in retrospect). I later learned he gossiped about how inappropriate it was for a candidate to ask about company financials.

<comment><USER39> Same here. This information is only for investors and other "important" people. Most of us are not part of that group.

</comment></comment></comment></comment></comment><comment><USER40> ,,It's also only by joining a successful startup early that you can get remarkably steep career trajectories, like Jeff Dean''

It's sad that Jeff Dean is the last example the article can give. When evaluating a startup as an investor, I see that while investors get great terms, employees get junk options. So until it changes, I'm just staying with big companies, thank you very much.

</comment><comment><USER41> Bad advice. You shouldn't pick a startup solely based off these criteria. You are a very minor investor that is the last to get paid. Investors can accept far more risk and reward, and care very little for things like whether the employees are happy.

Does the work look interesting? Will you learn new things?

Do you like the problem space the startup operates in?

How is the culture? Fit or not?

Will you be happy there?

</comment><comment><USER42> Some good points there. A couple of things to add from my experience.

The asking hard questions is very important. I once interviewed with a startup that just raised $3MM. You pay them a small fee and if your flight gets cancelled they find you a new one for free. I pressed the founder hard on why someone like me would buy that insurance and his answer eventually was for the same reason you buy insurance for your car or house. Once he gave me that answer I knew I'm not going to work there. And this was actually a nice startup with some good people. There are much worse startups with founders who have no clue and god knows how they managed to raise money. One founder once told me he is well connected and one phone call and people write him checks (red flag). Then there are the ones who are really shady and will lie about everything. Be very careful and don't ignore the red flags!

Another important point is that you need to make sure the startup really needs you. In the past I talked with two startups that built their pitch around AI but they had very little knowledge of AI so what they had in mind wasn't really possible and even if it was, the product had millions of other things to succeed before AI was even needed. The problem is that founders sometimes focus too much about their pitch and how to impress investors rather than on their product.

</comment><comment><USER43> The author writes from the point of view of an investor. How likely it is that as a candidate for a job, they would give you all that service and access to all that information? A meeting with all the founders?

Unless you're a valued, seasoned industry veteran, joining a very early stage startup founded by 20-somethings, would you really be able to access all that the author suggests?

</comment><comment><USER44> Choosing a YC startup is probably the best bet. If it fails you can use that network to get into another YC company.

</comment><comment><USER6> I love working for startups, but not working for startups that have VC money -- the involvement of VCs changes the nature of everything.

But then, my goal is primarily to do meaningful work on interesting projects. I have little interest in getting rich.

</comment><comment><USER45> "If you're happy working where you are, and you don't have any ambition to do anything else, you're probably going to get paid less and work more if you leave for a startup. If getting paid less and working more is unappealing to you, then I would recommend staying where you are!"

There's another option. You can pick a job that isn't a startup, that makes you hate your life, and phone it in every day just to get by. You save your energy and grind away at night on your own company. I say "company" instead of startup because I don't think venture capital is the right thing to pursue for a single founder doing this.

Just have a goal to build a product that has at least 1000 customers paying $10/mon so you can quit your dayjob. The hatred of your dayjob will fuel your motivation to work at night.

A startup is much riskier than taking this approach. You put in 60 hours a week at a startup and even in the very unlikely scenario it pays off and the startup becomes huge - at most you have a 1% stake and become a millionaire. You become a millionaire way easier working on your own project.

So my philosophy is to get a job you hate - work to build the future you want yourself - never let anyone else exploit you to the point where the only way you become a millionaire is if they become a billionaire.

</comment><comment><USER46> As an "investor" you should consider the range of asset classes available to you when deciding how to invest your time and labour.

See Dan Luu's articles about "big company vs startups" and "options versus cash"

[https://danluu.com/startup-tradeoffs/](https://danluu.com/startup-tradeoffs/)

[https://danluu.com/startup-options/](https://danluu.com/startup-options/)

</comment><comment><AUTHOR> Rather than treating predicting startup success as an intractable problem, I think anyone considering joining a startup should act like a startup investor making a bet on how much the value of equity in that startup will grow over time. Startup investors do this for a living and that's essentially what you are too. You're investing your time and they are investing money.

<comment><USER47> Hrm, the parallel feels really forced to me. You can invest money in multiple startups at the same time, to hedge your bets. You can't do that with your time if you plan on working full-time.

<comment><USER48> Its not even about hedging but about diversification. If you are in a position where you can't diversify fully, you should require a higher return on investment in order to take on the risk.

For example. If you could bet on a coin flip 100k times at $1 a bet, you might be willing to accept getting paid $1.01 per win. But if you had to bet $100k on a single coin flip, you would likely need the payout to be much greater before you were willing to take the bet.

<comment><USER47> Both are viable strategies. You diversify when you spend time working for startups across different sectors in the hope that some might succeed in their own area. You hedge when you work for several competitors in the same area in the hope that one of them will win in the end.

</comment></comment></comment></comment><comment><USER49> "I think startup employees should re-evaluate the growth trajectory of their startup every year."

At a bare minimum. Probably more often.

</comment><comment><USER50> the best advice I can offer is to join a team that has deep pockets. the biggest reason my company succeeded is that they had cash to burn. sure, they were smart. they moved quickly, they dropped failing products instead of holding on to them. they made consistently good decisions. but they also were able to sink millions into the company's products and promotion thereof without going under for years, long enough to stumble upon a hugely profitable model.

no idea how to assess the size of a company's pockets. maybe one that has a founder who has already had a successful exit. every other attribute of a company is basically fortune telling.

</comment><comment><USER51> Being an early-stage employee gets you all the downsides of being a founder, with only a fraction of the benefits.

</comment><comment><USER52> I found these questions to be pretty interesting

[https://medium.com/@therealpankaj/interview-questions-to- ask...](https://medium.com/@therealpankaj/interview-questions-to-ask-a- startup-ceo-cf04d71752e8)

</comment><comment><USER53> Just read the conclusions, the writer is not sure what really works.

</comment><comment><USER54> And why startups condense in America? [http://paulgraham.com/america.html](http://paulgraham.com/america.html)

</comment><comment><USER55> What's considered a good bps for an very senior engineer joining as 20th employee, at a series A company with a couple of million dollars revenue?

</comment><comment><USER56> This kind of advice is similar to the "get rich day trading stocks" narrative. It only sounds realistic if you are ignorant of the statistical probabilities involved (it seems most people are).

A vast majority of VC funds produce weak or _negative_ returns. And this is after diversifying their fund investment across 10+ start-ups and assuming that 90% are going to be losers compared to putting that money in public equities.

You can't work for 10+ companies at once like a VC can. And even if you could, the odds are _still_ against you. The idea that you'll be able to pick ONE winner at an early stage is, quite frankly hilarious and naive.

<comment><USER37> Another major reason that you won't be able to pick the winner is because you only get to pick once, and then you are booked for a long time. If you think a better one comes along you now have a sunk cost, and you'll be starting all over again, with a very good chance that your 'better' one will end up being worse. So the odds are very much against you if you are evaluating start-ups serially.

The better way to do it is to evaluate a whole pile of them at once, and then to pick the best one that you can find. And you're going to have to do a lot of work to evaluate those options, about as much as though your future depends on it, because it does. If you're not prepared to put in that kind of work then it really is just a lottery, and you're most likely better off to just take a job that pays you roughly what you are worth on the market, in the longer term that + a good savings regime will be a much surer path to some serious cash than buying lottery tickets at an opportunity cost of 300-500K _each_.

</comment></comment><comment><USER57> What about the Groucho Marx strategy of not investing in any company which would have someone like yourself as an employee?

</comment><comment><USER11> it's funny to think of my own finances...I have a portfolio of stock from 3 startups now that has worked out surprisingly well

</comment><comment><USER58> Which scratch-off ticket should I buy at the gas station?</comment>


Study: Only 5% of Spanish Population has Covid-19 Antibodies [pdf] - <AUTHOR> http://www.ciencia.gob.es/stfls/MICINN/Ministerio/FICHEROS/ENECOVID_Informe_preliminar_cierre_primera_ronda_13Mayo2020.pdf <comment><USER2> We already knew it way before the study: mortality rate Covid-19 = 1.5%. 40.000 deaths. 100*40000/1.5 = 2.600.000 infected => 5% prevalence (Spain population 47 million)

<comment><AUTHOR> Based on NYC mortality figures as a lower bound, I also thought the rate must be in that neighborhood.

But there were influential dissenters, e.g. the infamous Stanford study a few weeks ago estimating nearly 3% infected in Santa Clara County, or the Swedish authorities' conviction that 25-30% of the population in Stockholm is infected.

This study seems to provide pretty strong evidence that those estimates were too high... not that I expect it to change anyone's mind at this point.

</comment></comment><comment><AUTHOR> Text only available in Spanish, unfortunately. But IMHO interesting because with >60,000 participants, it may be the largest longitudinal study so far.</comment>


Job Seekers Pay for Job Referrals - <AUTHOR> https://www.edsurge.com/news/2020-02-13-employers-pay-for-job-referrals-now-job-seekers-can-too <comment><USER2> Companies should always interview the referrer about their relationship with the referred.

How do they know the referral? Where have they worked together, and how closely did they work with each other? Involve the referrer in the hiring process.

Involve the referrer in the hiring process. It quickly becomes obvious if the referrer doesn't really know the person they referred. Don't hesitate to inform people that the quality of their referrals will impact their reputation.

Once people know that their referrals are being watched, they won't participate in these games. The single worst referral program I witnessed was a fire-and-forget program where employees put names on a referral list and received $5000 if that person was hired. No consequences for bad referrals. Unsurprisingly, a few people immediately flooded the referral list with the names of every developer in their LinkedIn lists. That program didn't last long.</comment>


Hedlund's startup ideas: "..find an old UNIX command that hasn't yet been implemented on the web.." - <AUTHOR> http://radar.oreilly.com/archives/2007/03/sfearthquakes_o.html <comment><USER2> top -- reddit.com

yah I'm a dork

<comment><USER3> wouldn't top be alexa.com (etc.), or internet storm center? ;)

</comment></comment><comment><USER4> "pine became Gmail"

Yeah. Google invented online email. Seriously, does google pay for fanboyism by the pound or what? Geez.

<comment><USER5> Having not lived the days of yore, I'm guessing that there were inferior mail clients that came before pine that are now long-forgotten because pine was better. Gmail is a similarly superior online email; it may not be the first, but it's the best, and that's all anyone remembers.

<comment><USER6> Yes, ecuzzillo said exactly what I meant. I also remember reading that Gmail consciously adopted Pine keyboard shortcuts (though I may have that wrong), which is why I made the direct link. Gmail seems like a very UNIX-y web mail client, where Hotmail, say, was not.

-Marc Hedlund

<comment><USER7> A Google employee and Pine contributer (Ryan Barrett) compared the two and gave his thoughts on the matter:

http://snarfed.org/space/gmail%20vs%20pine

</comment></comment></comment></comment><comment><USER8> I want fdisk for the internet.</comment>


AMD is gearing up for 7-nanometer CPUs and graphics cards - <AUTHOR> https://www.engadget.com/2018/04/30/amd-7-nanometer-cpus-and-gpus/ <comment><USER2> It would be pretty wild if AMD beats Intel to a 7nm CPU process. That's an ambitious timeline for AMD but clearly they see an opening in Intel's recent announcement that Canon Lake would be delayed until 2019 and have decided to capitalize.

I'm so glad that the competition between the two companies can be exciting once again.</comment>


The Virtues of a Second Screen - <AUTHOR> http://www.nytimes.com/2006/04/20/technology/20basics.html?ei=5090&en=6fc17b9bf54ea2ef&ex=1303185600&adxnnl=1&partner=rssuserland&emc=rss&adxnnlx=1145557985-oz7cOx7rKEkI//IXM/IYdA

<comment><USER2> I guess I'm one of the few people who has tried two screens and not found a benefit... maybe it's because I run so few applications - just Emacs and Firefox most of the time. I did try a two screen setup for a couple of weeks, with Emacs on one, and Firefox on the other. It just didn't do anything for me. I'm either working in Emacs, or I'm looking at the results in Firefox. I don't find I need to do both at the same time.

Perhaps I'm doing it wrong?

<comment><USER3> The lack on Windows of quick keyboard shortcut access to multiple open buffers and virtual desktops make multiple monitors seem important. Navigating by alt- tab and with the mouse is just too slow. In the X11 world the other buffer/virtual desktop/screen of stuff you want to see is one or two key presses away.

I have never felt a big benefit from multiple monitors, or even especially big monitors. 95% of the time I'm working with text, and I can only comprehend one window of text at a time. As long as I can flit around between multiple buffers, tabs, or desktops without my hands leaving the keyboard I'm fine.

<comment><USER4> I've run Linux forever and always enjoyed two monitors. I use WindowMaker and have have 7 workspaces (Main, Browsing, Communication, Development, Email, Shells, Misc.). Keyboard shortcuts for everything as I despise the mouse.

Most of the time I'm in "Development" and the left monitor is a fullscreen terminal with documentation/revision control/program output and the right is fullscreen gvim.

Nothing is more important to me than resolution though. I can't deal with anything less than 1600x1200 and almost always run 1920x1200 on everything (including laptop).

</comment></comment></comment><comment><USER5> I didn't look at the date, but when I saw the price listings, I was like, "What!?" I just bought a 22" widescreen for $200. I certainly appreciate all the extra real estate, and yet I can't deny that I could find a use for more. I'm considering plugging my old CRT into my integrated video card, but it produces so much heat compared to a flat panel.

</comment><comment><USER6> I am a big believer in 2 screens as well. I have a flat panel plugged into my laptop, and keep my project management <http://www.streamfocus.com> constantly on it while I work so I can easily move between working on the laptop and knowing what to work on on the lcd. :)

</comment><comment><USER7> Bah. A 30" is vastly superior to two screens. Think about it: with two screens, the valuable screen real-estate right in front of you, where you want the most important things, is instead occupied by 3 inches of BLACK PLASTIC.

<comment><USER8> I solve that just by having one centered and the other to the side. Soon I'm getting a third screen. You can get 4-5 22" LCDs for the price of one 30".

</comment></comment><comment><USER9> Why is it posted here?

</comment><comment><USER10> 2 screens seems a little passe, doncha think? 3 screens is ala mode.</comment>


District Of Columbia Tests Google Apps  - <AUTHOR> http://www.informationweek.com/news/internet/google/showArticle.jhtml?articleID=207600018&cid=RSSfeed_IWK_All

<comment><USER2> Good for them. But I think in this situation MS typically swoops in and makes a deal with the customer (and even if it's an unprofitable arrangement, why not keep the other guy from gaining revenue and headlines?).

</comment><comment><AUTHOR> "Google charges a flat, monthly fee of $50 per user, per year,"

huh?</comment>


Ask HN: Who moderates HN? - <AUTHOR> <comment><USER2> Do you sell torches and pitchforks?</comment>


Reaper: Digital Audio Workstation - <AUTHOR> https://www.reaper.fm/ <comment><USER2> Although considerably cheaper than Ableton, bitwig, it comes with a UI that reflects the price.</comment>


Browse iphone app store from browser - <AUTHOR> http://app-store.appspot.com

<comment><USER2> How did you make this?

<comment><USER3> By reading out and parsing the XML plist served by apple?

<comment><AUTHOR> yes

<comment><USER4> How do you get at that plist?

<comment><USER5> Wireshark

</comment></comment></comment></comment></comment><comment><USER6> <http://iphonexe.com> did this a while ago - it was all over the tubes last week

</comment><comment><USER7> This is pretty cool (useful). Thanks.

</comment><comment><USER8> why?

<comment><USER9> coz there are many of us who would like to read the details on linux. that's one reason.</comment></comment>


Bicycle radar gives cyclists a 6th sense - <AUTHOR> http://crowd.backtracker.io

<comment><USER2> Nice! Open API could mean some interesting hw combos, I'm thinking Google Glass.

<comment><AUTHOR> Absolutely! We're playing with Google Glass in our office - it's the ultimate interface.

Pricing of Glass is just an issue at this stage.</comment></comment>


Turning an obsession into gold - <AUTHOR> http://ninjasandrobots.com/obsessions-to-creativity

<comment><USER2> I think this is somewhat over-simplified. A lot of people have great design sense and love vintage stuff. Creating good products is necessary but not sufficient to make a business. Not too many people have a forum like Coudal to sell from.

<comment><USER3> Thanks a ton for checking out the post!

But I wasn't trying to make a point about simplifying anything. I definitely wasn't trying to say Step 1 obsess over something. Step 2. Profit. Coudal is a master at marketing and both he and Draplin have a tremendous reach into groups of people that helped get the ball rolling on these notebooks.

The point was merely that I've noticed that many of the people who I admire the most creatively seem to take "loves" and "interests" and made obsessions of them.

Aaron has taken a "love for vintage stuff" and turned it into quite an awesome collection. Which then turned into inspiration for his design/identity work for clients, and eventually it became the source of a great and well designed product idea. A lot of us could probably learn from this, and go much deeper into something that merely interests us in order to find better ideas.

</comment></comment><comment><USER4> _These guys have figured out how to create a tremendous business out of friggin notebook paper._

Can you explain the appeal here? All I see is the Beanie Babies concept for paper nerds, but am I missing something?

<comment><USER3> Well, I'm probably not the one best to explain why this business has become so popular with a mass audience as I was really just pointing out where the idea came from. But if it helps, this business has gone onto be much more than just stuff for "paper nerds". An example on the top of my mind: J Crew carries these notebooks in their retail stores and online: [http://www.jcrew.com/mens_feature/ingoodcompany/fieldnotes.j...](http://www.jcrew.com/mens_feature/ingoodcompany/fieldnotes.jsp). But I think Aaron captures it best:

"Will they go out of style? Oh yeah!" Draplin says. "The people who have a loop for frivolous shit, they're one out of 100. There's 99 other motherfuckers who take notes because that's their job. The UPS guy that comes in here, he uses them. I gave him one a year ago he just fills full of shit. I would much rather see him using the things. It's just paper. It's not cool. The fonts aren't cool at that point. But it works for him. And that is a cool thing."

<http://wweek.com/portland/article-17913-the_write_stuff.html></comment></comment>


Why "Agile" and especially Scrum are terrible - <AUTHOR> https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/ <comment><USER3> Like so many rants against Agile, this one assumes that it's intended to provide everything you need to take software from a drawing on a napkin to a fully functional, deployed product. The author goes even further and assumes that Agile is also supposed to provide a system of professional development, and all your R&D to boot. Why not blame it for not offering a guide to retirement investing while you're at it?

Agile is a process for managing software implementation. Period. You have to bring your own software design process, and if your company's is terrible (or nonexistent), don't blame Agile. You also have to manage your own software R&D, though you could certainly use the process to manage projects within R&D. But the idea that Agile somehow precludes R&D itself is ludicrous, no more sensible than saying it precluded your company from spending enough on marketing. Even sillier is the idea that it should provide some kind of career advancement plan. Agile is a software development process, not a personal development process. It doesn't (and shouldn't) offer a career roadmap any more than your build system does.

<comment><USER4> So I don't really agree with your opinion, but I don't think you're entirely wrong.

I've been doing scrum for about a year, and while I think agile is excellent because of the feedback look, I also think scrum is the worst agile method. Mainly because non-technical management will turn it from managing software implementation, into managing employees. But it's worse because you have to tell everyone your progress, and god forbid you actually have a problem and fuck up that sprints velocity. I was almost fired once because my velocity was half of what it normally was one sprint, due to basically dropping development work and doing devops for a week.

I've been on a project where we had marketers join our sprints, and we're even assigned stories. Timeboxing genuinely difficult problems into two weeks is extremely stressful, and most product owners don't care about complexity, only results. I've had to make some super nasty hacks just to help get a "win" to make a client happy. True scrum is just too rigid for applications with complex problems, which is why you'll have a hard time finding two places that do scrum the same way, or keep processes consistent sprint after sprint. In my opinion, I find kanban to be a much more effective way in managing development, as it allows your engineers to actually solve problems. So I agree that agile is effective, but I don't think scrum is always the answer.

Sorry about the word vomit.

<comment><USER3> These are really good observations. If there's a common thread, I would say it's the intolerance for failure exhibited by managers who don't understand software development. I'm not sure that intolerance would be lessened by another system, whether it be waterfall or kanban, or ad hoc. Prior to agile, when failure happened, it tended to happen in a big way near the end of the project. But if a project were two or three years long, as is common in software, everyone could move on to other jobs after having spent two or three years without having to report progress every day or demo features every two weeks. A couple years in one job is pretty typical nowadays. So in some ways it was a more comfortable environment for engineers.

Agile was introduced so that failure could be amortized and tracked. It makes the development process more transparent so that mid-course management corrections can be made and the corporate ship can be steered around the icebergs instead of running blindly dead into them. But in order for it to work, management must be tolerant of small failures. If it's not, then scrum will become theater with failure swept under the rug, and you'll be right back where we were, with failure becoming apparent only near product launch, when the iceberg suddenly appears out of the fog too late to avoid it.

Now, it may be a valid criticism that agile expects too much from management, that most software company managers aren't competent enough to use it. But that pretty much says we're all doomed anyway, regardless of what system (if any) is employed.

I'd be interested in your thoughts on why you feel kanban is better, since my impression is that it is essentially the same process but without sprint intervals.

<comment><USER4> So kanban and scrum are fairly similar, but the difference is that with kanban, you don't have to estimate a point value to it, as time isn't the priority.

I view this as an advantage for two reasons:

\- 1. Most non-technical clients view point estimates as absolute expectations. They can't comprehend an estimation in any other way. So if I can do 5 points a day, and I give a story 13 points, it's expected to be accomplished in ~2.5 days. If I exceed that amount of time, I've missed their expectations, and now I have a client who considers that work behind schedule.

\- 2. Large complex problems can be solved without the pressure of accomplishing it within a finite deadline. I think this leads to more robust implementations, and helps prevent large amounts of technical debt. To compare, I have never seen a scrum project that didn't have a runaway amount of technical debt that lead to some insane scope creep in stories later on.

It has a downside of potentially hiding some problems, but I think it helps with individual responsibility when it comes to tasks. Every time I've used kanban, it's usually been for pretty short periods, but those periods were extremely productive and way less stressful.

I mean, this is just all my opinion, so take it with a grain of salt, but this is what my agile experience has been so far.

<comment><USER3> Thanks, interesting perspective. The advantage of sprints is that you're demoing progress on a regular basis. I can see the possibility of people focusing more on the demo than the ultimate purpose of the code, in which case as you say you'd accumulate technical debt in the form of hacks. But if you don't demo regularly, you run the risk of hidden problems where everyone assumes something works when in fact it doesn't. Either way, competent management is needed to avoid the pitfall.

<comment><USER5> The 'hack a demo' problem highlights one of the rationales behind having a Definition of Done in Scrum. Unfortunately Scrum doesn't put hard and fast rules behind what should be in it, but most good Scrum teams take principles from XP such as all code should be tested. This helps reduce the 'hack' factor at the expense of getting it out the door faster.

</comment></comment></comment></comment></comment></comment><comment><USER6> This is all true. I worked in a medium size (400+) fully "agile" organization There was constant short term thinking and seemingly nothing was properly designed or actually engineered.

External facing APIs changed regularly, affecting other teams and leading to slow and painful integration. By regularly, I mean just about every sprint. How about thinking more than 2 weeks ahead?

It didn't help that there were lots of inexperienced guys just out of college (who probably thought this was normal.) Along with a "manager" with extremely poor communication skills (not uncommon in development) this was basically a disaster.

We did, however, have lots and lots of unit tests. We spent about half of each "iteration" rewriting them due to the API problems.

I gotta laugh.

<comment><USER5> Sounds like a problem with the organisation and engineers. Unless of course the externally facing APIs had to change regularly because of requirements changing, in which case welcome to software development, you were probably lucky that those external APIs weren't an opaque box for six months like they may have been without an agile methodology.

</comment></comment><comment><USER7> I don't disagree with the digs at Scrum and similar implementations of Agile, and I certainly agree with the spirit of criticizing (in the 'art critic' sense) the processes we use, instead of blindingly accepting whatever gets thrown at us.

That said, I think this post falls short at acknowledging the difference between the general Agile concept and Scrum as a particular implementation (of which there are many), and I have a few further disagreements:

 _Instead of working on actual, long-term projects that a person could get excited about, they're relegated to working on atomized, feature-level "user stories"_

Translation: instead of working the way I enjoy working, programmers have to work in a way I dislike, therefore Agile is terrible.

As a programmer, I _like_ working on small features and projects, and the variety that comes from taking on different types of work.

Long-term stuff is nice too, but despite what you might think, not everyone gets excited about the same things you do.

 _often disallowed to work on improvements that can't be related to short- term, immediate business needs (often delivered from on-high)._

People being disallowed to work on core improvements happens in any kind of organization system.

Around here, we use "processes [that] promote sustainable development" and which allow us to "maintain a constant pace indefinitely." That means occasionally allocating people to refactor and improve the codebase, when the programmers feel that need and point it out.

 _Atomized user stories aren't good for engineers' careers._

Well, then it shouldn't be hard to show that engineers with Agile-based work experience have more difficulty getting hired. Is there evidence on that?

 _5\. Its purpose is to identify low performers, but it has an unacceptably false positive rate._

Absolutely no argument here. The constant tracking is demeaning and often counter-productive.

That said, I don't think Agile requires it, just specific implementations of it (like the aforementioned Scrum).

<comment><USER5> Agreed with many of your points - although I don't think that the purpose is to identify low performers, per se.

It's more about breaking down development into small chunks at a time, so that if there are performance (or specification, or other) issues, they can be dealt with quickly.

</comment></comment><comment><USER8> The best thing about this article is the linked book in the comments: "Agile: The Good, The Hype, and the Ugly". I suggest checking that out for a more nuanced view.

I think also the OP doesn't give agile/XP enough credit for the good things it has mainstreamed. For example:

\- Sustainable pace (don't work > 40 hours week). Agile companies, in my experience, tend to have good work/life balance.

\- Continuous integration. Release and integrate often.

</comment><comment><USER9> Having read ken schwaber's "agile Project management with scrum" something like 8 years ago and hearing him speak, and working with agile teams during my most junior development I couldn't fucking agree more. I loved scrum when I first started using it, and I was a horrible developer back then. I pity anyone who had to work with me.

This article was strangely heartwarming.

<comment><USER10> Interesting...my experience has been the opposite, largely due to the fact that the description of Agile/Scrum in this article is nothing like the way it was implemented in my last company. (We built our processes and goals based on the original Agile Manifesto.)

<comment><USER11> I would be very interested to hear you say more about your experience with Agile!

</comment></comment></comment><comment><USER12> To save repeating myself: [http://blog.binarymist.net/2014/01/25/essentials- for-creatin...](http://blog.binarymist.net/2014/01/25/essentials-for-creating- and-maintaining-a-high-performance-development-team/)

</comment><comment><USER5> This is a poor article on many levels. Even basic facts don't check out.

Agile didn't "grow up in web consulting", and it wasn't about dealing with finicky clients who couldn't be "managed". It came from enterprise both large and small, mostly not involved in web or consulting. In fact, it arguably started before _software development_ did - see Kanban at Toyota.

Agile _software development methodologies_ came from a real need to reduce the failure rate of software projects that was, even 10 years ago, closer to 50% than 0%. It attempted to provide ways to stop the _average_ software project from running nearly 50% over budget. It waged war on the "big design up front" methodology handed to us by other engineering fields and acknowledged that in the real world, software development is often a wicked problem ([http://en.wikipedia.org/wiki/Wicked_problem](http://en.wikipedia.org/wiki/Wicked_problem)) that cannot be solved until it is solved. It acknowledged that requirements change, and software takes such a long time to build, often by the time a large design is built it already doesn't do what it needs to.

Almost all the statements the author makes are misleading, or misguided.

Violent transparency? It's a good thing that helps software projects succeed.

Atomic little user stories? They embody the divide and conquer philosophy to break down the author's ambiguous "long-term projects" into small chunks that can be understood, tested, and estimated. And delivered _quickly_.

Shared ownership? Promotes respect of the team, organisation, and customer. Helps get rid of bat-cave developers who can't acknowledge genius other than their own. Helps diffuse any blame for failure.

Social organisation? Has little to do with agile methodologies and a lot to do with the enterprises that implement them. Some do it well, some don't. Scrum doesn't dictate that a product owner or Scrum Master is more important than the engineer. Contoso Shiny Widgets Inc. does that. Just like they dictate whether experience and skill are valuable in their teams, and whether they listen to their engineers about technical issues that cause the kind of technical debt that is hard to solve with "good design".

Exit strategy? Short term? What? Use an agile process when it makes sense. Stop using it when it makes sense. Of course the process is designed to be there forever - they're tools to be used by people trying to solve real problems. The nature of those problems changes over time.

Lack of R&D? Software development is prima facie the D. The R? It's entirely possible to do that in iterations. Agile processes certainly don't remove R&D - spikes are there almost exclusively for R, and they're a first class citizen in the process unlike pre-agile. Perhaps the author refers to those 'long- term' projects that more often than not end up nowhere?

Technical debt? The author doesn't understand agile at all. Agile has two main tools to help manage technical debt - fast feedback loops, and encouraging development in small vertical slices. The best agile has even more - <USER2> promotes TDD, not prematurely optimising, refactor mercilessly among other things. Basically universally accepted ways to improve the quality of software.

Crunch time? No! Agile promotes sustainable pace. To help avoid death marches. Heard of those? They've derailed careers for good.

I'm no big supporter of Scrum - it lacks the software design guidelines of e.g. XP, and it's been abused by some companies for their own purposes (probably those the author has worked for). But it has some fundamentally good ideas, and since Agile methods have been around enterprises small and large have improved on many measurable metrics. It's the best we currently have - come up with something better.

<comment><USER13> Well summarized. Especially appaling is that the author does identify agile concepts wrong. The sprint impediment is taken as a measure for weeding out low-performers. I am not really in the mood to look up an exact citation, but I have always understood the "impediments" to be external impediments, not team-internal ones. Its pretty lousy as a argumentation strategy to compare apple with pears. If this was the interpretation of scrum in that guys company, I feel really sorry for him.</comment></comment>