How to quickly become effective when joining a new company
drmaciver.com
drmaciver.com
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)
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.
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.
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.
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.
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 ...
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.
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.
Cheers.
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.
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.
Instead I flailed around blindly in the usual manner of trying to get PHP applications to work and seem to have fixed the problem. :-)
I should really move my blog to an environment I actually understand and have control over.
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.
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.
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.
Here's a good example - I hired two admins within a week of each other. The second hire had closed more tickets in two weeks than the first one did in three. The first was gone soon after.