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).
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)
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.
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.
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.
This is absolutely true, but none of the (few) companies I've worked for were interested in a fresh perspective (with the exception of the company I was hired to bring a fresh perspective to). Entrenched mindsets dominated, unfortunately.
Agreed. I've always experienced pressure to conform, too. But I know some of my best contributions came when I didn't do things the standard way. Of course, going at things differently is risky, since you have no cover if things fail; however, if you find the right solution, it's very satisfying and can elevate your status quickly.
"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.
I think "best solutions come from new people" is an over-simplification of what actually happens. New people force you to re-examine your assumptions and blind spots. Sometimes this is useful, sometimes it isn't. This doesn't mean that new people solve more problems, but sometimes an influx of new people can help the experts to solve more problems because they realise something they assumed to be true/OK wasn't.
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.
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.
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 ...
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.
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.
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.)
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.
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.
Not being effective sucks. Do you enjoy the feeling of starting somewhere new or starting with a new project and not knowing what you're doing? The trick is to minimize that time so that you can:
a] feel effective
b] not have a long term, negative impact on your team's velocity.
I give new hires exactly one month to prove themselves now. I've found that giving more time does not increase the success rate of workers in any measurable way.
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.
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.
32 comments
[ 3.0 ms ] story [ 70.0 ms ] threadedit: 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.
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)
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.
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.
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.
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.
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.