How can a Right-Brainer Deal with Massive Left-Brainer Code? [closed]

Question

I'm an artist, mostly, though I describe myself as a artist/physicist. While I can do math, deal with words, and the "logical" stuff considered left-brain, it's an effort and I make mistakes, whereas I do well with and most of the time think in terms of those things associated with right-brain thinking - spatial relations, holistic big-picture context, etc. Of course all that is fuzzy, as the right-left brain theory is oversimplified and no mental activity is so simple. Yet I do sense that I fit in fine with artists, video directors, chefs, and other non-verbal thinking, creative types, while most people in "IT" or hardcore software engineers have minds that work differently, with attention to detail, holding many details in mind at one time, and strong rational and verbal capabilities.

So here I am in a job being paid to fix fussy and obscure bugs in a massive swarm of C++ software, very heavy on OO, and any one line of code makes no sense unless I hold in mind about twenty other class and method names, relations between them, the flow of execution (very spaghetti-like) and other detail.

Besides that, I'm also rather strongly against much of contemporary C++ and OO styles. Those who wrote this code really drank the deep OO and Modern C++ kool-ade. I find it actually makes code much harder to follow, much harder to decide where to fix or change something. I don't know if this is part of the left/right differnce (or whatever you want to call it) or not.

But work on the C++ I must - people depend on me for my income. What are tips and techniques to deal with this situation, to be as effective as possible for my employer?

Answer 1

Try getting more into the design side of things where being comfortable with the fuzziness is a strength would be my suggestion in terms of career progression. As someone that likes to be creative, working on maintenance may not be a great fit whereas working on new stuff may be better if that is possible.

While there is nothing wrong with wanting some pride in one's work, wanting to not get bogged down in the details may be something that you may have to find a new approach to improve. Rather than look at it as getting down and dirty, there may be another perspective that could make it fun somehow.

---

Support and maintenance likely have their fans as some people would prefer to tweak existing systems than put in a new system. I know I tend to work better with an existing system that I'm changing rather than trying to pull something out of the ether.

What you may try to do is to note when people are wanting ideas for dealing with various trouble spots and brainstorm solutions as this is part of what you like. It isn't about knowing which lines of code to change but rather if you can tell someone, "Did you look in that object and see if it is doing more than it claims?" kind of thing.

Another point is knowing what you want to create: Graphics, applications, websites, processes or systems? These are all slightly different things that in wanting to create, you could be asked for "Create what?"

Answer 2

It doesn't sound (at least to me) like your code is particularly object-oriented, or particularly similar to "Modern C++". Rather the contrary, one of the key elements of good object orientation is encapsulation, the primary intent of which is to reduce the number of things you need to keep track of at any given time. Likewise, "very spaghetti-like ... flow of execution" sounds neither object oriented nor modern (anything).

Now, I suppose if I looked at the code you're maintaining, I might see it differently, and/or you might see my code as being similar to what you're maintaining right now -- that's a bit hard to guess. It is true that if you tried to trace through every detail of how my code works, I suppose you could see it as a rather spaghetti-like flow of control.

Just for example, I'm a lot more fond (or at least tolerant) of quite a few implicit conversions than many programmers -- I use things like proxy classes quite a bit. This means there might easily be three or four temporary objects of different types created in the course of calling a single function (and note that I'm not talking about actually executing the function, just calling it). Of course, all of those temporary objects will be destroyed again at the end of the expression containing the function call. If you count it up, you might easily have half a dozen or more separate functions invoked in calling/returning from one function that's "visibly" called in the code.

The point of doing things that way, however, is to make it easy to ignore most of the trivia involved in (for example) dealing with details like how a particular object is represented, and concentrate solely on what it really is instead. You'd only ever need to deal with most of that code if you saw a bug in that particular part. I try to avoid much of that, however, by creating classes so small and simple, that do so little, that it takes barely more than a glance to realize that it's obviously correct, so it's easy to ignore from then on.

Answer 3

Warning: this answer is very long and has a lot of psychobabble (which I try to explain, but still). What can I say? Psychology is one of my favorite subjects outside programming.

I'm an artist, mostly, though I describe myself as a artist/physicist. While I can do math, deal with words, and the "logical" stuff considered left-brain, it's an effort and I make mistakes, whereas I do well with and most of the time think in terms of those things associated with right-brain thinking - spatial relations, holistic big-picture context, etc. Of course all that is fuzzy, as the right-left brain theory is oversimplified and no mental activity is so simple. Yet I do sense that I fit in fine with artists, video directors, chefs, and other non-verbal thinking, creative types, while most people in "IT" or hardcore software engineers have minds that work differently, with attention to detail, holding many details in mind at one time, and strong rational and verbal capabilities.

This is actually based on a somewhat outdated view of neuroscience. At one point in time, scientists believed that the left brain was only responsible for logic and raw sensory data while the right brain was solely responsible for intuition and feeling. As it turns out, the left brain is really capable of everything the right brain is and vice versa. As someone who is extremely right-brained yet logical, terrible with directions and spatial orientation, and completely devoid of any of the artistic creativity that is traditionally associated with the right brain, I can attest to this.

The best way to think of the difference between the left and right brain is to think of them as mirror images of each other. To understand this, you need some background data. A psychologist named Carl Jung came up with a personality theory in the 20s that divided up personality along a couple of dimensions. You've probably heard of one of them: introversion vs extraversion. I've written a couple blogposts on this subject, but it basically boils down to this: introversion differentiates itself from others while extraversion focuses on how it can connect to others. This is referred to as an "attitude".

