4 ms·

The problem arises when you are focused on something very specific, for example designing a particularly complicated series of function calls, you effectively h

The problem arises when you are focused on something very specific, for example designing a particularly complicated series of function calls, you effectively have to keep a stack in your mind, think about locals, instance variables, whatever, abstract stuff that the brain isn't so well designed at retaining, which becomes very vulnerable to disruption. If you are unlucky enough to be interrupted while in that kind of state, the spinning plates effectively fall and break - it can almost be painful, and certainly drudging to get back up to where you were before. I've found this tends to take anywhere from 30 minutes to a day of time away from me because getting back in that flow state can be so damn difficult. I think a lot of the problem comes down to us using the brain for stuff it's not great at.

DTrejo 16y ago
Maybe your code is too complicated? I suppose the ultimate goal is too keep one's code clean and simple enough that one does have to go into super brain mode in order to solve a problem. Sadly we don't live in an ideal world.
- singular 16y ago
  I don't think it takes very much complexity before this kind of situation arises (perhaps my example was a little contrived!), maybe it would be clearer to apply this to debugging where it certainly becomes very quickly apparent even with extremely simple code. I don't think what you claim as ideal is possible - the only thing a programming environment can hope to offer is to eliminate as much accidental complexity as possible, leaving you to focus on essential complexity. The real-world problems we try to solve as developers are usually at least somewhat hard (even the seemingly simple ones), no getting away from that. In no way intending to be condescending, I seriously recommend you read 'No Silver Bullet' by Fred Brooks if you haven't already - http://en.wikipedia.org/wiki/No_Silver_Bullet http://en.wikipedia.org/wiki/No_Silver_Bullet - an absolute classic (and important too I think).
- epochwolf 16y ago
  > I suppose the ultimate goal is too keep one's code clean and simple enough that one does have to go into super brain mode in order to solve a problem. Let's drop back into reality for a minute. Just 15 minutes ago I was tracing sql data converted to xml by a rails application which was processed by a perl frontend. Yay legacy code. It would really be nice for things to be simple but the reality is I'm dealing with multiple erp systems that output mostly similar xml thanks to the people that where here before me. It is not possible to not end up in super brain mode with some of the problems I deal with. Now my latest project was rather complicated. I took a report that only showed current inventories and converted it to display inventories at any specific day. It was all fine and simple until I encountered a little off by one bug which caused most of the dates to be off by one. Tracing that error through all the layers required a number of hours. I am thankful I was not interrupted with an emergency fix to some production report so it only took hours to fix instead days. It would be nice if things were simple but not everyone gets to work with clean environments and applications.
  - tel 16y ago
    "It is not possible to not end up in super brain mode with some of the problems I deal with." I'll argue that it is possible, just not necessarily preferable. You could rewrite the whole thing. You could also focus on building a number of small functions which brings the whole interface up to a human-digestible level. The reality of the matter is not the realm of possibility, but instead that you often just want to get it working by whatever super-herculean effort it takes. People are often very interruptible while fighting hydras or stealing golden fleece. So it's twofold. Ensure that as often as possible you've got the programmatic infrastructure to only consider human-digestible chunks of complexity at any given time and try not to be interrupted whenever that's not possible.
    - epochwolf 16y ago
      > I'll argue that it is possible, just not necessarily preferable. No, it's not possible. I do my best to minimize complexity but it's hard. I don't have access to most of the systems I interface with. This is what I am talking about. The complexity is not just in legacy code but in interfaces I don't have control over. The project I mentioned was a complete rewrite and I'm able to modify most sections of it without tons of brain power. It's just the main report that's confusing as hell due to requirements. When things external to code are complex you need brain power. You need to create abstractions and your abstractions end up being complex because you can't mask some of the requirements behind simpler code. There is also a problem of lacking tools. I have no ability to use a real debugger on any of the programs I work with. Only one application will run on my laptop, everything else is sitting in a carefully deployed minefield of interconnected dependencies on various linux servers.
- ColinDabritz 16y ago
  What if we looked at it as a competitive advantage? Teamwork is a competitive advantage because a good team can develop more complex systems than a single programmer. Clean and simple code with good architecture is a competitive advantage, because using simpler more appropriate constructs, we can develop more complex systems (or our systems run faster, or take less resources) If we are able to go into super brain mode we are able to deal with and build more complex systems. I like clean code as a competitive advantage, or force multiplier, but I also like the ability to use super brain mode to be able to handle more complex systems. The double edged sword is that you've made a more complex system requiring the focus of super brain mode to work with, but if you use it carefully, sparingly, and wisely, perhaps your system can do things that a constant interruption brain mode system just can't do. It's a dangerous but powerful tool in my opinion. Perhaps working in that space is what separates the good or amazing developers from the code monkeys? Or is it always too much of a liability to have such a system?
stcredzero 16y ago
The problem arises when you are focused on something very specific, for example designing a particularly complicated series of function calls, you effectively have to keep a stack in your mind, think about locals, instance variables, whatever, abstract stuff that the brain isn't so well designed at retaining, which becomes very vulnerable to disruption. Let me ask this: after you've written such code, how is it for other people to read it? What is it like for people to debug it? I think a lot of the problem comes down to us using the brain for stuff it's not great at. I think good programming design tries to maximize the stuff your brain is good at and minimize the use of stuff your brain isn't good at.
- rdtsc 16y ago
  Note he said "designing" not coding. When you design things, a lot of relationships and entities are in your head. If you are just fixing some unit tests or looking to do small cleanups or tweaks then yes, you can do that while chatting with your friend about the weather, and at the same time banging away at code in front of you. Your context is just 100 or so lines of code.

