

How to quickly become effective when joining a new company - DRMacIver
http://www.drmaciver.com/2013/08/how-did-you-get-started-so-quickly/

======
dpatru
My summary: To become productive, get in the habit of doing things. More
specifically, get in the habit of immediately doing what needs doing. Don't
spend a lot of time learning in preparation for some future grand work when
there is useful work that you could be doing right away. When faced with a new
situation, quickly learn enough so that you can start doing useful work. Avoid
the temptation to spend a lot of time learning before contributing. Hence the
advice: "Acquire as little information as possible."

This meshes well with Sam Altman's advice to: "Have a good operational cadence
where projects are short and you’re releasing something new on a regular
basis." ([http://blog.samaltman.com/startup-
advice](http://blog.samaltman.com/startup-advice))

------
molbioguy
_Acquire as little information as possible_

This is an often overlooked opportunity. Learn as little as you absolutely
need so you don't get mired in the dogma. Some of the best solutions for
problems come from people who have not yet become indoctrinated in the
"standard" methodology. They approach problems with a fresh perspective and
can come up with new solutions that everyone else who's been there a while
missed. This opportunity is short lived, since everyone inevitably learns all
the standard ways, so it is very apt for when you join a new company.

~~~
dalke
"Some of the best solutions for problems come from people who have not yet
become indoctrinated in the "standard" methodology."

Is that really true, or a hypothesis? How was it tested, and what are the
numbers? For example, do 5% of the solutions come from people in their first
year and the other 95% come from those with between 1 year and 40 years? Or is
it more like 80% and 20%?

Knowing those numbers helps determine strategy. The former suggests that novel
solutions are hard, and inspiration is only weakly connected to experience,
while the latter suggests that people should move to new fields every year or
two, in order to take advantage of this effect.

For that matter, if the numbers are 1% and 99% then it implies that while
'some of the best solutions' come from new people, the overwhelming majority
do not, in which case your observation, while still true, has a different
interpretation.

In my own research, I came up with a novel and useful implementation for a
multiple-graph maximum common subgraph isomorphism. It's a problem that I
worked on when I first entered this field, when I was in my late 20s, but with
10+ years of experience in the field I was able to come up with a faster, more
efficient and more general purpose method.

(FWIW, it's based on the observation that in practice, for the types of graphs
I work with, a certain NP-hard method - pairwise subgraph isomorphism - is
actually very fast. New people to the field assume 'NP-hard' means 'avoid at
all costs', so avoid use this method.)

Is my story anecdotal? Absolutely. Which is why I'm curious to see the
evidence you used to form your statement.

~~~
molbioguy
My statement is based on personal experiences -- it's an observation and not
an authoritative fact; I don't have formal studies to back this up. A really
_great_ solution from a new perspective is admittedly rare when you take into
account all tasks. However, when there's a problem that's been giving a group
some difficulty, I've had many occasions where the new person who was coming
from a different background, provided a key advance. It was usually along the
lines of something we all thought was either too simple to try, "known" to not
work, or just went against all the standard methods we had been taught (like
the anecdotal example you provided).

In the context of the article, having minimal knowledge (just enough to
understand the problem), also affords you with the opportunity to learn more
_on your own_ and develop your own views before someone tells you how to
think. While I can't back it up with level of evidence you're asking for, in
my experience it's still a good strategy to go with. I realize this is
drifting away from the original topic. Sorry about that.

~~~
dalke
As I pointed out though, without some sense of what "many" means, it's not
possible to make an effective planning decision based on this hypothesis.

For example, what's the bias error? How many new problems are solved daily by
people with expertise in the field, which would take someone without that
expertise a long time? This is also different than the class of problems I
think you're referring to, which are cases where the experts in the fields are
already stymied. Even then, you might not notice the ones where someone with
15 years of experience figures it out, because you expect that to happen,
while if an intern solves it then it's notable.

At the point where the group is stuck, dead in the water on a problem, then
it's definitely useful to have others look on it, if only because there isn't
much to lose by doing so.

~~~
molbioguy
Not quite sure what you mean by "planning decision". Do mean actively
recruiting people with backgrounds and knowledge that are substantially
different from your existing group? Do you mean from the individual's point of
view whether or not to learn as much information as possible and become an
"expert" before contributing? I'm assuming you have minimally sufficient
knowledge of your field, otherwise you wouldn't have been hired in the first
place.

I'm just saying that it can _sometimes_ be advantageous not to spend all your
time learning as much as possible about the way things are normally done at
your new job/activity and approach the job from your own strengths and
knowledge. In that way you may surprise yourself and others with solutions
that they hadn't thought of because they couldn't see outside their box. You
will become an expert eventually (if you want), but you may delay contributing
if you wait until you reach that status before trying. And although you may
look foolish or stupid if your naive idea was wrong, in my experience you
don't get fired for trying. You just get embarrassed and then spend your time
steeping yourself in the field's dogma :) It's just an observation ...

~~~
dalke
By "planning decision" I mean to use this knowledge to make a decision which
is more likely to lead to a successful project.

Consider the converse to your statement: It can _sometimes_ be advantageous to
spend all your time learning as much as possible about the way things are
normally done while approaching the job from your own strengths and knowledge.

It seems that that converse statement is equally true. If a statement and its
converse seem equally true, then how useful of a statement is it?

"you may delay contributing if you wait until you reach that status before
trying"

Certainly. However, contributing is also an important part of learning, and
you are unlikely to get to expert status if you delay in contributing.

~~~
molbioguy
_By "planning decision" I mean to use this knowledge to make a decision which
is more likely to lead to a successful project._

Sorry, still not clear to me what you mean. Please clarify.

 _Consider the converse to your statement: It can sometimes be advantageous to
spend all your time learning as much as possible about the way things are
normally done while approaching the job from your own strengths and
knowledge._

Nope. The converse of what I said would be: It can sometimes be advantageous
to spend all your time learning as much as possible about the way things are
normally done before trying to contribute to projects.

 _" you may delay contributing if you wait until you reach that status before
trying" Certainly. However, contributing is also an important part of
learning, and you are unlikely to get to expert status if you delay in
contributing._

Yes, exactly. Fits with what I'm saying.

I'm sure you'll have something to say, so I'll leave you to have the last say.
Thanks for the discussion.

~~~
dalke
I'm not sure how I can clarify in another way, sorry.

Cheers.

------
nraynaud
In my last job, I hired a guy who was pretty impressive, in the morning he got
the code on his machine with the help of a co-worker next to him and got
accounts in the dev tools, after lunch he sat alone, he put on his headphones
and started killing bugs moving his head to the music. He corrected maybe 3 or
4 bugs on his first day. His code respected all the conventions we had set
(it's consistent so he gathered them from the existing code).

~~~
jiggy2011
Did he used to be a freelancer? Figuring out new tools and codebases is a
skill one tends to acquire very quickly in that line of work.

~~~
nraynaud
I don't really know him that well, I left the week he arrived :)

edit: but it felt like that, he knew the framework, but I guess he had seen
quite a few codebases before, also he was young in age.

------
tmorton
Cache link:
[http://webcache.googleusercontent.com/search?q=cache:pONjMF-...](http://webcache.googleusercontent.com/search?q=cache:pONjMF-
sswIJ:www.drmaciver.com/2013/08/how-did-you-get-started-so-
quickly/+&cd=1&hl=en&ct=clnk&gl=us)

~~~
DRMacIver
Thanks. I'm currently paying the price for my foolish decision to self-host
wordpress. In the process of trying to fix.

~~~
yaddayadda
I think this is proof of Principle 1's pros and cons. (I still don't have a
self-hosted blog because I tend to account for all contingencies. Therefore,
when I finally self-host, it won't have this flaw. Meanwhile, you already have
a self-hosted blog and are simply working out the kinks as they happen.)

~~~
DRMacIver
TBF, I've had a self-hosted blog for about 6 years. I just chose a platform
that I didn't understand in order to prevent me from wasting time yak shaving
on the means of hosting and just write content so have never actually
performed the learning part of step 1.

I've mostly got away with it in the past - it's survived much heavier
hackernewsings - but I think I installed a plugin recently that was rather
more costly than it should have been, and then the fact that I hadn't
previously looked under the hood bit me.

Edit: It's also worth noting I don't think principle 1 is always a good idea.
This advice is very specifically optimised for the case of joining an existing
company with an existing product and an existing team. If you're starting from
scratch you should do more up front investigation and thinking things through.
though maybe not orders of magnitude more.

------
gvb
I'm not wild about the labels "implicit" and "explicit" for mental models.
"Explicit" is not bad, but "implicit" is less intuitive. IMHO, "behavioral
model" is a better label.

With simulations (e.g. CPUs), what the OP referred to as an "implicit model"
is a "behavioral model" (the results are right, but the simulation takes
shortcuts). An "explicit model" is a "cycle accurate model" because the
simulation goes through all the actual motions that the real target (CPU)
would do.

Behavioral models are much faster but less detailed and sometimes less
accurate. For instance, in a CPU simulator, you get estimated execution times
for the code whereas for a cycle accurate model you will get actual
(simulated) clock cycles that the instructions took to execute the code.

~~~
DRMacIver
Yeah, I'm not wild about those labels either. I confess they were thought up
on the spur of the moment to try to explain the idea.

The reasoning for the naming is essentially that an explicit mental model is
one where you can write down all the steps, whileas an implicit model is one
that just arises naturally from the things already in your brain and you can't
really point to it and say what it is. I'm not sure that behavioural model
quite captures that, but I'm definitely up for a better naming convention.

------
splatcollision
Thanks for the detailed explanation of how your brain works - I found it a
fascinating read and insightful for my own thought processes as well, also
having one of those brains that "won't shut up" as you so aptly put it.

------
a3voices
What is the advantage of quickly becoming effective? You'll probably only get
promoted marginally faster, at best.

~~~
DRMacIver
If your sole measure of advantage is promotion then yeah, feel free to kick
back your heels and do whatever you want.

Personally, I quite like to be doing useful work, and normal ramp-up times for
people seem to be about 3-6 months, which if you work at a company for < 3
years can be as much as 10-20% of your time. More if you're switching between
projects within a company. It's pleasant to not have to waste that large a
percentage of your time getting up to speed.

