Great points. They make me ask what PG thinks about unit tests: they seem to be like an exoskeleton allowing you to keep just a part of the program in your head. Or are they just a distraction?
Holding a program in one's head
71–80 of 136 posts
Re: Holding a program in one's head
#72Great essay Paul. Some echoes of your Lisp book and Code Complete!
The only downside to working on your own is that you don't see the bugs that you create through not seeing the problem? Others seem to see what you don't? That solo work needs tempering with some level of review.
I chuckled over the effort spent on 'homers', work done (perhaps even for the company) in a persons own time. Boy does that work get some deep concentration and produce some good results!
Thanks Paul. DaveP
Re: Holding a program in one's head
#73This is a collection of points PG has made before in other essays and comments. If the ideas are new to you, you may want to check out the others: http://www.paulgraham.com/articles.html > Perhaps the optimal solution is for big companies not even to try to develop ideas in house, but simply to buy them. What's good for YC is good for the country!
> What's good for YC is good for the country!
It's not that unlikely. Since we had the luxury of doing whatever we wanted by the time we started YC, it stands to reason we'd do something beneficial instead of merely money-making.
Re: Holding a program in one's head
#74This is a collection of points PG has made before in other essays and comments. If the ideas are new to you, you may want to check out the others: http://www.paulgraham.com/articles.html > Perhaps the optimal solution is for big companies not even to try to develop ideas in house, but simply to buy them. What's good for YC is good for the country!
> What's good for YC is good for the country! It's not that unlikely. Since we had the luxury of doing whatever we wanted by the time we started YC, it stands to reason we'd do something beneficial instead of merely money-making.
It reads like a marketing pitch to acquirers -- "don't build, buy! Look at this one, a 2.0 webby thingamajig, ain't she a beaut? Only nine ninety nine nine nine nine ninety-nine. Hardly any miles!"
Google sure seems to have a lot of success developing apps in-house, and due to integration requirements this makes a lot more sense in many cases. An outside party would simply be unable to provide an optimal solution in those instances. E.g., Kiko.
Re: Holding a program in one's head
#75I think you're right, except when it comes to what you say about brevity.
I don't think it's important for a program to have a small text-footprint in order for it to be easily loaded into your brain. Why? Because it's the CONCEPTS behind the application code we're loading into our heads. It's not the text itself. So... if I have a program where I've formulated a class tree, it doesn't matter to the ease with which I can grasp the program whether the classes are formulated in Python, C#, C++ or Pascal. It's the concept of the class tree which we load into our head. Not the code itself.
So, on that point you're actually wrong. Brevity isn't important.
That said, a lot of your other points actually DO make sense.
Re: Holding a program in one's head
#76I'm pretty sure that a lot of programmers, engineers and designers of many things get the message. A lot of them will understand the issue along additional axes too.
The problem is the people who impact problems and haven't got a clue. There seem to be a lot of them and they are dragging mankind backwards, slowing and even reversing progress. These are the turkeys who blame programmers for a majority failure rate of projects.
It's important to deturkify these guys. What can you do to help that happen?
Re: Holding a program in one's head
#77One useful technique for design/debugging is to read through the code, and explain it, to somebody else. (Whether or not they're actually there is often surprisingly immaterial)
Re: Holding a program in one's head
#78agree with most parts except for the use of perforce. most good programmers i know hate it, because it slows you down (as does subversion). git is the scm/vcs to use for doing feature experiments.
Re: Holding a program in one's head
#79I think you're right, except when it comes to what you say about brevity. I don't think it's important for a program to have a small text-footprint in order for it to be easily loaded into your brain. Why? Because it's the CONCEPTS behind the application code we're loading into our heads. It's not the text itself. So... if I have a program where I've formulated a class tree, it doesn't matter to the ease with which I…
I'm pretty sure what you described is what he meant by brevity. It's not about writing less code per say. It's about adding layers of abstraction, which classes are, to shrink the problem space.
Comparing python to assembly, python has basically added in another level of abstraction. It's easier to translate a concept into python because of this. A good hacker can build up these abstractions himself no matter the language, but it's just easier and nicer to use a language that has the type of abstractions you'll be using already built in.
Once you fully trust your classes then they become like DSLs and you build your program out of them rather than the raw bits of whatever language you're using.
Re: Holding a program in one's head
#80Point #3 ('Use succinct languages') deserves special mention. I've noticed time and again that writing small helper functions (especially new predicates) at my Scheme REPL leads to being able to express the problem at hand with ever more clarity. Also, a REPL with the ability to dynamically reload code is an invaluable weapon...