Deep-copying in JavaScript - ingve
https://dassur.ma/things/deep-copy/
======
andrewstuart
If you find yourself deep copying then you're about to level up your
JavaScript career.

The actual answer is not to find out how to deep copy reliably.

The actual answer is don't deep copy - instead you should be using immutable
data structure - check out immutablejs. This will solve the problems that you
are trying to address by deep copying.

Sticking with deep copying will only increase your pain and decrease your
software reliability.

~~~
Cthulhu_
Doesn't immutablejs do the deep copying itself?

Even better would be a language (could be plain JS) that enforces
immutability. How about a new keyword in Typescript?

~~~
littlestymaar
There's Object.freeze[1] for that. Of course that's checked only at runtime,
because js is a dynamic language …

[1] [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze)

------
streptomycin
"Deep copy" and "structured clone" are not synonymous. A structured clone is
one specific type of deep copy, and it has a variety of quirks. It's not clear
to me why anyone wants structured clone as opposed to some other kind of deep
copy, except if you were polyfilling some API that demands it like I did here
[https://github.com/dumbmatter/fakeIndexedDB](https://github.com/dumbmatter/fakeIndexedDB)

There are plenty of more reasonable deep clone functions available, for
instance the Lodash one someone posted in another comment
[https://lodash.com/docs/4.17.4#cloneDeep](https://lodash.com/docs/4.17.4#cloneDeep)

~~~
Sammi
I'd like to see the benchmark in the article include the lodash cloneDeep
function.

------
xamuel
The solutions presented fail if one of the values in obj is a function. E.g.,
JSON.parse(JSON.stringify({foo:x=>x})) returns {}.

It's not intuitively obvious what the "correct" solution ought to be. If
cloner is a deep-cloning function, and f is a function, which of the following
should be true?

1\. cloner(f) === f?

2\. For all ...args, cloner(f)(...args) === f(...args)?

3\. For all ...args, cloner(f)(...args) === cloner(f(...args))?

4\. For all ...args, cloner(f)(...args) === f(...args.map(cloner))?

5\. For all ...args, cloner(f)(...args) === cloner(f(...args.map(cloner)))?

6\. Something else entirely?

~~~
dassurma
Ohai. Author here. That’s indeed one of the trip-wires. So is that any kind of
prototype is lost.

The point of the structured clone algorithm is to make values transferable to
other realms, so functions are actively ignored. Most of the time, I think
that is “good enough”.

~~~
shkkmo
Can you fix your first statement: "JavaScript passes everything by reference"
which is incorrect?

see: [https://jsfiddle.net/t73ykuj0/](https://jsfiddle.net/t73ykuj0/)

~~~
zakember
Can you please explain why this behavior is happening in this jsfiddle, or
point me to a link that can help me understand this better?

~~~
shkkmo
The term for what Javascript does is pass-reference-by-value or pass-by-
sharing:

[https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sh...](https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sharing)

------
chatmasta
“Deep copy” is a code smell and attempts to implement it will lead to
pernicious bugs. Either you’re copying data, in which case it should be
serializable to and unseriazable from JSON, or you’re copying objects, in
which case you should think about what you’re really trying to achieve. There
is usually a better solution.

------
tlb
I use lodash.cloneDeep for this.
[https://lodash.com/docs/4.17.4#cloneDeep](https://lodash.com/docs/4.17.4#cloneDeep).
It has variants to munge the object while copying.

------
ricardobeat
Missing from the benchmarks is simple deep copying:

        function deepClone (obj) {
            var clone = {}
            for (var key in obj) {
                if (obj.hasOwnProperty(key)) {
                    var value = obj[key]
                    switch (Object.prototype.toString.call(value)) {
                        case '[object Object]': clone[key] = deepClone(obj[key]); break
                        case '[object Array]' : clone[key] = value.slice(0); break
                        default               : clone[key] = value
                    }
                }
            }
            return clone
        }

This is 5-10x faster than the JSON trick in WebKit:
[http://jsben.ch/W0ciO](http://jsben.ch/W0ciO)

(naive implementation, but covers 90% of uses, see lodash for the full mess:
[https://github.com/lodash/lodash/blob/master/.internal/baseC...](https://github.com/lodash/lodash/blob/master/.internal/baseClone.js))

~~~
drodgers
I believe that it's faster, but only because it's not actually deep-cloning.

This:

        value.slice(0);

is a shallow clone; it makes a new array, but doesn't clone it's contents.

~~~
ricardobeat
Hence being a 'naive' implementation. You can replace that with something like
`deepClone(value)` + implement copying for different types, ultimately you'll
end up with code like lodash's.

~~~
drodgers
It's not just naive though, it's wrong; it won't even give you new objects
although it seems like it's meant-to:

        a = [1, {foo: "bar"}];
        b = a.slice(0);

        b[1].foo = "baz";

        console.log(a)
        > [1, {foo: "baz"}]

        console.log(b)
        > [1, {foo: "baz"}]

A naive implementation would do this:

        case '[object Array]' : clone[key] = value.map((item) => deepClone(item)); break

And would thus be slower.

~~~
ricardobeat
We are in agreement here. My suggestion was to make the deepClone method also
take arrays, and walk through them copying values in the for loop
(significantly faster than map).

Again, I linked to a full implementation at the end; was more commenting on
the lack of this particular approach, wrote this on the spot as an example.

------
smt88
Because JS doesn't clone natively and library behavior varies somewhat, our
team has started to consider deep-copying and cloning to be a smell. It forces
the maintainer to figure out how exactly the copying/cloning is going to work,
and it also creates nasty bugs when modifying a class without knowing it'll be
copied or cloned somewhere.

We instead only use immutable, plain ("POCO" or "POJO" in other languages)
objects for data. If you want to copy an object, you have to call the same
functions to change it that you called on the original. If the functions are
deterministic (as they should be), then you get identical objects at the end.

Our code base is effectively functional, even though we still use objects as
our syntactic sugar (addOwner(car, user) becomes car.addOwner(user), etc.)

------
frwhlr
I think it is almost unbelievable that the ESxx train continues to expand the
language with ever more features, while at the same time there is still no
native method to deep-copy an object..

Almost everything in JS is an object, but there is no reliable way to copy
one.. Feels like an epic failure to me. Would it not be an idea for the ESxx
team to finally fix this core issue for the first upcoming release?

~~~
taco_emoji
Why is deep copy so essential? Deep copy is the wrong solution to your problem
99% of the time, IMO.

~~~
frwhlr
I think spamming mutable objects around in your codebase is asking for
trouble. I'd be really happy to be able to do something like this:

      foo( Object.copy(barObj) );

I mean, why would you send your state's mutable object as argument if you're
100% sure you don't want it to be changed?

~~~
taco_emoji
Because copying is expensive. If mutability is the issue, use Object.freeze(),
or define properties with Object.defineProperty() setting _writable_ to false.

------
kin
I would never deep copy using any of those methods. Can't you just write your
own recursive version? I remember plenty of examples on jsPerf (site not
working at the moment) including my own that significantly outperformed JSON
parse/stringify.

~~~
BinaryIdiot
Yeah I'm confused as most of those methods, like postMessage, stringifies
things anyway. I simply iterate other object properties to make a copy of a
full object.

I've never run performance tests but surely that's faster than parsing an
object into its string representation then parsing it back into the language,
no?

~~~
dassurma
As I explain in the article, postMessage does not stringify. It runs the
structural clone algorithm, as per spec. Otherwise things like ArrayBuffers,
Sets et al. would not make it to the other side.

------
tw1010
Tackling the toughest challenges of our generation.

------
takinola
For fun and games, try deep copying event objects. Spoiler alert: it doesn't
work in ways that are not immediately obvious. Hours of my life I will never
get back...

------
tobr
Is the `await` used in the last two examples a typo? They're not asynchronous
are they?

~~~
dassurma
So, it’s me being lazy and copy-pasting, but you can use await on synchronous
functions, too. It’s a no-op :D

~~~
phpnode
Not a no-op, it wraps the awaited value in `Promise.resolve()`:

       async function foo() {
          const a = await {then(resolve) { resolve(123); }};
          console.log(a);
        }
        foo();

~~~
pitaj
Indeed, you don't use `await` on functions either, it's used on promises. In
fact, when used on a non-promise, it still waits an extra loop cycle before
resolving and continuing the async function.

------
kevincennis
JavaScript is absolutely _not_ pass by reference.

        let a = 1;

        function foo( a ) {
          a = 2;
        }

        foo( a );

        console.log( a ); // 1

~~~
jerf
Nowadays, everything is pass-by-value. The only question is whether a
reference or a pointer is one of the things that can be passed by value, or if
everything passed is always a copy.

An exception to pass-by-value would be Forth; in the case of stack-based
languages there really isn't a "pass" going on at all. But everything copies
_something_ for every non-inlined function call nowadays. Another instance
where it's less obvious what is going on is a truly immutable language like
Erlang or Haskell, where the "value" is quite likely still being passed via a
pointer, but that's only relevant from the point of view of considering
garbage collection behavior.

This makes the old "pass-by-value vs pass-by-reference" terminology vestigial
to the modern software engineer, which is why the only place you'll encounter
it is in school courses. A better way of understanding the modern issues is to
ask what powers a passed-in value has and just ignore the old question.

~~~
kmill
Off the top of my head, here are languages in use that have a feature for
pass-by-reference semantics: C#, Ada, C++ (though in this language you can get
ahold of the reference as a value if you want).

Of course, to implement pass by reference, you tend to have to pass pointers
around, but the point is that the language gives the illusion that the
identifiers within a function's scope _are_ locations specified by the caller.

I guess a takeaway is that in designing a language, one has to consider the
relationship between an identifier, the mutable cell associated with the
identifier, and the value stored in that cell. It seem that in common
languages the identifier refers to the cell, but if the identifier is used in
a value context, it evaluates to the value in the cell. Languages with pass-
by-reference semantics let you make your own & function, so to speak.

(A weird example in C of this relationship is that an identifier for an array
refers to a cell that contains the whole array, but, if you use the identifier
in a value context, it becomes a pointer to the first element. One aspect of
it not actually being a pointer is that you cannot replace its value with the
pointer to another array.)

Anyway, an everything-must-be-a-first-class-object hard-liner would insist
that pass-by-reference is the way of the past. But, sometimes it is not
economical to get everything to be a first-class object. For instance, you
might decide it is not worth trying to create a pointer type for referring to
members of a packed struct, but it is not too hard to make a pass-by-reference
feature for this (via copying).

~~~
Roboprog
Pascal “var” parameters. Pascal is rarely used any more, but I suppose it’s no
more obscure than Ada.

------
heisenbit
How does inmutable-js fit into this discussion? My limited understanding is it
defers the copy decision and then can limit it to the area needed. Wouldn't
that lead in most cases to a better performance?

~~~
dlbucci
If you have immutable objects (doesn't even have to be ImmutableJS, you can
just decide to never mutate object properties), then there's really not even a
need for cloning at that point. The reason you would clone an object is to
avoid mutating the original object, which you don't need to worry about when
everything is immutable.

~~~
DiThi
Except that you need to copy _something_ at some point to modify values (or
more precisely, having another object that is the same but with X change). In
theory everything is re-created with a change, but in practice only the
changed objects are copied.

------
xg15
Somewhat OT:

If you click through, you can find the original Twitter conversation that
prompted this posting [1]. In that conversation, an interesting point about
"optimizing away" string representations was brought up: [2, 3]

> _Interesting! How is this better or worse than the usual trick of
> `JSON.parse(JSON.stringify(obj))` ?

(...)

My idea was that the browser could detect that the string is immediately
parsed anyway and just interpret the two function calls as "deep copy this
object for me"._

I had thought about somethig like this in the context of innerHTML a whole
ago. Generally, there are a lot of places in the DOM where can modify an
object not by setting properties, but by _getting a string representation of
the object, modifying that string, then feeding the new string back to the
browser for reparsing_. Examples are document.cookie, css properties and of
course innerHTML.

In those cases, an optimisation like the above sounds like it could actually
make sense.

E.g., if someone abused innerHTML like this:

      for (let i = 0; i < data.length; i++) {
        myList.innerHTML = myList.innerHTML + "<li>" + data[i] + "</li>";
        doSomethingWith(myList.lastChild);
      }

a naive implementation would have to serialize, parse and recreate the whole
object tree for each iteration of the list. However you could probably
optimize it by having innerHTML return some special object that only "looks"
like a string but somehow keeps track of its mutations internally. When the
object is fed back to innerHTML later, the browser could use the internal
properties to mutate the DOM instead of recreating it.

I'm curious, does anyone know if optimisations like this are actually used?

[1]
[https://twitter.com/DasSurma/status/955484341358022657](https://twitter.com/DasSurma/status/955484341358022657)

[2]
[https://twitter.com/sergiomdgomes/status/955484966313488384](https://twitter.com/sergiomdgomes/status/955484966313488384)

[3]
[https://twitter.com/moritz_kn/status/956444334970343424](https://twitter.com/moritz_kn/status/956444334970343424)

------
codeisawesome
> If you don’t expect cyclic objects and don’t need to preserve built-in
> types, you get the fastest clone across all browsers by using
> JSON.parse(JSON.stringify()), which I found quite surprising.

I wonder if that’s because browser devs know by now that this is a widely used
technique and hence optimise for it.

~~~
Havelock
I suspect it is because JSON.parse and JSON.stringify are more commonly used
methods and therefore see more optimization than methods use less.

------
peter_retief
I was surprised how difficult it was to make a deep copy with javascript, (I
did try JSON.parse) but finally decided to rewrite the logic without deep
copy. Its a great article, shed some light on an interesting programming
question

------
klokoman
In some cases you can assign the object you want to copy as the [[prototype]]
of another object, this way you delegate what you don't want to change and
change what you want in the "copy" via assignments

------
Stratoscope
On the "pass by value" vs. "pass by reference" controversy, I see two issues
here:

First, these terms have specific meaning in other languages such as C++, but
JavaScript's behavior does not match either of their definitions.

Second, there is a widespread myth that JavaScript passes primitive values and
objects in two different ways. It doesn't. They work exactly the same, and
making an artificial distinction between them is not useful.

I find it helpful to make up some new terminology, so my thinking isn't led
astray by implied comparisons with other languages. I like to talk about
_names_ and _things_.

A _name_ is a variable name or a parameter name.

A _thing_ is any object or primitive value: anything that you can pass as a
function argument or use on the right side of an assignment operator.

A name always refers to one thing. A thing can have multiple names.

When you pass an argument into a function, or when you use the assignment
operator, you are giving a new name to an existing thing. If the name already
referred to some other thing, that connection is lost. The name now refers to
the new thing, and only to the new thing.

Everything works this way, primitives and objects alike.

The reason it's often claimed that objects are passed into a function by
reference, while primitives are passed by value, is that we instinctively
write _different code_ for the two cases. That different code is what leads to
the notion that objects and primitives are treated differently.

If you pass an object into a function and you want to add or change a property
of that object, you'll naturally write:

      function foo( obj ) {
          obj.myprop = 42;
      }

But if you know the function is going to receive a primitive value, you won't
write this:

      function foo( val ) {
          val.myprop = 42;
      }

If you do, you'll find out soon enough that it won't work. It will throw an
exception in strict mode, or fail silently in non-strict mode.

Instead you may write:

      function foo( val ) {
          // Do stuff here with val
          val = 42;
          // Do stuff here with the *new* val, which isn't the old val
      }

The reason the functions behave differently is not because JavaScript passes
primitives and objects differently. It doesn't; they are all treated the same.

But primitives are _immutable_. They have no properties that we can change. We
know that, or we find out if we try, so we simply don't write code that tries
to change a property of a primitive value.

It isn't the JavaScript language that treats objects vs. primitives
differently when passed into a function or when used in an assignment
statement. We programmers do, by writing different code for the two.

(Edited for clarity)

~~~
shkkmo
> The reason the functions behave differently is not because JavaScript passes
> primitives and objects differently. It doesn't; they are all treated the
> same.

>The reason is that primitives are immutable

This is incorrect. See:
[https://jsfiddle.net/t73ykuj0/](https://jsfiddle.net/t73ykuj0/)

The reason is that javascript uses "pass-reference-by-value" not "pass-by-
reference"

edit: The immutability of primitives is why the "pass-reference-by-value"
behavior of javascript works like "pass-by-value" for primitives (and for
immutable objects).

~~~
Stratoscope
I think we are saying the same thing. Your term "pass reference by value" is
the same as what I called "give a new name to an existing thing".

I simply like to avoid the terms "pass by reference" and "pass by value" to
avoid comparison with other languages. But if you want to use "reference" and
"value", then your term "pass a reference by value" is a good description of
how it works - both for objects and primitives.

Coincidentally, just before I saw your comment I changed what I said about
"The reason is that primitives are immutable" to make it more clear.

The real reason is that we instinctively write different code for the two. If
a function parameter named 'val' is a primitive, we're not going to try to
change a property on it. If we do, it won't work, because the primitive is
immutable. (That's the point I was trying to get at with my original comment.)
The same would be true, of course, with an immutable object.

And when we pass an object into a function, we _may_ reassign the name
completely inside the function, as in the mutatePassByReference() function in
your fiddle, but more likely we will write code that manipulates its
properties, as in your mutatePassReferenceByValue().

So the immutability of primitives isn't the direct cause of what is sometimes
thought of as different behavior for objects and primitives. It's an indirect
cause, because it leads us to naturally write different code for the two.

That's what I was really trying to get at (in my usual long-winded way):
JavaScript doesn't treat objects and primitives differently, we programmers
do.

~~~
shkkmo
> I think we are saying the same thing. Your term "pass reference by value" is
> the same as what I called "give a new name to an existing thing".

>I simply like to avoid the terms "pass by reference" and "pass by value" to
avoid comparison with other languages.

The terms mean the same thing in every language. Some people (as shown in the
article and this thread) don't understand what "pass-by-reference" means and
incorrectly use it to apply to javascript.

The pass-reference-by-value behavior is shared by a lot of languages, I'm not
sure why you want to avoid comparison with them.

~~~
Stratoscope
> The pass-reference-by-value behavior is shared by a lot of languages, I'm
> not sure why you want to avoid comparison with them.

That's a fair point. I just think a lot of JavaScript programmers are confused
about this, and end up thinking that primitives and objects are passed in two
different ways. Even MDN makes this mistake:

[https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Guid...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Guide/Functions)

My use of "things" and "names" is just an attempt to get away from this
confusion.

------
tobyhinloopen
This is why JavaScript is the biggest joke of web development. And error
handling.

Can we please stop using it

------
potch
JavaScript is pass-by-reference for all Objects and Arrays. Value types are
pass-by-value.

        let obj = {a: 1}

        function foo(arg) {
          return obj === arg;
        }

        foo(obj) // true

The === operator operates on object not by comparing their value, but by
comparing their memory reference [1]. A function argument variable can be
reassigned using = in the function body, but that changes which location in
memory the reference points to and isn't somehow "proof" of pass-by-value.

[1] [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Operators/Comparison_Operators#Equality_operators)

~~~
shkkmo
Javascript is pass-reference-by-value for Objects and Arrays, see:
[https://jsfiddle.net/t73ykuj0/](https://jsfiddle.net/t73ykuj0/)

If javascript was pass-by-reference for Objects, your code could read: arg =
{a: 2}; return obj === arg;

and still behave the same.


How to Learn Any (Technical, Programming, Other) Subject in 7 Days - andre
http://okdork.com/2007/05/30/how-to-learn-any-subject-in-7-days/
======
abstractbill
If only I had read this _before_ I started the PhD. It would have only taken 7
days!

cf. Norvig's essay: <http://norvig.com/21-days.html>

~~~
machine
For real. If only the world really worked this way. Even programming languages
take a bit longer than a week to really learn. I find I go through at least
two levels with a programming language: the first at which I know the syntax
and can code small projects comfortably (this takes about a week), the next at
which I have developed a personal coding style that works well with language
and allows me to handle large projects (this takes at least 6 months or so of
regular coding).

------
inklesspen
Step 1) Read an introductory text Step 2) Do stuff with what you read

Is this news?

~~~
staunch
You forgot: Step 3) Significantly overestimate what you've learned.

------
crxnamja
@inklesspen

Make sure to do it fast!


New Zealand admits illegally spying on Megaupload founder Kim Dotcom - 8ig8
http://worldnews.nbcnews.com/_news/2012/09/27/14120478-new-zealand-admits-illegally-spying-on-megaupload-founder-kim-dotcom?lite

======
beedogs
This is my surprised face.

Other western countries do what is asked of them when the US comes calling.

~~~
dmm
The US government is the last true sovereign.

~~~
tomjen3
RIAA is the last true sovereign.

------
rolux
In other news, New Zealand's prime minister seems to have issued a public
apology to Kim Dotcom:

[https://torrentfreak.com/new-zealand-prime-minister-
apologiz...](https://torrentfreak.com/new-zealand-prime-minister-apologizes-
to-kim-dotcom-120927/)

------
OhArgh
Ah but New Zealand still doesn't let the US nuclear powered ships in their
waters! <http://en.wikipedia.org/wiki/Nuclear-free_zone#New_Zealand>

Why should they fold to the US government who is basically being controlled by
the media industry?

There is a process to get someone extradited it should be followed

------
nvmc
Our government has been at the beck and call of the White House ever since
they came to power. Key is financier, a snake.

------
mikerice
Rule #1 of spying: Never admit to it.

------
briandear
The real question: is Dotcom innocent of his alleged crimes? The real story is
that if Dotcom was facilitating piracy. The technicality of if he was wire
tapped illegally or not is important in theory, but it comes down to this:
Dotcom would not be in trouble if he hadn't broken the law. If he was
innocent, then this would be a big story. This is similar to someone caught in
video robbing a store but beating the charge because of a technicality.

Criminals winning cases on technicalities while still having committed the
crime is not justice. Justice is getting punished for crimes actually
committed. Justice is when innocent people are acquitted of crimes they did
not commit.

Turning Dotcom into somekind of folk hero is ridiculous. He became very
wealthy by facilitating theft. It isn't like he was donating the proceeds to
build schools for girls in Afghanistan. If he broke a potentially unfair law
as a statement and did it for something other than getting rich, maybe then we
could consider him something other than what he is -- a self-serving criminal.

~~~
ixnu
"Justice is getting punished for crimes actually committed."

A government's complete disregard for due process is a far greater crime than
piracy.

The punishment for this crime is "[c]riminals winning cases on
technicalities".

~~~
drivingmenuts
> The punishment for this crime is "[c]riminals winning cases on
> technicalities".

I disagree. The punishment is to find the person or persons responsible and,
at a minimum, fire them. That should serve as a warning to others that you
either do it right, or not at all.

The "[c]riminals winning cases on technicalities" is a side-effect of
erroneous judgement.

~~~
freehunter
I would argue that, in the US at least, criminals winning on technicalities is
_not_ a side effect. It is a direct punishment of the government not following
proper procedure. Authorities cannot illegally search your home because if
they do they forfeit the right to use that evidence. If that repercussion was
not in place, there would be no incentive for the government to actually
follow the law.

Do it right or you lose the case. That's the deal.


Growing By Shrinking - peteforde
http://hackertourism.com/post/44454709336/growing-by-shrinking
======
codewright
I identify with, and am seeking for myself, a lot of things described here.

That said, the author is speaking from an intensely privileged point of view.
Referring to selling one's time as a programmer as 'whoring' caused me to
cringe.

I have strong aversion to growth for growth's sake now that I've lived and
worked in Silicon Valley and the startups that go with it (I was CTO at a
nutrition startup).

Things I've done recently:

1\. Quit my job and went back to being an independent consultant. Looking to
start a product company in the gap time between contracts.

2\. Exercising more, in my case, 6 times a week minimum as well.

The real question is whether or not I'll be able to make something that bears
revenue fruit or not. I've had small bits of success here and there before but
nothing substantial or lasting. Current side project is just me scratching an
itch, no real revenue potential.

I've been reading a lot in an attempt to learn as much as I can and prepare
myself to be able to make something profitable. Mostly marketing and sales
books, about to do another read-through of Patio11's stuff again.

Can anyone tell me what the aspiring micro-ISV/self-employed entrepreneur
_really_ needs to know in order to get ramen profitable? I know I need to
build and experiment quickly - what else?

Edit:

My book log: <http://bitemyapp.com/post/book-log-1/>

I agree with orangethirty's "start selling". I just need to hoof it and do it.
Not about to stop reading though :)

~~~
peteforde
Fair point re: whoring, so far as we might have to agree to disagree.

Let me explain differently by saying that when I was young, I wanted nothing
more than to get paid to program. I loved to code, and I needed to get paid —
professional coding was the obvious answer.

The problem was that by my mid-20s I was really sad all of the time, and my
work was at the root of it. I was programming and getting paid, yet the more
work I did the worse I felt. I thought I had fallen out of love with coding.

One day it hit me like a lightning bolt: the reason you do something directly
impacts whether you enjoy doing it.

Being a prostitute seems like it would be awesome. You get laid constantly and
people throw money at you, right? Well, only if you ignore that you don't have
any control of who, when, how, why or where in many cases. Awesome becomes
terrible.

I get the same joy from coding that a painter gets from painting. A painter
that can paint what, when, how, why and where they want is likely happy. A
painter that has to paint what other people want on a schedule is often just
struggling to pay the rent. They develop a toxic relationship with their art,
and that's sad.

So yeah, I have had some great programming clients and worked on some really
interesting code projects for money, but in the end it wasn't worth the
sadness that my body was literally fighting back against. I was fat and sick
all of the time, everything seemed like it was getting worse. I was
disconnected from the chi.

However you want to describe it, everything started getting better as soon as
I stopped doing it for other people.

~~~
anu_gupta
So, instead of whoring your developer skills, you're whoring your technical
knowledge?

~~~
peteforde
I'm not whoring my technical knowledge. I discovered that I really enjoy
sharing it, and it's a happy coincidence that people are excited to pay for
it.

------
seivan
I agree with you. A small team of founders that are just developers who can
design will outbeat ANYTHING that might have some VC money behind it.

You don't need business monkeys, or "UX experts" who can't code their JS/CSS.
I hate it when iOS positions already have a lead designer who can't do Cocoa.
It's such stupid notion. It's like saying we're looking for a CSS developer,
we already have a lead HTML developer.

iOS products are logic + design. And a developer who can design is far more
useful, cheaper and faster than a developer + ux monkey.

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

"I like programming a lot. If I'm away from it for more than a couple weeks, I
start to miss it.

The software industry deserves to choke on a dick and die, however. Fuck bad
code, micromanagers, dopey "startups" that expect 14-hour days on the
assumption that 0.0x equity slices represent real "ownership", closed
allocation, and regimes in which programmers don't choose their tools. All of
that can go to hell.

As software engineers, we're a defeated tribe. We work for businessmen, get
little respect in comparison to the value we add, and often are pigeonholed
into roles that are 3 levels below our creative and intellectual ability. We
do most of our work for managers and investors who think we're losers because
we don't have their jobs. To me, quitting programming is just running away.
Programming was never the problem. We need to take control of this game. We
need to take it back and make it good-- and fast."

Let the downvotes commence.

~~~
guylhem
Sorry to deceive you but when I see the truth, I can only upvote it.

There is a lot of cruft in many businesses - so much inefficiency, that it can
hardly be removed by joining in their ride. The software industry is not
immune to that.

Therefore it just is more logical to do something by yourself.

After all, there are only 2 possibles outcomes - you do bring value, which
will be rewarded by the market, or you don't - and at least, it won't last too
long. Unefficiency is a pain.

Create your business. Sink or swim, with the added advantage (schadenfreude ?)
of watching the inefficient ones drown while you swim around.

There no personal hate involved- I don't hate them, and in fact I may even
feel sorry. It's the inefficiency that I hate.

~~~
FourthProtocol
It's not that simple. My forever project (started in 2004) needs another month
or so of polish, but after stripping out many features to ship a version one,
is pretty much ready.

Build it and they will come doesn't work. I need paying customers, and being
the type that works best when writing code (alone!), I'm about to start
exploring options to find someone to market this thing for me, and turn my
spare time over the last 9 years into something that makes real money.

~~~
peteforde
But did you enjoy building your project? Did you learn from it or benefit in
other ways?

It's most likely that you won't recoup on your investment if you only see this
in financial terms. If you expand your definition of success it is possible
that you have already succeeded.

~~~
FourthProtocol
Yes, I've already succeeded. And whether I've learnt from it or not (I have)
is secondary to the fun I've had with it.

The money, any money is just a logical next step to a project that will never
die, regardless of it's commercial success or failure.

------
bdunn
Ditto. I gave up lucrative, decently sized consultancy to go solo.

Before: Long commute to my office from the suburbs, 10+ hour workdays, lots of
stress, kids would be asleep when I get home. After: 30 second commute
upstairs, work out daily, lots of sunshine and bike rides to the park, etc.

I wrote about it here: [http://planscope.io/blog/giving-up-a-million-dollar-
consulta...](http://planscope.io/blog/giving-up-a-million-dollar-consultancy/)

------
pmorici
I'm confused first he says, "I’M DONE WITH WRITING CODE FOR OTHER PEOPLE.",
but two paragraphs later he says, "All of my work comes by referral now, and I
have an agent". So what exactly is he saying? That he just does other kinds of
work besides software development now?

If that is the case then why is one 'whoring one self out' and the other is
not?

~~~
mrbgty
Well of course it sounds bad when you put it that way (using all caps when
quoting him)

~~~
lindenr
What? In the original it was written in all caps as well.

~~~
peteforde
Disclaimer: I'm not a type expert.

It's technically not _written_ in all caps, the font that my blog theme uses
for bolding renders as capital letters.

My personal jury is out on whether this is okay or not. Your comment leans me
towards "no".

~~~
lindenr
It does seem a bit more forceful than bold to me; maybe you could have a
separate 'bold' font and a 'really really bold' font?

------
noelwelsh
Sounds great, but let's be realistic here: it's the N years of consultancy
that allow this fantastic lifestyle, because it is the network built then that
is being leveraged now. In other words, as fantastic as this lifestyle sounds
(and it really does sound fantastic!) it's not something you can just jump
into.

~~~
AznHisoka
Yep. He calls coding for other ppl "whoring".. but he seems to forget that
people pay you to do EXACTLY what others won't or can't do. If other people
enjoy it as much as they enjoy sex, you wouldn't get paid a ton

~~~
peteforde
If you enjoy coding for other people as much as you enjoy coding your own
projects, then we are wired very differently - and that's just fine.

However, I have found that many of the things I used to think everyone could
do are in fact skills that I now get paid to use because they can't do them.
Go figure.

~~~
shawn-butler
What can you tell me about the "agent". Are you paying him or her or is it a
commission basis? How did you find someone you could trust?

~~~
peteforde
Ted Pearlman (<http://usistwo.com/>) approached me, and I listened because he
had an interesting opportunity that was relevant to my interests. He was also
referred directly by Hampton Catlin, who I used to run a company with. After
jumping on Skype with Ted, it was clear that we would be friends.

I'd prefer to let Ted discuss how he is paid, but I will point you to his
Pudding Manifesto:

<http://puddingmanifesto.org/>

------
yesimahuman
This quote spoke to me:

> "Unspace was a convenient umbrella; an excuse for three friends with
> complimentary skill sets to share a small office"

In a lot of ways my company right now is just an excuse for me and my best
friend to build cool software together and have our own office. It just turns
out the money is coming with it and we are able to build a real business out
of it.

We've had chances to raise money and grow but we know deep in our hearts it's
not what we want. It was hard to be "okay" with this because everyone throws
the VC stuff at you and makes you think you should be "going big" and killing
yourself at 25. Understanding and being confident that we could still be a
"big", important, and profitable company in our space by doing it "our way"
has been a really big milestone of our personal and professional growth.

Great post.

~~~
peteforde
There's a really amazing moment in "An Evening With Kevin Smith" (highly
recommended!) where he recounts meeting some dick producer who admonished him
over concerns of practicality.

"Kevin, making movies isn't about getting together with your friends and
having a good time!"

[Pauses] "It isn't?"

------
saravk
Nice. Congrats on your move. I wrote a similar post exactly 2 years earlier
when i decided to downshift from my job of about 10 years and go live in the
mountains doing photography <http://www.kettik.com/go/articles/16>. Reading
your post made me go down the memory lane and examine my own journey.

Fast forward 2 years and i have very mixed feelings about the whole thing.
Monetarily its been a complete flop, failing to earn even a single paise in
the past 2 years. But spiritually, the memories and experiences gathered along
the way have been priceless. Sounds like a classic Mastercard ad, doesn't it
:D

All this experience did motivate me to create my startup. I have to say that i
totally resonate with your "the only code I write will be for my personal
projects" line. It feels more fulfilling this way. But ofcourse there is no
guarantee that this would arrest the rapid depletion of my bank balance (as
opposed to taking up parttime consulting gigs). Only time will tell.

~~~
peteforde
Coincidentally, I also love photography.

What I'm not sure about from your comment is whether you intended to do
photography for money or because you loved doing it (or both!)

I made a decision a long time ago that I would never allow myself to be hired
to take photographs, for all of the reasons around what we're discussing. I
want to keep photography as something I do out of love.

It was a very smart decision to make.

~~~
saravk
I intended to do photography so that i could make a living doing something i
loved. It seemed a great idea at that time.

But while i loved the process of taking the photos (i do mostly landscapes,
which basically involves patiently waiting for something magical to happen
<http://saravk.kettik.com/go/photos>), i didn't quite enjoy the process of
turning that hobby into an income generating endeavour. So i guess i finally
came to the same realization as you did. To keep my passion and profession
separate.

I also realised that i didn't lose my love for coding, especially when working
on my own projects. So i'am now working on a solution for my original problem.
To find a way to help travellers create, share and monetize their content.

------
RyanZAG
Best thing I have read in months. Bravo!

I've done similar stuff, and I'm in a similar situation to yours - although
I'm only at ~8 years and not 15. I also get all of my work from referrals,
although I participate in (paying) startups too - on my own terms - and drop
it if it moves away from what I'm interested in doing.

Never been happier.

~~~
peteforde
Hey - if it took you 8 years instead of 15, that's a good thing! :)

------
brador
Isn't the point of quick growth to work hard in your early years and retire
early? Sell, IPO, or just plain bank.

Yes, you could have a happier life if you worked at a more relaxed pace
(there's a guy on HN who works 3, holidays 9), but you'll most likely be
working for longer. Wanting to work for longer assumes you will remain fit to
work for all those years, mentally and physically. That's not as guaranteed as
you'd probably like to think at 25.

My advice: Push yourself, but keep a sharp eye on life balance.

~~~
kayoone
That assumes working extra hard in your younger years makes you rich before
30, which in a vast majority of cases does not happen, no matter if you work
for a startup, bigco or on your own.

~~~
brador
Rich or comfortable wealth or your own personal limits?

You can retire to a lifetime of minimum wage and no more work ever for just
$200k. A good software engineer could back that up in under 5 years. Play
video games all day stress free till death if that's your thing. (not
recommended).

~~~
guylhem
Indeed, not recommended - I'd call that just waiting for death.

------
mitmads
Best phrase "optimize for happiness instead of money" !!!


Apple Contractors Allegedly Listened to 1,000 Siri Recordings a Day – Each - innovateee
https://www.theverge.com/2019/8/23/20830120/apple-contractors-siri-recordings-listening-1000-a-day-globetech-microsoft-cortana
======
mkl
Previous discussion:
[https://news.ycombinator.com/item?id=20788463](https://news.ycombinator.com/item?id=20788463)

------
herohamp
Am I supposed to be shocked by this? Literally every company that makes
similar things does it. It's important for making the voice assistants better


A Tender Hand in the Presence of Death - wallflower
http://www.newyorker.com/magazine/2016/07/11/the-work-of-a-hospice-nurse
======
keithflower
The rotation I did through a hospice service when I was a fourth year medical
student was one of the most meaningful experiences of my life.

Hospice staff are experts at effective pain-wrangling (pain in all its many
manifestations), and, as they say, in helping people _live_ until they die.

I'm grateful for the teaching - from both clinicians and patients.

------
ggamecrazy
I do wonder sometimes if it's a gift or a curse to know that your eventual
death is coming soon. Death is such a weird concept that at least I personally
feel I lack the hardware to fully comprehend or be at peace with (as of right
now anyway).

~~~
pavlov
I try to think of it as something that will feel like falling asleep. I don't
dread sleeping, so I shouldn't dread dying either.

~~~
mikeash
I'm not afraid of death, although I hope mine is delayed a long time for the
sake of my family. I am, however, afraid of _dying_ , which is often a long
and painful process.

~~~
pavlov
Fair point. Everybody hopes they can go swiftly into the good night.

Isn't the fearsome part of dying just the pain and sickness though? Those
things can exist as a chronic state that doesn't lead to death, so I'm not
sure it's dying that one should be afraid of...

In some countries like Belgium, unbearable pain that doesn't lead to death is
sufficient cause for an individual to be granted assisted suicide performed by
medical professionals.

~~~
mikeash
That's a good point, the two don't have to be linked. I always think of them
together, I imagine because so I've seen so many people die slowly, and
relatively few end up with horrible chronic afflictions that still let them
survive for a long time.

------
bb101
In a world filled with fast money, quick soundbites, greedy startups and
selfish individualism, it's heartening to read that people like Heather exist
- quietly and patiently showing us what really matters.


Most startup theory is ex-post, therefore bs - shafyy
https://shafyy.com/post/startup-theory-ex-post/
======
zby
The primary social function of giving advice is a domination game
([http://www.overcomingbias.com/2015/03/advice-shows-
status.ht...](http://www.overcomingbias.com/2015/03/advice-shows-status.html),
[http://www.overcomingbias.com/2014/01/advice-isnt-about-
info...](http://www.overcomingbias.com/2014/01/advice-isnt-about-info.html)) -
that's why there is a lot of shitty advice. That does not mean there are no
good business theories that cover startups. Some of them are scientific
theories with all the required rigour - but not all theories need to be
properly scientific to be useful, in our daily life we live with lots of ex-
post theories, they are not perfect but are still useful. By the way I am the
author of one non-scientific startup theory myself
[https://medium.com/hackernoon/aggregators-
bffd36063a72](https://medium.com/hackernoon/aggregators-bffd36063a72) and I
hope it can be useful:) There are also useful advice. It is good to read them,
evaluate, adjust them you your circumstances, etc. In the end you need to
decide for yourself, but they show you the possibilities.

~~~
bigred100
I hate this interpretation of everything as status games. It seems like a
great way to drive yourself insane and develop mental illness as you overreact
to mundane situations or fail to take advice from proper authorities. I
consider somebody unqualified throwing out nonsensical advice as simply kind
of a moron.

To elaborate: I’m convinced that most people viewing this view status as a
good or at worse neutral thing, and although they may not approve of tactics
they deem immoral (maybe including this one), basically have some admiration
for “winning” the game. I view this as a wrong approach. The guy giving advice
all the time is blinded by pride and fails to realize even the bounds of his
own competence. He’s not winning anything. My opinion is that he looks like a
buffoon.

------
tlb
Not all ex-post theories are BS. For example, I slam my hand in the drawer and
theorize, "Slamming hands in drawers hurts; one should not do it." That theory
is pretty solid. It doesn't cover all the edge cases, but following it is
better than not following it.

There are lots of startup theories that are equally solid, despite being ex-
post. I know a startup that didn't pay payroll tax for a couple years, and it
ended badly. The resulting advice is pretty obvious.

There are theories about how to hire, how to find customers, how to negotiate
deals. These theories might not apply in every single case, but you should
definitely start by knowing what worked in the past.

This post picks a couple of unsupported startup theories, but it's sort of
like criticizing physics for the 1% of reality it can't explain and ignoring
the 99% it can.

~~~
chibg10
The difference is the prior.

There's strong prior reason to believe not paying payroll tax is not going to
end well. The theoretical basis is simple, clear, well-reasoned, and supported
by strong evidence in adjacent realms (i.e. the IRS takes taxes taxes pretty
seriously).

Whereas the prior on the validity of something like "early-stage founders
should live with their customers" is much weaker.

Even though the advice for each presented example is based on sample size n=1,
the resulting belief can and should be quite different depending on your
prior.

The real meta-advice is to be able to understand and evaluate your prior for
any given piece of advice you receive. This mostly comes down to thinking
rationally, being knowledgeable, and critically considering each piece of
advice for whether it's worth heeding or not.

Which is not so far from the author's message I think ("figure everything out
yourself", "I don't mean to say don't take any advice").

(Obligatory shout-out to Bayes Theorem)

~~~
nostrademons
> Whereas the prior on the validity of something like "early-stage founders
> should live with their customers" is much weaker.

There's a pretty strong theoretical reason for that as well: startups succeed
because they make something customers want; the more time the person making
product decisions spends with times with customers, the more information they
can gather about what the customers want; and the more the customer trusts and
has a rapport with the founder, the more willing they'll be to share candid
feedback.

There are some practical problems that make living with your customers a
little problematic if you're not Brian Chesky, namely that they may not want
another roommate, you may not want a roommate, they or you may already have a
family, or you might just get on each others' nerves.

But if you extend the general principle to "spend a lot of time with your
users" (and being able to extend to a general principle is a big advantage of
having theoretical reasoning), there are a lot of other companies that have
found similar success. Facebook was another one where the founder literally
lived with his first users. Google, for all intents and purposes, lived with
their first users (it's grad school, after all). DropBox, Reddit, and
Instacart _were_ their first users. Apple, Stripe, Clerky, Twitch, etc. were
in regular contact with their first users.

~~~
Retric
That’s an overly wide definition of living with your customers to be useful.
Apple for example was selling people kit computers at the start, they did not
really have much interaction with or feedback from their customers. Nor could
they do much to adapt their product with customer feedback.

I mean if all you mean is have even a tiny amount feedback from a few of your
customers. That’s going to include almost every company.

~~~
unscaled
Their first customers were microcomputer enthusiasts and both Steves were
members of the Homebrew Computer club, and Woz built Apple I with continuous
feedback from the club meetings.

I would argue that it's moving to the Apple II (were they suddenly lost this
direct feedback because of the vast expansion of their customer base well
beyond their reach.

------
hinkley
I have had a couple of managers over the years who had dreams of writing a
book, and with the exception of one, they were all mostly wrong about the
secrets of their success. They didn't have any awareness of how their team and
especially their leads supported them. Responses varied from humor to hurt
feelings.

Ask the people who work for them why the team was successful. They'll probably
have very different opinions.

~~~
monocasa
Would you mind expanding on their respective theses? I can see a lot of value
in looking at these in a anti-pattern kind of way.

~~~
hinkley
You know, it's funny for all of things I can enumerate on 'how not to do
something', there are some pretty big areas where I either don't keep score or
tear up the scorecard the moment I don't work there anymore. In this case
probably the latter.

The guy I said did have it figured out? I'd like to retract that. He wanted to
think of the process of moving stories from the backlog to done as a physics
problem. As managers go he was fairly emotionally sophisticated, but that was
his big blindspot.

Some of the others had elements of 'mushroom management' (keep them in the
dark and feed them bullshit), and a lot of quick fix-feeling techniques. Those
can be helpful in small doses, as long as someone else is beating a drum for
technical excellence (not perfectionism, but get stuff done, keep it done, and
keep getting stuff done).

------
drblast
It's fun to read older business books like Built to Last and Good to Great
that use the "let's study successful businesses to see what they do"
methodology. It's fun because many of the companies featured in those books
either are bankrupt today or facing some sort of existential difficulty.

It's survivor bias bullshit wrapped up in feel-good propaganda and people eat
it up every time. Study successful people and emulate them. Of course! How
could we go wrong?

Nevermind that the successful people are more likely to just be lucky or even
just plain wrong about the reasons for their success.

I attribute my success to hard work, getting up early, making steady progress
every day, picking great people to work with, and staying ahead of the curve.
Sounds great, right? But to really know if any of that matters, we have to
study a large number of people who also profess to do exactly those things and
see if they're way more successful than average. If they're not...well then
I'm just wrong about the reasons for my own success and other factors are more
important.

It doesn't sell books though when your message is "in order to be successful
you have to be naturally smart, tall, and attractive, work about as hard as
everyone else, and be well-connected and lucky."

~~~
lifeisstillgood

       in order to be successful you have to be naturally smart, tall, and attractive, work about as hard as everyone else, and be well-connected and lucky."

I can write a short pithy book on that one :-)

------
solresol
I'm surprised nobody has mentioned the QUT CAUSEE study. They actually did
follow a group of early-stage startups, interviewing them each year and then
afterwards looked at what factors predicted success or failure.

Some of their results: \- changing direction as a result of customer feedback
(very, very good, one of the best predictors of success) \- having an
accountant (good) \- having one parent born overseas (helpful for some reason)
\- making use of Australia's research and development tax concession (very
good) \- knowing the name of your lawyer (bad) \- accessing government
services designed to help startups (very bad) \- writing a business plan and
sticking to it (bad) \- founders having experience working in enterprises
(neither good nor bad, but it slowed the process down a lot)

My favourite gems that they discovered... in the Australian startup community,
it appears that investors are no better at picking successes than random
chance. Externally-funded companies had no difference in outcome compared to
bootstrapped ones; the only difference is that they got to success or failure
faster.

~~~
i_feel_great
Never heard of it, although I work just up the road from the Garden's Point
campus. Where can I find a summary?

~~~
solresol
[https://staff.qut.edu.au/staff/per.davidsson](https://staff.qut.edu.au/staff/per.davidsson)

------
bovermyer
When I was in my twenties, I was part of the early "life coach blogger"
culture.

Now that I'm almost in my forties, I realize everything I wrote back then was
bullshit. Earnest, but bullshit nonetheless.

I'm much more cynical, but I'm also much more likely to just do what seems
right and figure out the rest as I go. I don't read "best practices" or advice
articles anymore.

This is not to say that there is nothing to be gained from such sources; just
that the likelihood of it being useful or accurate given my particular context
is small.

In this, my attitude is much closer to where it was in my teens and childhood,
where I just had to figure everything out on my own.

~~~
kd5bjo
I’ve read a lot of time management/productivity books, and there seem to be
only two things all of the authors agree on: write stuff down, and
continuously tweak your system.

The latter is usually mentioned offhand in the preface, as the author wants to
deliver a _fait accompli_ instead of just some tips and tricks.

~~~
ionforce
Can you elaborate on "write stuff down"?

~~~
novok
Plan, write a log of work, write down your todos, keep track of what your
doing and keep yourself accountable.

------
amoorthy
I'm surprised this blog post made the first page of HN given its lack of
sources or analysis.

Maybe a good discussion can come on one example startup advice from YC: do
things that don't scale.

I think this is really sound in that they're saying "get product-market-fit
with some segment of users." i.e. know that there's demand for your
product/service even if it's pretty manual to deliver early on. Then see how
to automate. Because most product/services aren't materially better than
existing options and so you never get product-market-fit even when it's
entirely manual and customized to the user.

As a founder I've been guilty of building first because it's fun. I saw what I
wanted in user research and built a whole app accordingly. It failed. Would've
been better to start with a smaller attack surface (email newsletter) and once
we found success to then scale. The interesting thing is I knew of the advice
"do things that don't scale" beforehand. But until I failed I didn't know why
it mattered and how to apply it.

Net: applying advice is harder than evaluating if the advice is good or bad.
You want to have enough time to fail a lot and then appreciate the wisdom of
startup advice :-)

~~~
gtirloni
_> I'm surprised this blog post made the first page of HN given its lack of
sources or analysis._

Sometimes people will upvote articles not for the quality but for the
discussion they will trigger.

~~~
thisisbrians
This 100%. I sometimes upvote posts without even reading them because the
comments are very interesting.

~~~
thisisbrians
I guess the parent comment isn't very interesting...

------
dang
I think Paul Buchheit said it best in 2007:
[https://blog.daryn.net/post/32264049/paul-buchheit-
limited-l...](https://blog.daryn.net/post/32264049/paul-buchheit-limited-life-
experience) and
[http://redefine.dyndns.org/~andyr/blog/archives/2007/03/note...](http://redefine.dyndns.org/~andyr/blog/archives/2007/03/notes-
from-star-1.html)

But see
[https://news.ycombinator.com/item?id=70808](https://news.ycombinator.com/item?id=70808)
and
[https://news.ycombinator.com/item?id=70795](https://news.ycombinator.com/item?id=70795).

~~~
shafyy
Damn right.

------
blrgeek
Carnap vs Popper

Popper = create hypothesis and falsify

Carnap = see instances and use induction to create hypothesis

Everything else they say about the scientific method is the same.

Herbert Simon, in thinking of sciences of the artificial, used the Carnap
method to create a ton of valuable science.

It's not that post-facto is bad - carnap showed otherwise.

It's about the quality of the science and the specificity of the
recommendations, that lead to bs.

For instance you can mitigate for survivorship bias by studying the dead as
well as the living, and driving deep into the differences. But that's a lot of
work!

As a theory, effectuation studies the difference in decision making processes
between expert entrepreneurs and corporate CEOs. The result, while similarly
post-facto, is delightful. See effectuation.org - Vinod Khosla remarked it was
the first useful study on entrepreneurship he had ever read.

------
krm01
I think having lots of data points is the only way to give proper advice about
Startups. YC has given outstanding startup advice from a specific SV
perspective.

I've been running a UI/UX design firm for the last 10 years, working with
small unknown bootstrapping founders, up to well funded and awesome companies
founded by super stars like Elon Musk and others. Though this was never my
intent, over the years we've collected so many datapoints that alongside our
design work we tend to advice and steer the companies we work with into
directions we think the company should go. All backed by real examples from
previous experiences. Being in positions where you work with a lot of
companies over a longer period of time, I think, is the best way form
thoughtful startup advice.

~~~
shafyy
While data points do help, impactful startups often change the paradigm and
how things are done. So, again, I don't think relying too much on emperical
data points is good for founders. If you do, you'll rarely do something
interesting and new.

~~~
krm01
As I mentioned, data-points can help steer in the right direction. I'm
definitely not talking about disruption or changing paradigms. The same way a
YC can't guarantee each startup will disrupt an industry. All they can do is
help make something good, go to great faster.

~~~
shafyy
Agreed.

------
dcolkitt
> Do you think Musk copied that strategy from the business school he never
> went to.

Elon Musk did his undergrad at Wharton.

I guess the statement might be true if you mean "business school" to strictly
mean a graduate MBA program. But Musk definitely took business classes that
would have been nearly identical to those taken by MBAs.

~~~
shafyy
He has an economics and physics degree, not business. Did he take business
classes and read business books? Probably.

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

~~~
vikramkr
It's a business degree. The undergrad wharton degree just happens to be called
a B.S. in economics, but there's only a few economists classes in it, it's
entirely a business degree with business concentrations and so on. I think he
concentrated (like a major) in entrepreneurship but I might be wrong on that.

------
JackFr
[https://en.wikipedia.org/wiki/Whig_history](https://en.wikipedia.org/wiki/Whig_history)

"The term is also used extensively in the history of science to mean
historiography that focuses on the successful chain of theories and
experiments that led to present-day science, while ignoring failed theories
and dead ends."

------
squirrelicus
Emulating successful startups is folly. It's the myriad failures that you will
never learn about that you should be concerned with.

I'll just leave this here.
[https://en.m.wikipedia.org/wiki/Survivorship_bias](https://en.m.wikipedia.org/wiki/Survivorship_bias)

~~~
marcus_holmes
this. So much. Copying the success stories makes no sense unless you also
understand how other people following the same strategies failed. You have to
study the failures in order to understand the successes.

------
std_throwaway
It's hard to test theories when the underlying system constantly changes like
it does in economics. Something that works today might not work tomorrow. A
theory that looks sound when applied to yesteryears data might stop working
before the sun rises. When many others try to apply the same tricks that made
you successful the cake on that table might suddenly be divided into so many
pieces that everybody will go home hungry. You must find a new table with a
new cake but old data and old theory doesn't help much with that because
someone else is already there. You need to think fresh and unconventional or
you need to squeeze blood out of stones harder than anybody else.

Physicists have it easy in comparison. One of the basic truths of natural
science is that the laws of nature are independent of the observer and time
and experiments can be repeated as many times as you like with the same
results.

~~~
whatshisface
> _experiments can be repeated as many times as you like with the same
> results_

That is not actually true, there is a lot of randomness, and in quantum
mechanics the randomness is fundamental. The real secret of the natural
sciences is that good physicists never publish if they know they don't know
the answer. It took hundreds of years of that policy before the narrowly
applicable theories blossomed into the general laws of the universe. If the
focus was determining the general laws of the universe from the start no
progress could have been made: Newton could have guessed at the laws of
motion, but without the specific and painstaking celestial observations
preceding him nobody would have known he was right. Economists could enjoy a
similar success, but it would be at the expense of 400 years of saying only
things that policymakers thought were obvious, while refusing to answer useful
questions.

There are plenty of "very true" theories in economics, but they often aren't
broad enough to answer the questions about economics that the fate of nations
ride on. However 400 years from now those narrow but well-tested theories will
be the foundation of the _true_ general economics and all the rest will be
forgotten.

~~~
std_throwaway
Sure, there is randomness but in normal cases you can apply statistics to
describe it reasonably well. The results are not 100% sure but 99% or
99.99999% or whatever you need. It's not that the laws of gravity stop working
entirely over night. Newtons theory wasn't perfect and Einsteins theory isn't
perfect but it describes what happens in nature very very well for billions of
years.

~~~
whatshisface
You could find physical places where things seemed to change drastically one
hour to the next, for example my dog. You can also find things in economics
that don't change, like the laws of supply and demand in a true commodity
market. Supply and demand in a true commodity market is a pretty narrow
situation, but the early history of physics is full of narrow theories like
Kepler's laws and the precursors to PV=nRT.

If you went back 400 years and demanded that physicists explain my dog's
behaviors, you would probably get some answers that sounded OK (kind of like
Aristotle's attempts at physics) and maybe even were convincing to people of
the time, but they wouldn't have much truth value. Present day economics has a
few equivalents to Boyle's gas law, many equivalents to ancient Greek physics,
and no equivalents to atomic theory.

~~~
std_throwaway
The emotions of your dog are not laws of nature.

The "true market" is like "no true Scotsman" or "a closed system" or "a
spherical cow on a frictionless plane". It assumes something that doesn't
exist. In economics the influence of the things it assumes wrongly can be very
significant. In physics wrong assumptions can also make the results wrong and
a lot of work (or rather most work) is done on checking if all the assumptions
are sound and ensuring that the influence of the remaining gaps are
negligible. That is something that is hard to do in economics when it involves
interactions with the global market.

Yes, special theories can be precursors for more general theories.

~~~
whatshisface
> _The "true market" is like "no true Scotsman" or "a closed system" or "a
> spherical cow on a frictionless plane"._

Come on, what is physics about then? ;)

Even today, systems like my dog are computationally infeasible to predict from
the fundamentals, even though everything my dog does is a logical consequence
of QED. That's why it is impossible to make progress without assuming a
spherical cow and then traveling to every dairy farm in the world in search of
the roundest heifer available.

In 400 years economists might still be unable to predict recessions, but I
think by then the specific and very true theories of today will have had
enough time to evolve into general laws that could predict recessions in
principle.

~~~
std_throwaway
With regards to your dog, you should look into chaotic systems and the
butterfly effect. Chaos here doesn't mean that anything is possible or that
each outcome is equally likely. It refers to that the outcome changes greatly
for even minimal changes of the inputs. Since we don't know everything at one
point in time, we can only make limited predictions about a future state. No
matter how precise we measure the system it will still behave chaotically.

To some extent this is also true for the economy which contains many feedback
loops and meta-stable states. Even if we have the perfect theory it might
still behave chaotically and might be as unpredictable as the weather.

------
tmemth
> Or “Airbnb growth hacked Craigslist to link to their own website. And did
> you know that the founders lived with their users. You should do that,
> too!””

I was told by a founder that I was a first time founder (I am not) because I
didn’t believe this strategy works anymore. He was basically mocking me for
being so stupid to not know now growth hacking like this works.

And all the time I was thinking at the back of my head about how dogmatic his
thinking was. What works 10 years ago doesn’t mean it still works today.

Copying other people’s strategy is the worst way to run a startup. By the time
you have heard it, another 100 people probably heard it too and doing the same
thing.

I agree with the post. Think for yourself. And definitely don’t talk down to
other founders thinking you know better. Especially if you haven’t succeeded.

~~~
shafyy
Agree. Recently listened to a podcast with Jason Fried where he made this
point exactly. It's this IndieHacker episode here:
[https://www.indiehackers.com/podcast/105-jason-fried-of-
base...](https://www.indiehackers.com/podcast/105-jason-fried-of-basecamp)

Edit: Corrected link

~~~
gringoDan
Can you update this link? Looks like you just linked back to this thread's
URL.

~~~
shafyy
Just did, thanks

------
TrackerFF
Startup (and business) theory is really pretty simple:

1) Identify problem

2) Come up with, or look up for existing solutions

3) Develop, iterate

4) Identify and get some competitive edge

5) Keep pleasing clients

Of course, there's a ton of things underneath all this, like marketing,
funding, or simply being lucky with timing.

The copy-cat method is probably the most legit, and battle-tested method. I.e,
simply just copy some existing product or solution, with a known market.

The entrepreneurship scene preaches originality and novel idea to hopeful
founders, but to me, it always ends up with a race for who can do something
better than their competitor.

I've noticed that in many countries outside US, especially western Europe,
some of the largest startups are those that play-by-play copy successful US
startups, probably hoping to get acquired once the US startups start expanding
to said countries.

------
quartz
I feel like this post mistakes advice for directive.

Most of the great founders I've encountered are excellent pattern-matching
engines who can absorb large quantities of advice and then re-apply it within
their personal contexts rather than rejecting it outright, ex post facto or
not.

No you probably don't need to live with your users, but yes you should
probably spend significant time with them doing the thing your company is
trying to help them do better.

Putting advice to work is more than regurgitation... then again, if your
company's goal is to normalize short-term living with strangers well then
yeah, you probably should live with a few.

------
downandout
From the article:

 _”Do you think Brian Chesky of Airbnb heard that strategy from a friend?
Hell, do you even think that freeriding off of Craigslist was their reason for
success?”_

Yes, freeriding off of Craigslist was the reason for their _early_ success,
without which their later success was not possible. Having a good model means
absolutely nothing without some ability to market it, especially in the
marketplace space. Initial momentum is what causes these businesses to either
succeed or fail.

The idea of using free ways to get your startup initial momentum is absolutely
not BS.

~~~
shafyy
> The idea of using free ways to get your startup initial momentum is
> absolutely not BS.

Agree, and that's also not what I said :-)

~~~
downandout
That’s how I read it in the context of your premise. You seemed to be mocking
the notion that Craigslist was a vital part of their success. I am not sure
how else to interpret _“....Hell, do you even think that freeriding off of
Craigslist was their reason for success?”_

~~~
shafyy
I'm saying that they would have been successful with or without this marketing
tactics. I am not saying that startups shoulnd't use free marketing
opportunities.

~~~
vikramkr
Exactly, which means you're saying that this wasn't a vital part of their
success, while the other commenter is saying the opposite, so I don't think
you agree with the argument that doing things that don't scale is a critical
part of their success right? Unless I'm misreading something.

~~~
downandout
Yeah this was my point. IMO they would have never made it to the point of
becoming a viral success without their prolific Craigslist spamming operation.
Every virus needs a patient 0.

------
avs733
The issue isn't that its ex-post, it's how theory is built. There are better
and more credible resources/work on this topic than a blog post.

The most common terms I've seen that gets used in academic research that is
critical of how theories about entrepreneurship are built are 'mythifciation'
and 'reification'...

e.g.,
[https://onlinelibrary.wiley.com/doi/abs/10.1111/1467-6486.00...](https://onlinelibrary.wiley.com/doi/abs/10.1111/1467-6486.00196)

------
smallgovt
>> Do you think Musk copied that strategy from the business school he never
went to? Do you think Brian Chesky of Airbnb heard that strategy from a
friend?

Maybe not, but that doesn't mean talking to other successful founders isn't
extremely helpful. The best founders have multiple great ideas and not enough
time to execute on them. If you want to increase your success rate, you should
use feedback from other successful founders to decide which great idea to
invest your time in.

~~~
vikramkr
Also, musk could totally have learned that strategy when he was in bschool,
and chesky could totally have gotten the idea from a friend. Those are hardly
implausible situations.

~~~
shafyy
I agree, I don't now that for a fact. It's more a form of rhetoric to trigger
interesting discussions. Seems to work ;-)

~~~
vikramkr
Sure, but it wasn't phrased as an open ended question, it was framed as
rhetorical questions with a given answer that are evidence for your
conclusion. I'm confused by the "bschool he never went to" bit as well. I'll
grant that it sparks an interesting discussion, but I don't think that it does
much to support your thesis as evidence.

~~~
shafyy
I'm not writing an academic thesis. It's just my opinion in a short blog post.
Deal with it :-)

~~~
vikramkr
Not exactly sure what there is to deal with here, and it's certainly not easy
to have an interesting discussion about a topic if you decide that it's not
worth trying to argue your point instead of telling the other person to "deal
with it" when they ask for clarification about what some of your points mean
or point out things that would make your argument stronger if addressed

------
ThomPete
The problem with startup theory is, that the theory that actually works is
mostly the "don't do this". Only once in a blue moon does they prove to be
wrong, but they are also the least valuable as many of the are quite obvious.

The part of startup theory most people are interested in "the do's", most of
the time doesn't work as they are highly contextual.

------
rvn1045
The thing is though that you've probably read so much startup advice that your
sick of it and know a lot of it and dont find any value in it anymore. you've
reached a tipping point where you done reading about this shit and just want
to build stuff. but if you dont know anything about startups or business or
whatever its still probably useful to read about it.

------
vonnik
"Ignore advice" is not good advice. Even for startups. There are so many
predictable ways that founders screw up. I, personally, have committed most of
them. A few of them I avoided, or stopped doing soon enough to survive, and
often it was with the help of good advice. YC gives good advice: Talk to your
users. Build something people want. Run lean. Those are all great for people
starting out. There is a lot of knowledge much more specialized that,
contained in the collective wisdom of startup operators and investors. The
challenge is to vet your sources, know which advice applies to your situation,
and how to implement it. Nobody can teach you how to be a good judge of
character. And nobody knows your startup well enough to decide for you which
advice and how. But we can all learn from others who have gone through the
ringer, whether it's PG, Michael Seibel, Naval, Lemkin or others.

------
rdlecler1
Airbnb and Tesla surely looked at other business models for success and
modified or adapted it to their own. These theories can provide a framework to
help people think through the problems without reinventing the wheel. On to
the irony of the post: this post is giving advice “ignore advice think for
yourself”. Bs.

------
samtheprogram
> Do you think Brian Chesky of Airbnb heard that strategy from a friend?

I'm pretty sure he heard it from Paul Graham.

~~~
hiccuphippo
I'd be more interested in learning of what other startups used the same
strategy and failed anyway.

Ultimately luck is a large portion of success.

------
stephc_int13
I think the same about most management theory, most of the corporate bs can be
categorized as a form of Cargo-Cult.

Look how well they did doing that, let's copy them without understanding the
context or anything below the surface of the things.

------
nabdab
Don’t study success. The people who double their money by betting it all on
black didn’t have some divine insight that you can copy, they just got lucky.
But do study failure. The people who lose everything by betting it all on red
did have a fatal flaw in their approach to risk that will be valuable for you
to avoid or at least be well aware of.

One of the obvious faliures to study is that many great teams with great ideas
failed to get any funding because they didn’t walk the startup walk or talk
the startup talk with potential investors, which is exactly why you should
talk about copying Tesla and about growth hacking.

------
vortico
I agree that most anecdotal startup advice is BS, which is why I barely pay
attention to it. What I'd like more of is textbook-like material offering
terminology and detailed case studies. Simply knowing the common name for
something (e.g. marketing terms like
[https://en.wikipedia.org/wiki/Veblen_good](https://en.wikipedia.org/wiki/Veblen_good))
or the usual process of how things work (like a typical schedule of the
process for accepting angel funding) is far more useful than advice that seems
like darts thrown at a dartboard.

------
floki999
So true. Everyone and her grandmother is an armchair startup expert these
days. WTF is a startup anyway. I’m building a new for-profit business
enterprise, not a social i-have-one-too startup. Call it what it is.

------
rl3
Many years ago I read a ton of books on trading psychology. The best
books—widely considered to be bibles of their field—came to the following
conclusion:

There's many valid approaches, and often these approaches are radically
different. Regardless of whatever approach you choose, if it is to be
successful, it must be both reasoned out by—and compatible with—you.

I can't name a single great entrepreneur that didn't have very strong
opinions, or that largely relied on outside advice. These things must come
from within, and critical thinking is no exception.

------
ryandrake
So much crappy business advice suffers from Survivorship Bias [1]. “Companies
A, B, and C did X and succeeded. Companies D, E, and F did not do X and
failed. Therefore, X leads to success.” Ignoring how many companies also did X
but failed too. The book “Good to Great” contains nothing but Survivorship
Bias and is adored by Business Schools.

1:
[https://en.m.wikipedia.org/wiki/Survivorship_bias](https://en.m.wikipedia.org/wiki/Survivorship_bias)
(excuse the mobile link)

------
rmason
I did two startups in the nineties. There was little or no information out
there and the Internet quite frankly was a brand new world. Or so we thought
at the time ;<).

Now there's too much information out there. Lots of it is total malarkey to be
polite. If I had the choice I'd much rather have too much information than no
information. I honestly believe that I would have made fewer mistakes.

------
WheelsAtLarge
It's not all b.s. but it's hard to sort the good from the bad. It's impossible
to test out theories so you have to try lots of possibilities and hope for the
best. There are 2 basics that are part of every successful projects: hard work
and luck. Anything else you have to evaluate and decide whether it's worth the
risk in time and resources.

------
AznHisoka
Reminds me of the book "Good To Great". The author took a bunch of successful
companies, and found patterns that they all had in common. But just because
all these companies did X, didn't mean that made them successful. It could've
been because of survivorship bias. So yes, most business/startup advice is
curve overfitting, imo.

~~~
ci5er
I don't recall "Good to Great" coming to this conclusion - it was the later
critical pieces. (Poor guy - it was a lot of analysis!)

IIRC, the book "First, Break all the Rules" actually challenged the "Good to
Great" methodology a bit on this point.

(The other point, IIRC, was that first you have to find the right questions,
before the right answers can be considered).

------
joneckhardt
Much of the empirical academic literature on entrepreneurship and startups
does not suffer from ex post rationalization.

------
bikamonki
Yes, all future success stories will play out differently.

And no, we have identified patterns accross many past successful cases so we
think we can risk theorizing some formulae and advice.

Top of my mind: \- Build something really wanted/needed \- The A Team \-
Timing \- Early/easy access to funding

And whether you like it or not: luck!

------
grumpy8
The other side of the coin is after you've built a few startups, you see the
same pattern coming up again and again. Part of being creative is to know
where to focus your attention (I.e. figuring out PMF) rather than wasting
cycles on problems with clear solutions.

------
ufmace
I'd agree that it's rarely a good idea to directly copy any other startup.
It's probably good to hear many of their stories of success - maybe a few
pieces of one or two will give you a great idea, or at least tend to make you
think in the best ways.

~~~
std_throwaway
Take a working idea, find out why it's working, find out how to make it
better, try it out.

It doesn't make sense to only copy a working idea without understanding why
it's working because your copy will be slightly worse. While you might have
some success you won't take the big share. You must find a weakness in the
original idea or the execution or the location or anything else. If you have a
solid point where you can improve you have a chance. Don't be afraid of
stealing ideas and making them better.

------
Ma8ee
I can't help thinking of this wonderful talk about how to win the lottery:
[https://youtu.be/l_F9jxsfGCw](https://youtu.be/l_F9jxsfGCw)

~~~
downandout
That's actually a pretty great video. The tldw version: advice on how to buy
more lottery tickets is useful; advice on how to win the lottery is not.

------
monikgandhi
I really like this thinking, its more independent and logical. Just because
the idea worked for one, doesn't mean its gonna work for all. We need to
create our own paths to freedom.

------
chiefalchemist
BS feels heavy handed, but I sense her/his point. Paraphrasing:

Stop following and look for your own magic.

Yeah. Pleny of cookie-cutter knock off wannabe brands and products would
benefit from such thoughts.

------
twothamendment
My marriage advice is always this: "Don't listen to any marriage advice except
mine". I suppose if I wrote a longer version it would sound like this article.

~~~
tlb
But can you imagine starting a marriage never having heard any advice or even
seen a marriage in person? You were raised by wolves, but one day you came to
the village, met a girl, and now a guy in a robe says you're married. How much
trial and error will it take to become a good husband? You should go acquire
some wisdom by asking people.

Many startup founders are basically in that situation for a dozen kinds of
relationships. They've never hired, never closed a sale, never rented an
office, never tried to collect a late payment, never fired someone, never
raised VC money, never hired a marketing firm... Those things aren't rocket
science and you can certainly learn to do any of them, but noob mistakes are
expensive and you don't have a big cushion of time and money. So it's good to
have someone to talk your plans over with first.

A lot of advice does come down to "That's a standard problem, and here's a
standard way to solve it that works fine." That's fundamentally conservative
advice, but startups seem to do best if they innovate only on the few things
that make them unique and just do the standard thing for everything else.

------
compiler-guy
"To what do you attribute your success?"

"We listened to the people who gave us advice."

"We didn't listen to the naysayers."

One hears stories of both types.

------
joneckhardt
Much of the empirical work published in academic journals on startups is not
ex post.

------
AlexDragusin
Make something people want + Do something you love = All you need to know.
Enjoy.

------
travbrack
Kind of ironic that this is advice for startups.

------
billman
History is written by the victors.


Ask HN: How do you help your team “level up”? - Tharkun
I'm the lead software engineer at a company with about 10 other software engineers. Part of my job is coaching them on technical matters.
We organize biweekly talks about various technical subjects. And while these are fun to do, I'm not entirely sure that this approach will scale as the company grows.
How do other lead engineers help their team grow their skills?
Thanks!
======
sethammons
I help them by bringing forth best practices. What is the state the project
should be in? How do you get it there? How is logging, metrics, alerting,
ci/cd (roll out and role back), tracing, performance monitoring, system level
testing, unit testing, etc. Is there application state that can be removed?
Can code reviews be improved? Auto remediation on alerting? Techniques for
better project management. Maybe there are new packages or libraries that the
team should investigate. Give projects to team members that require them to
grow a bit, including presenting knowledge gains to others. There are few
teams and projects where that is all perfect.

------
atmosx
Secure a member budget for online classes (e.g. Coursera), conferences and
books. Have them do presentations on various subjects related to their craft
(new things they've learned, new frameworks), add standards (coding, testing,
linters, etc.) to the team's workflow, send them to conferences and have them
do presentations on what they learned and how could help the team grow, etc.
Voice your concerns, ask them to participate. Remember that ppl have
difference backgrounds and learn in many different ways.

NOTE: None of the above should be done if the employers free time, except from
the Coursera classes ofc which the company will have to pay if the team member
agrees. A team needs to have at least some time per month spent in personal
development, where you need to combine what everyone in the team likes with
what is useful to the company/team. All the above needs to be decided on a
team level, but as a leader you can drive the discussion.

------
janoka
Personal growth is something you really have to do personally. In my team the
developers are supposed to volunteer to work on stuff they have not worked
with before.

We need to update our deployment pipeline and you have never worked with AWS
before? Go for it!

Once they do, you can always do a bit of pair programming, but nothing really
helps you grow more than the hands-on experience.

------
laurentl
A few thoughts, as a CTO with a small team:

\- not everyone needs the same leveling up, and it’s not always technical. I
coach one of my junior dev on improving his code, another one in being more
confident of her skills. My lead dev is solid on code but doesn’t always take
into account the business perspective (i.e. in which context the code will be
used, how often, etc)

\- my main method of coaching is to ask a lot of questions. How do you plan to
implement this feature? Why this way? What’ll happen when <edge case>? Why did
you choose this architecture? Have you thought of <situation that’ll result in
a bug with the current implementation>? Whenever possible, I don’t say how it
should be done but try to bring them around to figuring it themselves. It’s
not (always) leading questions, either. I’m not cross-interrogating them, just
trying to understand what they did and why

\- closely related to above, I let them make their own mistakes. Rather than
try to convince someone that their approach won’t work (if the round of
questions isn’t enough to clarify this), I let them go ahead. They either
figure out on their own that they made a mistake (and then they’re open to
discussing alternative solutions), or when the code has become complex enough
I ask them to demonstrate a few corner cases. When those fail, sometimes
hilariously, we can go back to the design phase. I try to balance how long to
let them flounder between “long enough that they learn something” and “not so
long that they bear a grudge for being played”

\- refactoring their own code (for junior devs). I ask them to come back to a
piece of code they wrote mostly on their own, a few months after they’ve
worked on it (e.g. something they did as an intern, or one of their first
projects). Can you figure out what your code is doing? Hmm, guess some
comments and clear method names would come in handy now! How would you do
things differently in hindsight? How would you reorganize your code? Once the
code is refactored, a before/after comparison to highlight how much better the
new code is.

\- I’ll sometimes point someone to books or articles and ask them to read it,
when I want to make a specific point. E.g. I asked a dev who wrote some very
stateful js (lots of methods without a return value would would manipulate
global variables in weird ways) to read _Learn You a Haskell for Great Good_
to get him to think about side-effects and how to avoid them when possible.

\- I haven’t done this yet, but I thought about a team code advent where
everyone would solve the same problem in the same language, and we would
compare solutions. This implies setting out some time each day for everyone in
the team to work on the problem, so needs a little bit of planning and finding
the right time.

I realize that most of these ideas are time consuming, both for me and for the
developer. It would be much faster to just tell them how things should be done
(at least how I want them to be done), or to point out the mistakes as I see
them unfold. But I believe that teaching a man to fish is a much better long-
term solution than giving him a fish every day.

------
ezekg
I think one of the most valuable things a team can do to grow each other’s
skill is to practice good code review.


Losing my mindfulness - whysonot
http://www.tonysheng.com/blog/losing-my-mindfulness.html

======
pedalpete
The correct link for this is [http://www.tonysheng.com/blog/losing-my-
mindfulness/](http://www.tonysheng.com/blog/losing-my-mindfulness/)


Automated iOS app localization tool - Olshansky
http://olshansk.github.com/ios_localizer/

======
asd
Cool!


Get rewarded with tokens for recommending friends - vartikam
https://itunes.apple.com/us/app/bff-best-friends-forever/id1317793365?mt=8
======
vartikam
BFF is a community to ask and recommend contacts anonymously and earn a trust
score which will be converted to a reward as BFF tokens.