Then you have four different cognitive functions: thinking, feeling, sensation, and intuition. For simplicity's sake, let's just say that two of these functions are considered "judging" functions (thinking and feeling) while the other two are "perceiving" functions. The judging functions make decisions. When you're in a judging mindset, you are trying to avoid surprises. You want to have made all of the right decisions beforehand so you don't have to adapt when surprises come along. Because you've done so much planning in advance, you may have a tendency to become rigid and inflexible once a decision has been made. On the other hand, a perceiving mindset tends to prefer flying by the seat of its pants and rolling with the punches.

Generally, you combine the function and an attitude to create a (creatively named) function-attitude (introverted thinking, extraverted feeling, etc). Peoples' conscious personalities are defined mostly by a dominant function-attitude and an auxiliary function-attitude. Eventually, psychologists came to a consensus that there are broadly two types of people: people whose primary two functions consist of an introverted judging function and an extraverted perceiving function, or people whose primary two functions consist of an extraverted judging function and an introverted perceiving function. If you've ever taken the MBTI or similar personality test, the last letter tells you which category you fall into. If you're a P, it means you're an introverted judger/extraverted perceiver and J is the other way around.

Still with me thus far? Here's where I get to what I meant by the two sides being mirror images of each other. Nobody realized it at the time, but they were essentially building a sketch of where functionality lies in the brain. Indeed, each of Jung's function-attitudes has been mapped to a rough location in the brain. As it turns out, all of the P functions (introverted judging and extraverted perceiving) are on the right side of the brain and the J functions are on the left side of the brain.

Whenever you say that left-brained people are good at details and right-brained people are good at the "big picture" (although I would say "whole picture" would be more accurate), you're focusing on the extraverted side of things. If a left-brained person manages a right-brained person, the lefty is going to want to know all the details about how the righty is going to do their job up front and in advance. They want the requirements set in stone and hard deadlines decided in advance. The righty just wants a very broad idea of what they need to do so they can fill in the details later.

However, note that this isn't doesn't seem to be what you are experiencing. It seems as though the lefties' code probably wasn't terribly well thought out in advance and has some issues that could have been prevented by some forethought. This is because when you build abstract models of things like code in your head, you're using your introverted function, which works the other way around. The righty wants to build that model in advance and do so in such a manner that it fills in all the necessary details or easily can fill in all the details. Plus, they might become rigid in terms of the best approach to take (note that you're taking a hard line on how you feel about C++'s more advance features). The lefties' model will be more ad hoc and filled in as they go.

My experience is that because of this, the lefties will accuse the righties of over-engineering everything while the righties will accuse the lefties of being too quick and dirty. Both sides have a grain of truth to them, but only when that approach is taken to the extreme. Here's what's funny though: they're taking opposite approaches to achieve the same goal (that is, getting things done). The righties want to have their model decided upon up front so they can spend less time implementing the thing and therefore getting the entire project done sooner. The lefties want to spend less time architecting so they can get things done sooner.

Incidentally, these two attitudes are reversed when it comes to project management type stuff (determining timelines, coming up with requirements, etc). This can lead to a really confusing situation where one side is accusing the other of being too rigid while the other claims that the other side isn't planning ahead enough, and then the next argument has both sides taking the exact opposite stance.

What can you do about all of this? Nothing other than being aware of these differences and trying to accomodate the other side's view as much as possible. The problem though is that this goes both ways. You can understand and accomodate the lefties as much as possible, but that won't make much difference unless they're trying to return the favor. This is always the challenge. Not because the lefties are assholes and want to make the righties' lives miserable, but because the lefties are used to being dominant in the field of programming. If your way of thinking was echoed by pretty much everyone else, you'd be pretty convinced you're correct too.

Answer 4

Trust your intuition. If you are a good professional, it means regardless of your "brainness" - left or right - things that left-brainers do consciously you can do intuitively. In the end it's the same thing. Unfortunately we don't control our subconsciousness, but it does the job faster than our consciousness, if it does it at all. These intuitive insights coming out of nowhere are exactly the results of subconscious calculations.

Oh, and you may fail, it's too unreliable. But since you asked... ;)

Answer 5

I think visually also and the details of typography bedevil me.

Google terms: British dyslexia site also Learning styles: visual spatial thinking, whole to part learning.

Concepts First, Tips After

1. Right brained people imagine everything in their 'mind's eye'.
2. When your visualization corresponds well to reality, the work is easy
3. Right brained thinkers who do not do Left brained thinking well must rely on visualization
4. Right brained learners learn the whole thing at once 'aha!' then fit details into the mental construct. They need the overview FIRST, then details.
5. Without an overview for context, the details float in a vacuum, unconnected in the mind's eye - so brute force memorization has to be used. Very hard for the right -brained.

TIPS that helped me:

• 1 Use Color to distinguish syntax parts
  1. write pseudocode of the code you are debugging: this does this, then go here and label code sections to match
  2. if the objects were, say, real animals, they would have habits, and expected behaviors.This is a more easily visualized way of thinking about codeing.
  3. I imagine the code as a story with pseudicode as my notes and then follow the process around.

---

• What section to fix next?

• My workflow

• Who lives there? (process, connections, data,etc.)

• what do they need to do? (function) OK

  OK

• code it somewhere it can be syntax /spell checked OK copy and paste

• Test

  Result -->it Works? Yes, keep going

  No? The characters must be acting out Hamlet where everyone dies.

• Return to environment-

• left something out?, sysntax errors
• needs a connection
• needs data
• error code has meaning?
• it works in another part of code?
• Version trouble?
• its supposed to work