Summary
In his recent essay, Paul Graham explores the power of holding a program in your head.
Advertisement
It is common knowledge that the ability to focus and concentrate for long periods of time can make a developer more effective. In a recent essay, Holding a Program in One's Head, Paul Graham points to the main reason behind that truism: Uninterrupted concentration and focus allows a programmer to hold large parts of a program in his or her head. That, in turn, makes it possible for the programmer to fully explore the problem the program needs to solve.
Graham compares that mode of programming to how mathematicians explore a problem domain:
Mathematicians don't answer questions by working them out on paper the way schoolchildren are taught to. They do more in their heads: they try to understand a problem space well enough that they can walk around it the way you can walk around the memory of the house you grew up in. At its best programming is the same. You hold the whole program in your head, and you can manipulate it at will.
Graham notes that in-the-head programming is valuable mainly because it makes it easy to change your design simply by changing your mind:
Initially the most important thing is to be able to change what you're doing. Not just to solve the problem in a different way, but to change the problem you're solving.
Graham suggests eight best practices a programmer can follow to aid his or her mental faculties in keeping a program in memory:
Avoid distractions...
Oddly enough, scheduled distractions may be worse than unscheduled ones. If you know you have a meeting in an hour, you don't even start working on something hard.
Work in long stretches... Even when you're actively working on a program it can take half an hour to load into your head when you start work each day. And that's in the best case. Ordinary programmers working in typical office conditions never enter this mode. Or to put it more dramatically, ordinary programmers working in typical office conditions never really understand the problems they're solving.
Use succinct languages... You can magnify the effect of a powerful language by using a style called bottom-up programming, where you write programs in multiple layers, the lower ones acting as programming languages for those above. If you do this right, you only have to keep the topmost layer in your head.
Keep rewriting your program... You have to understand a program completely to rewrite it, so there is no better way to get one loaded into your head.
Write rereadable code... A prototype is a conversation with yourself. And when writing for yourself you have different priorities. If you're writing for other people, you may not want to make code too dense. Some parts of a program may be easiest to to read if you spread things out, like an introductory textbook.
Work in small groups... The smaller the number of programmers, the more completely a project can mutate. If there's just one programmer, as there often is at first, you can do all-encompassing redesigns.
Don't have multiple people editing the same piece of code.... Redesigning code with several authors is like changing laws; redesigning code you alone control is like seeing the other interpretation of an ambiguous image.
Start small... When you first start working on a project, you're forced to see everything. If you start with too big a problem, you may never quite be able to encompass it. So if you need to write a big, complex program, the best way to begin may not be to write a spec for it, but to write a prototype that solves a subset of the problem.
Graham notes that many organizations are set up in such a way that they discourage most of the above eight tenets:
There is a contradiction in the very phrase "software company." The two words are pulling in opposite directions. Any good programmer in a large organization is going to be at odds with it, because organizations are designed to prevent what programmers strive for...
One of the defining qualities of organizations since there have been such a thing is to treat individuals as interchangeable parts. This works well for more parallelizable tasks, like fighting wars. For most of history a well-drilled army of professional soldiers could be counted on to beat an army of individual warriors, no matter how valorous. But having ideas is not very parallelizable. And that's what programs are: ideas.
What do you think of Graham's suggestion of holding a program in your head?
1. cubicles: many times I've been pulled out of thinking about a particular business/programming problem by a colleague who decided to vent about the latest bonehead management decision
2. languages that divert your attention from the problem you're trying to solve to coddling the machine, e.g. memory management - dangling pointers, memory leaks
3. project managers who think you can accomplish anything when they shift priorities several times a day
4. matrix management: the practice of having a developer on several projects and leaving that developer to decide which project manager's priorities come first - amounts to the same as 3. above
There are probably plenty more, but these have been the biggest time wasters where I've worked.
I agree with Paul "Holding a Program in One's Head" is the ONLY WAY to do high quality software and to be a REAL SOFTWARE ARCHITECT. May be the "program" is a module, a library a well-defined part etc but one concentrated brain usually makes cohesive, coherent, symmetric, pattern based, almost bug free software.
This is because refactoring is a "dirty" pleasure, because is the art of convert nightmare dirty code in a sweet choreography, in the end of refactoring the program is hold in one's head. This is because software development is not a monkey job.
i agree too with those 8 points. So why many books, many it managers and even many developers still believe that we are to write first a lot of specifications, just as if a program could be written entirely on paper and then given to dumb programmers who just translate it in machine code?
> i agree too with those 8 points. So why many books, many > it managers and even many developers still believe that we > are to write first a lot of specifications, just as if a > program could be written entirely on paper and then given > to dumb programmers who just translate it in machine code?
There is a misguided notion, left over from the Industrial Era, that all work can be broken down into an assembly line process. Breaking down work this way allows for a small number of well paid people making decisions and a large number of poorly paid people simply implementing the decisions with little thought - sort of like human machines. Eventually the poorly paid implementors get replaced by either cheaper labor or machines. Software development seems to defy this notion (so far).
> Eventually the poorly paid implementors get > replaced by either cheaper labor or machines. Software > development seems to defy this notion (so far).
The thing that is so ironic about this is that the machines are already doing it. These misguided managers are trying to replace machines with people (using machines).
Well paid (and well educated) people making decisions and machines implementing the decisions is precisely what skilled programmers do.
> The thing that is so ironic about this is that the > machines are already doing it. These misguided managers > are trying to replace machines with people (using > machines). > > Well paid (and well educated) people making decisions and > machines implementing the decisions is precisely what > skilled programmers do.
Exactly!
I read somewhere, it might have been Pete McBreen's book "Software Craftsmanship", an analysis of the industrial practices trying to be applied to software development. The analogy breaks down because the assembly line, oft quoted as the ideal by IT managers, allows for mass reproduction of a product; whereas, reproduction of a piece of software isn't the problem - that's just a matter of stamping copies onto CD's, etc. The more appropriate analogy is with the design of the product, which is what developers do. Designing a product in an industrial setting is the time-consuming part as it is with software development. Even with the improved analogy, it's still not completely the same because we don't design products bounded by physical laws.
> I read somewhere, it might have been Pete McBreen's book > "Software Craftsmanship", an analysis of the industrial > practices trying to be applied to software development. > The analogy breaks down because the assembly line, oft > quoted as the ideal by IT managers, allows for mass > reproduction of a product; whereas, reproduction of a > piece of software isn't the problem - that's just a matter > of stamping copies onto CD's, etc.
The really insidious part of this is that by trying to make the problem (development productivity) fit the solution (assembly line) this approach is actually changing the nature of programming. Instead of building software that eliminates the need for repetitive work we are being pushed to write designs that can be implemented as repetitive work and to use tools that make repetitive development easier.
This seems good at first because what was being done by a few expensive people is now being done by a lot of cheap people. The problem is that acceleration is lost. A good developer will figure out how to eliminate most of the repetitive tasks or make them executable by non-developers. What I see is that this kills innovation. The unskilled team takes too long to get up to speed on new approaches and the members of this team will potential lack a voice. New approaches disrupt the assembly line.
Please realize that I'm not telling you or anyone else here this because I think you don't know it. I'm trying to hone this argument because it's a fight that I'm taking on.
> A good developer will figure out how to eliminate most of the > repetitive tasks or make them executable by > non-developers.
Exactly! we work with machines, if something may be replicated with almost no brain activity then some kind of software can do it (a framework, MDA tool, some kind of source code generation etc). *Every* developer IS an architect, may be a "low level" near-of-metal architect, but definitively an architect because a piece of code is not a brick, and if it is going to be a brick then construct some kind of framework or tool and it will put the brick for you.
> The really insidious part of this is that by trying to > make the problem (development productivity) fit the > solution (assembly line) this approach is actually > changing the nature of programming. Instead of building > software that eliminates the need for repetitive work we > are being pushed to write designs that can be implemented > as repetitive work and to use tools that make repetitive > development easier.
Yes...Good points. We're falling into the trap of being only skilled with a hammer so everything looks like a nail. The issue that worries me more is that we're spending so much time trying to force-fit development into the wrong model - and developing tools around that model - that we're not progressing software beyond its current paradigms. For instance, most UI software has a menu nowadays. Personally, I hate menus. Trying to learn a new piece of software through its menu system is frustrating. IMO, menus are non-intuitive and artificially contrived hierarchies of actions. Isn't there a more intuitive paradigm? Not being a very visual person, I have a hard time envisioning what it would look like, but I think lots of dragging and dropping would be involved. I digress a bit, but I hope I got across my point that we as a community are continuously striving for better ways of developing in the same old paradigms. With the advances in processors, graphics, game theory, learning theory, etc., shouldn't we look towards an evolutionary shift in the paradigms we develop? Isn't that where our value to an organization can increase?
> This seems good at first because what was being done by a > few expensive people is now being done by a lot of cheap > people. The problem is that acceleration is lost. A good > developer will figure out how to eliminate most of the > repetitive tasks or make them executable by > non-developers. What I see is that this kills innovation. > The unskilled team takes too long to get up to speed on > n new approaches and the members of this team will > potential lack a voice. New approaches disrupt the > assembly line.
Developers tend to remain unskilled as a result of several factors. The assembly line approach and higher pay, relative to many other fields, attracts people with little interest in software development. Pushing decision and design into the hands of a few creates the view that developers don't need training/professional development. A friend mine became an Applications Manager after 20 years in the field. He's now fighting the battle for training his staff with his CIO. Ironically, his CIO jumped from 20+ years as a developer into being CIO at this startup company and he now resists training!
> Please realize that I'm not telling you or anyone else > here this because I think you don't know it. I'm trying > to hone this argument because it's a fight that I'm taking > on.
No offense taken at all. These forums start with a focused topic and become a way of "thinking out loud" problems we see and just getting the frustrations we experience daily out of our systems. It's natural for human communication.
Flat View: This topic has 24 replies
on 2 pages
[
12
|
»
]
Previous Topic
