This is true for all kind of work you are doing with your head - and even if -like me- you are a surgeon! I guess I am "programming" my hands to do the work! Your essay gave me a better understanding - thanks
Holding a program in one's head
111–120 of 136 posts
Re: Holding a program in one's head
#112I suspected that my former employer was not unique in it's organizational misfits and reading your essay confirmed that it was indeed part of a larger picture. Of course. An organization cannot really tolerate indivduality as a basis for their development. Everything must be coordinated -> politics -> bad decisions. After working in a large organization for 8 years I quit, but not before I sent a letter to the man on the top. I conluded that my problems were due to his (bad) descisions:
1. The leader of 130 IT workers was not educated in IT. None of the top leaders were into IT. Not even the lead architect!
2. The economists think of everything as a "factory". Therefore, IT is produced the same way. I call this the "factory-view". If you add more money, more developers you will get this done faster. If you need something, go buy it. It's always better to outsource.
There were other things as well, but these factors may probably be more widespread than I like to think of. Finally I left for a small firm. What a relief!!
Re: Holding a program in one's head
#113I completely agree with the points.
Re: Holding a program in one's head
#114I am NOT a SW guy per say - I do ASIC/System level emulation - my way. It is a task that requires HW, different pieces of SW, scripting and work in the lab - but boy'o'boy - did U hit the nail RIGHT on the head. I worked for 4 years in a small but fiery start up and developed all the necessary pieces to emulate our system of 40M gates for about 1/10 of the $$ of commercial solutions - exactly the way U described it - in my head and in the (scarce) off hours....
Anyway, the startup didn't make it for the same lame reasons hundreds don't make it - abysmal (mis)management decisions that no technology can defeat :(
Now for a year I live in the quiet HELL of a bigger (and BIGGER) company where I HAVE to push the 2 buttons that I am assigned to and constantly reminded to shut up and watch the buttons I am assigned to push....
You touched a RAW nerve!
vess
Re: Holding a program in one's head
#115Thoughtful essay. You fail to mention the divide and conquer strategy that good mathematicians and programmers use to manage the complexity. Using your "loading" analogy, it would be like carving a problem into pages that exhibit locality of reference.
When mentoring smart rookies, this is the bit some are last to grasp. Partitioning a problem means that there isn't as much to remember. This scales, fractal-like to the design of larger systems.
I find as I get older, this is more and more important and necessary.
Re: Holding a program in one's head
#116Excellent points, except it's clear you've never spend much time pair programming in a small team. There, the rules are a little different, as the design is a collaborative process.
Although there's more inertia than working solo, I like team pair programming better. You get third-draft code in first-draft time when pairing, and having to continuously collaborate on the design sharpens your thinking a lot.
Re: Holding a program in one's head
#117I used to use the evening walks with our dog to solve programming problems. We live in a very, very quiet suburb with large properties, there is only local trafic and nothing else. So it was possible for me to visualise the solution to a problem into the dark in front of me (like an internal blackboard). Many times I came home after about an hour with a happy dog and a way to solve the problem or at least a great way to it. I just had to make some short note of it to pick it up next morning, the note releasing all saved information in my brain. Worked a treat for me.
Re: Holding a program in one's head
#118Wow. Nothing short of epiphanic.
Re: Holding a program in one's head
#119Wow... this is a great description of what's happening inside a good programmer. It may even be good enough to help non-programmers understand what's happening and therefore what to do about it. This should be on the short-list of reading for managers and others who are responsible for the software development working environment.
On a seperate tangent, Paul referred to some mental techniques (e.g. 'black box', 'solve a subset) and I can think of others (e.g. hold this portion 'constant' and change a different portion).
What if we had a catalog of those mental techniques - would that be interesting? Usefull? Who would use it?
Thirdly - my experience of loading the whole program in my head extends beyond programming - when I've participated in the business side, along with programming, then the scope of what I consider becomes larger (and involves some new elements) but the underlying approach and way of thinking about problems/solutions appears to be the same. Have other folks had a similar experience?
Re: Holding a program in one's head
#120Wow... this is a great description of what's happening inside a good programmer. It may even be good enough to help non-programmers understand what's happening and therefore what to do about it. This should be on the short-list of reading for managers and others who are responsible for the software development working environment. On a seperate tangent, Paul referred to some mental techniques (e.g. 'black box', 'solv…
[deleted]