Java Community News - Paul Graham on Holding a Program in One's Head

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Java Community News
Paul Graham on Holding a Program in One's Head

24 replies on 2 pages. Most recent reply: Aug 28, 2007 6:47 PM by Hui Deng

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 24 replies on 2 pages [ « | 1 2 ]

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Paul Graham on Holding a Program in One's Head

Posted: Aug 27, 2007 12:33 PM

> 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.

One of the things that I've see a lot recently is putting people with the most business knowledge in charge of technical teams. Business knowledge is a good thing and technical people should not be ignorant of it but the primary responsibility of a technical team or person is to be an expert in technical matters.

> 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!

He must have gone to business school. They brainwash you into groupthink there. I wish I could get someone who advocates this assembly line development strategy to debate the effectiveness of the strategy but I don't any deep thinkers have really advocated it. It seems assumed or based upon misleading metrics.

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Paul Graham on Holding a Program in One's Head

Posted: Aug 27, 2007 1:33 PM

> One of the things that I've see a lot recently is putting
> people with the most business knowledge in charge of
> technical teams. Business knowledge is a good thing and
> technical people should not be ignorant of it but the
> primary responsibility of a technical team or person is to
> be an expert in technical matters.

I'm certainly in the camp of developers being responsible for learning more about the business they code for.

It's odd that they'd put business people in charge of development. Isn't it kind of like putting an accountant as quarterback in an NFL game? In a situation like you describe, there is probably flagrant violation of the critical factors Paul describes.

> He must have gone to business school. They brainwash you
> into groupthink there. I wish I could get someone who
> advocates this assembly line development strategy to
> debate the effectiveness of the strategy but I don't any
> deep thinkers have really advocated it. It seems assumed
> or based upon misleading metrics.

If you can find any deep thinkers to explain assembly line applied to development, perhaps the person could also explain Six Sigma.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Paul Graham on Holding a Program in One's Head

Posted: Aug 27, 2007 2:01 PM

> It's odd that they'd put business people in charge of
> development. Isn't it kind of like putting an accountant
> as quarterback in an NFL game? In a situation like you
> describe, there is probably flagrant violation of the
> critical factors Paul describes.

I don't know. I see a lot of people who don't know a thing about development or much about computers deluding themselves into believing that it's easy. I think it's related to all these other bad ideas we are discussing.

And the thing about Six-Sigma. Yeah, that's a nightmare when applied to software. Too many really important things are hard to quantify and are therefore ignored. See the McNamara fallacy that I quoted in another thread recently.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Paul Graham on Holding a Program in One's Head

Posted: Aug 27, 2007 7:09 PM

> One of the things that I've see a lot recently is putting
> people with the most business knowledge in charge of
> technical teams. Business knowledge is a good thing and
> technical people should not be ignorant of it but the
> primary responsibility of a technical team or person is to
> be an expert in technical matters.

I think a failure by uber-geek technical people to understand "the business" actually stands in the way of innovation far more than primitive programming languages and cookie-cutter designs.

Computer science really isn't that useful all by itself. You need real problems to solve using its principles. That's software engineering.

You need to be able to keep the entire problem in your head, not just the program. Paul Graham advocates making this easier by unifying the problem and the program via an expressive programming language. I rather doubt this is entirely possible, but it is something to strive for.

In order to innovate (through software), we must solve increasingly complex problems. In order to solve those problems, we must understand them.

Hui Deng

Posts: 5
Nickname: dhui
Registered: Mar, 2004

Re: Paul Graham on Holding a Program in One's Head

Posted: Aug 27, 2007 11:09 PM

> Paul Graham advocates
> making this easier by unifying the problem and the program
> via an expressive programming language. I rather doubt
> this is entirely possible, but it is something to strive
> for.

It's not entirely possible, but it is mostly possible

> In order to innovate (through software), we must solve
> increasingly complex problems. In order to solve those
> problems, we must understand them.