DTrejo 16y ago

Maybe your code is too complicated? I suppose the ultimate goal is too keep one's code clean and simple enough that one does have to go into super brain mode in order to solve a problem. Sadly we don't live in an ideal world.

singular 16y ago
I don't think it takes very much complexity before this kind of situation arises (perhaps my example was a little contrived!), maybe it would be clearer to apply this to debugging where it certainly becomes very quickly apparent even with extremely simple code. I don't think what you claim as ideal is possible - the only thing a programming environment can hope to offer is to eliminate as much accidental complexity as possible, leaving you to focus on essential complexity. The real-world problems we try to solve as developers are usually at least somewhat hard (even the seemingly simple ones), no getting away from that. In no way intending to be condescending, I seriously recommend you read 'No Silver Bullet' by Fred Brooks if you haven't already - http://en.wikipedia.org/wiki/No_Silver_Bullet http://en.wikipedia.org/wiki/No_Silver_Bullet - an absolute classic (and important too I think).
epochwolf 16y ago
> I suppose the ultimate goal is too keep one's code clean and simple enough that one does have to go into super brain mode in order to solve a problem. Let's drop back into reality for a minute. Just 15 minutes ago I was tracing sql data converted to xml by a rails application which was processed by a perl frontend. Yay legacy code. It would really be nice for things to be simple but the reality is I'm dealing with multiple erp systems that output mostly similar xml thanks to the people that where here before me. It is not possible to not end up in super brain mode with some of the problems I deal with. Now my latest project was rather complicated. I took a report that only showed current inventories and converted it to display inventories at any specific day. It was all fine and simple until I encountered a little off by one bug which caused most of the dates to be off by one. Tracing that error through all the layers required a number of hours. I am thankful I was not interrupted with an emergency fix to some production report so it only took hours to fix instead days. It would be nice if things were simple but not everyone gets to work with clean environments and applications.
- tel 16y ago
  "It is not possible to not end up in super brain mode with some of the problems I deal with." I'll argue that it is possible, just not necessarily preferable. You could rewrite the whole thing. You could also focus on building a number of small functions which brings the whole interface up to a human-digestible level. The reality of the matter is not the realm of possibility, but instead that you often just want to get it working by whatever super-herculean effort it takes. People are often very interruptible while fighting hydras or stealing golden fleece. So it's twofold. Ensure that as often as possible you've got the programmatic infrastructure to only consider human-digestible chunks of complexity at any given time and try not to be interrupted whenever that's not possible.
  - epochwolf 16y ago
    > I'll argue that it is possible, just not necessarily preferable. No, it's not possible. I do my best to minimize complexity but it's hard. I don't have access to most of the systems I interface with. This is what I am talking about. The complexity is not just in legacy code but in interfaces I don't have control over. The project I mentioned was a complete rewrite and I'm able to modify most sections of it without tons of brain power. It's just the main report that's confusing as hell due to requirements. When things external to code are complex you need brain power. You need to create abstractions and your abstractions end up being complex because you can't mask some of the requirements behind simpler code. There is also a problem of lacking tools. I have no ability to use a real debugger on any of the programs I work with. Only one application will run on my laptop, everything else is sitting in a carefully deployed minefield of interconnected dependencies on various linux servers.
ColinDabritz 16y ago
What if we looked at it as a competitive advantage? Teamwork is a competitive advantage because a good team can develop more complex systems than a single programmer. Clean and simple code with good architecture is a competitive advantage, because using simpler more appropriate constructs, we can develop more complex systems (or our systems run faster, or take less resources) If we are able to go into super brain mode we are able to deal with and build more complex systems. I like clean code as a competitive advantage, or force multiplier, but I also like the ability to use super brain mode to be able to handle more complex systems. The double edged sword is that you've made a more complex system requiring the focus of super brain mode to work with, but if you use it carefully, sparingly, and wisely, perhaps your system can do things that a constant interruption brain mode system just can't do. It's a dangerous but powerful tool in my opinion. Perhaps working in that space is what separates the good or amazing developers from the code monkeys? Or is it always too much of a liability to have such a system?

stcredzero 16y ago

The problem arises when you are focused on something very specific, for example designing a particularly complicated series of function calls, you effectively have to keep a stack in your mind, think about locals, instance variables, whatever, abstract stuff that the brain isn't so well designed at retaining, which becomes very vulnerable to disruption. Let me ask this: after you've written such code, how is it for other people to read it? What is it like for people to debug it? I think a lot of the problem comes down to us using the brain for stuff it's not great at. I think good programming design tries to maximize the stuff your brain is good at and minimize the use of stuff your brain isn't good at.

rdtsc 16y ago
Note he said "designing" not coding. When you design things, a lot of relationships and entities are in your head. If you are just fixing some unit tests or looking to do small cleanups or tweaks then yes, you can do that while chatting with your friend about the weather, and at the same time banging away at code in front of you. Your context is just 100 or so lines of code.