4 ms·
I agree with the general point of the article. When you're deep coding you have a tentative model containing a lot of variables about the problem. You haven't c
by lordnacho 5y ago
I agree with the general point of the article. When you're deep coding you have a tentative model containing a lot of variables about the problem. You haven't committed them to memory yet, because it's all workings out that are undecided. Once you make some conclusions, that can be remembered because the end theory is simpler than the path to get there.
Nobody else constructs models in their minds that are almost purely mechanical and specific to a small problem. Every model the sales guy or manager uses has very few knobs to twist and are mostly intuitive models for which everyone has a template and practices use of every day: emotions, status, hierarchy, urgency, etc.
The programmer is building a house of cards and startling him means he needs to start over.
I agree if you're not deep coding, eg doing a bit of cleanup or documenting, it's not such a big problem.
EDIT
I seem to have ruffled some feathers with the absolute sounding "nobody else" phrasing.
I'm sure you'll run into someone else who has to think like a programmer, but I also tend to think such people to the extent they exist actually are programmers in some sense: either they happen to have a different title, or under the hood they are pretty much doing the same thing.
Now for some more about the nature of programmer's complexity. The thing about being a coder is you end up working on multiple abstraction levels, and they are all still your domain. If your app has some networking issue and you're wiresharking the packets, that's still you. If the front end is slow because you're calculating a lot on the GUI thread, that's still you. If the database is returning strange results, that's still programming. These are all areas that require a huge amount of work, in particular reading about existing conventions and tools, to understand.
In addition, programming has the capacity for you to create your own, local abstractions. Not only is the computer capable of remembering everything you made up, it also computes the interactions that you didn't consider. You have to interface these with the firmament. It is this creation of your own little menagerie and connecting it to the existing world that throws up an enormously large space for weird things to happen.
The thing that I need to point out is that there's no general human intuition for a lot of these things. Yes, you can use a bit of drawing diagrams to help you. But we don't get that intuitive, natural feel that you get in the rest of your life, particularly around emotions, that is I think called system 1 somewhere.
I also don't mean domain specific intuition, which is really just a form of learned knowledge.
- isbvhodnvemrwvn 5y ago> Every model the sales guy or manager uses has very few knobs to twist and are mostly intuitive models for which everyone has a template and practices use of every day: emotions, status, hierarchy, urgency, etc Have you ever worked in sales or as a manager?
- lordnacho 5y agoManaged teams for a long time. Not a sales guy per se, other than having been in a lot of sales calls.
- MattGaiser 5y agoLooking at their schedules for the ones on my team, you could not break up software development like they do with that they do. My manager's day is filled with stuff in 15 minute to 1.5 hour increments.
- isbvhodnvemrwvn 5y agoAnd yet even with these 15 minutes you have to immediately mentally reconstruct the context of this meeting and then actively listen to what the other person says, figure out if they actually mean what they ask (quite commonly the issue is different), and then immediately jump into another meeting, and you can't just forget what happened during that 15 minutes. You have to carry this mental model of conversation and context (typically multiple ones) all the day with you. Then you have to actively prioritize across the various contexts and deliver value for all of them, while being in the meetings for the better part of the day. It's a different side of the same coin.
- camjohnson26 5y agoI’ve noticed that I have a lot less trouble with interruptions deeper in my career than starting out because those mental models are refined and intuitive now. The example presented in the article where the programmer has a carefully constructed recreation of a null reference bug could probably be broken up into a series of steps that don’t require keeping as many variables in your head. I agree that interruptions are annoying but they’re unavoidable, and we can develop strategies to make them less impactful. Passive aggressively trying to make somebody else feel your pain is guaranteed not to work and will just make them resentful and make you look petty.