In some sense, the process of solving is the process of underdtanding. The language you choose will have huge influence on how you understand the problems, and it also will give you a better approach to solving the problems(same as the oil medium to the painters)

ju ju

Posts: 6
Nickname: juborland
Registered: Apr, 2007

Re: Paul Graham on Holding a Program in One's Head

Posted: Aug 28, 2007 12:38 AM

> In some sense, the process of solving is the process of
> underdtanding. The language you choose will have huge
> influence on how you understand the problems, and it also
> will give you a better approach to solving the
> problems(same as the oil medium to the painters)

yes, i believe that the way the program is taking shape in our mind is definitely embodied by the language : the decisions we take are driven by the amount of knowledge we have of the programming language and of the frameworks we use.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Paul Graham on Holding a Program in One's Head

Posted: Aug 28, 2007 3:28 AM

Actually the bigger the model one can hold in his head, the smarter he appears to be. This is true for every mental job.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Paul Graham on Holding a Program in One's Head

Posted: Aug 28, 2007 4:30 AM

> > In order to innovate (through software), we must solve
> > increasingly complex problems. In order to solve those
> > problems, we must understand them.
>
> In some sense, the process of solving is the process of
> underdtanding.

No, I don't think they are the same process. The process of understanding and the process of solving definately exist in a tight feedback loop, but I believe they are separate.

In order to solve very complex problems you need to know how to partition them into sufficiently independent smaller problems. You need to understand the problem domain in order to do this. Yes, your understanding will improve considerably as you solve the problem, but ultimately the quality of that first division and of successive attempts will determine how quickly and effectively you solve the problem.

It's like the difference between a A* search with a good hueristic and just doing brute force. Domain knowledge is your huerstic function to guide the search. If it doesn't exist, is painfully slow (i.e. you have to go ask the customer), or grossly inaccurate (i.e. the customer doesn't understand what you are trying to do enough to give good feedback) then while the search may eventually terminate given infinite processing time and memory...

> The language you choose will have huge
> influence on how you understand the problems, and it also
> will give you a better approach to solving the
> problems(same as the oil medium to the painters)

Yes, absolutely.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Paul Graham on Holding a Program in One's Head

Posted: Aug 28, 2007 6:20 AM

> > One of the things that I've see a lot recently is
> putting
> > people with the most business knowledge in charge of
> > technical teams. Business knowledge is a good thing
> and
> > technical people should not be ignorant of it but the
> > primary responsibility of a technical team or person is
> to
> > be an expert in technical matters.
>
> I think a failure by uber-geek technical people to
> understand "the business" actually stands in the way of
> innovation far more than primitive programming languages
> and cookie-cutter designs.

I agree.

> Computer science really isn't that useful all by itself.
> You need real problems to solve using its principles.
> . That's software engineering.

I agree.

I think maybe I wasn't clear. The geeks need to learn the business, there is no doubt. But putting someone who doesn't know anything about developing, maintaining, or supporting software in charge of that, IMO, is a really asinine thing to do.

That this makes no sense has been borne out by my experience. I have had managers that have no idea who to listen to and follow the advice of the most hare-brained individuals because it's the most convenient or just pick one person that sounds convincing. I have had many project managers who apparently have nothing to do but just walk around and ask "how's it going" and when things aren't going well blame the geeks. Actually I prefer these people to the ones that want a status report every five minutes. "What percentage complete are you today?"

Hui Deng

Posts: 5
Nickname: dhui
Registered: Mar, 2004

Re: Paul Graham on Holding a Program in One's Head

Posted: Aug 28, 2007 6:47 PM

> No, I don't think they are the same process. The process
> of understanding and the process of solving definately
> exist in a tight feedback loop, but I believe they are
> separate.

The solving process is the milk, the understanding process is the water, they are not the same thing. But the real process of tackling a complex problem is to put the milk into the water, at this time you can't tell one from the other.

Flat View: This topic has 24 replies on 2 pages [ « | 1 2 ]

Previous Topic

Next Topic